Jonas Smedegaard <d...@jones.dk> writes: > Quoting Russ Allbery (2013-05-16 19:57:59)
>> Sure, but if you have control over the server certificate and are tying >> the server certificate to the user certificate via some mechanism like >> Monkeysphere, why do the whole indirection dance through a URI at all? > Because when identifier is a URI then it is reusable for other purposes > than authentication. Thank you -- this and your other message clarifies for me. The idea is to create a persistent representation of identity on the web that can be linked to, included in other graphs, etc. The problem with a certificate is that, while you can link *from* it, you can't (easily) link *to* it or include it in graphs that can be followed with simple HTTP requests. I'm not sure what I personally think of this use case (I'm in general not a fan of rich social graphs, since I think the privacy drawbacks of making all of that data easy to mine outweigh the benefits in most cases), but it's definitely a use case a lot of people care about. One further note, though: > For PGP keysigning, a common way to "authenticate" is to look at a > passport or drivers license. But we cannot really authenticate that > way. > In airports when showing a passport, it is matched against a centralized > database. The government issuing the passports also provides ways for > police and other governmental appointed people to authenticate > passports. > ...but noone else are allowed access to those centralized databases. The passport verification system works this way partly because it predates public key cryptography and partly because the government wants to store confidential data about you that it doesn't want other people (often including, and perhaps even *particularly*, you) to be able to see. For the former, one does a central database lookup to prevent people from forging passports for new identities. Note that this is actually not a very good authentication system; it prevents people from creating all-new identities, and it prevents people from crosslinking identifies to different identities, but it doesn't prevent someone from simply forging another person's identity completely if they happen to know their passport number and the necessary demographic data to fill out the rest of the passport. Public key signature verification is as good or better (it still doesn't prevent straight duplication of the passport, but you have to have access to the original passport to copy the signed data; you can't just generate a new passport from demographic information), and is therefore superior from an authentication perspective to just looking up the passport number and checking that the name and birthdate match the central database. I suspect most machine-readable passports these days actually contain public key signatures on the machine-readable data. The government therefore doesn't need to (and doesn't want) to expose that sort of validation service to let other people use passports as an authentication tool. Rather, they would switch to a public key signature and just publish the root CA public key. That's already what the US government does for government-issued PIV hardware smartcards, such as those given to government employees. Anyone can verify the identity on those cards given the root CA public key. The lookup the government does at the airport will persist and will continue to not be available to the general public for the second reason: the government wants a place to store additional metadata about people that can be updated at any time without refreshing their passport, that isn't public, and that can be kept from the person themselves. (Things like whether you're on a terrorism watch list, for example.) This is an important use case for the government, but Debian probably doesn't have quite the same use case. I suspect we'd rather put the person's metadata, apart from a few key things like "is this a person a member of the project," under the user's control. At that point, it's reasonable to have the user re-mint their certificate if they want to change the metadata. You do still need some way of recording that the certificate is no longer valid and shouldn't be trusted, but for that you probably want to use a CRL protocol that's specifically designed for that purpose and has the necessary cryptographic glue so that you can trust the results. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjvuvfjx....@windlord.stanford.edu
