[therightkey] Non-digital maps, and 'technical trust'...

[Robin Wilton <[e-mail]>]

How did we ever manage? I suspect that using printed maps is one of those skills (like changing gear manually, or shaving with a cut-throat razor) that men cling to out of some atavistic belief that, if it really came down to it, we’d still be able to club a mammoth to death, skin and gut it, and roast it over an open fire. ;^)

But to your point about combining different types/styles of PKI:

1 - this is another example of an interesting architectural shift from predominantly hierarchical models to mesh-based ones; it’s starting to be visible in identity interfederation, too.
(Not sure what conclusions to draw from that observation yet, but I offer it as a data point).

2 - Combined PKIs obviously raise questions of technical interoperability (not least because, as last week’s IETF sessions illustrated, you’ll have stakeholders like the automotive industry insisting on their own variants of basic elements like certificate format, PKIX, etc. etc.).

3 - More to the point, composite PKIs raise questions of non-technical interoperability between different trust models. Your faith in a WoT-supported assertion of identity, for instance, will be based on different trust factors from your faith in an eIDAS-compliant certificate-based one.

This interoperability problem between different trust models already exists in the CA PKI world (where, for instance, the service user and the service provider have certificates with different trust anchors), and hasn’t been elegantly fixed there.

If you want to fix the problem centrally, you can fix it contractually, but that’s slow, expensive and inflexible. Fixing it technically would require something like Levels of Assurance, but for trust models, rather than identity assertions… that would be hard. (NB - I think we’re going to have to do something like that anyway, in due course, in order to make sense of the presence of PKI/crypto at multiple layers of the network infrastructure. For instance, what happens to the “trust score” of an inbound connection if it has come supported by a combination of DNSSEC and RPKI? But that’s some way off).

If you want to fix it at the client side instead, I think your client is going to end up being a lot thicker than you might currently be hoping.


R



On 27 Jul 2015, at 21:00, [e-mail] wrote:

> 
>   1. Using composite PKIs (Phillip Hallam-Baker)
> 
> From: Phillip Hallam-Baker <[e-mail]>
> Subject: [therightkey] Using composite PKIs
> Date: 27 July 2015 17:02:56 CEST
> To: "[e-mail]" <[e-mail]>, IETF OpenPGP <[e-mail]>, "[e-mail]" <[e-mail]>, <[e-mail]>
> 
> 
> [Followups on therightkey please]
> 
> Thinking about the discussion of the OpenPGP/DANE draft in OpenPGP in my car, I came up with a metaphor for how to approach joining different PKIs. In particular, Werner's comment that Web of Trust doesn't scale. The CA model does scale but it isn't actually much better when trying to identify private individuals rather than employees of a company since the only thing I can validate economically is an email address and that isn't a person.
> 
> We can approach the problem mathematically by considering the work factor (in US$) for causing a breach.
> 
> Combining Web of Trust with CA approaches and interning the assertions in an immutable blockchain like log does provide an approach that scales. The blockchain makes the workfactor time dependent. If the workfactor is $100 before an assertion is enrolled, it will be $trillions after.
> 
> Combining Web of Trust and CA trust is like building a dalek out of fiberglass: Individually, the glass fiber and the epoxy are weak. But using the two in combination locks the strands of glass fibre creating a lightweight shell that can support the weight of a small truck. This part is already written up:
> 
> https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/
> 
> 
> The question we are facing now is how we make sense of that type of data. Which is where the car trip comes in.
> 
> I am using GPS to navigate a part of the city I don't know very well. There are multiple resources at my disposal:
> 
> 1) My own knowledge of the area
> 2) Signposts on the road
> 3) The GPS maps in the car
> 4) Offline maps via my cell phone
> 
> Any one of these guides can be fallible. The GPS maps are pre big-dig (no CANBUS modem car for me) so they are out of date. Offline maps are more likely to be up to date but a malicious provider can direct specific individuals to the wrong place.
> 
> The fact that there is a human in the loop actually keeps the mapping service providers accountable. Even if 99% of drivers don't know where they are going. The fact that there are roadsigns and the fact that a few do know where they are going means that if the service defects, they are likely to be caught.
> 
> Using a pure online mapping service like Google Maps and a thin client means that I am always up to date but exposes all my movements to them. It also breaks if I am in Prague on a crappy AT&T data plan costing $20/Mb for international roaming. [Do the AT&T execs consider the semiotics of sending their customers a text message saying 'we are going to try to steal from you now' every time they cross an international border.
> 
> Using a pure offline map like the DVDRom based system in the Honda means that nobody can track me by my use of a mapping service. It also means that the maps are ten years out of date as I don't plan on replacing the van till the child whose car seat it was built to fit has learned to drive and won't trash the transmission.
> 
> The best map I have is actually an application on the phone that has downloadable maps for the whole of Europe and North America. The mapping service obviously preprocesses the maps so that the phone has as little work to do as possible. So it is a 'thick client' but not as thick as it might be.
> 
> 
> I think the key to making a composite PKI work is to approach the problem in a similar fashion. In the short term we want to be using the 'thin client' as this allows us to change how we analyze data and add new formats. When trying to develop a new protocol, agility is key. But the medium term goal is to have a thick-ish client.
> 
> 
> _______________________________________________
> therightkey mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/therightkey