Thoughts on using cryptography to allow users to control the dissemination of verifiable data in user-controlled "electronic wallets" This was originally composed in May 2001 in a thread on the importance of names, on a cypherpunks mailing list. I've stripped the comments of the person I replied to (since I did not seek his permission to republish his words). Apologies for any lack of coherence because of that editing. Regarding whether names are unique, whether they have ever been unique, and whether they are *unique identifiers*: No, names are not unique identifiers. Names are attributes of person objects. Like attributes in an LDAP schema, they're not unique. But within certain scopes, they are. Also note that not all attributes of a person object are readable by all who bind to the DIT (LDAP-speak for a directory of objects) that is the real world. They are used for identifying, they're just imperfect. On a mailing list I'd refer to you by your name (or email address) because those handles are sufficient and known to those on the list. But the folks at your local gas station know you by your car. Your grocer knows you perhaps by face, but perhaps by what you tend to buy. Amazon.com knows you by your customer number. There's no reason for Amazon to know what you eat, or for your grocer to know what you read. Regarding Diffie and Hellman's alleged assertion that names are suitable as unique identifiers: Right, this is a huge problem with PKI. Get a digital certificate from Verisign, and it only attests to certain attributes of your person objectness. If you visit Amazon.com from a PC where you have installed a Verisign client cert, but lack your Amazon cookie, how can Amazon associate the handles exposed in the Verisign cert to the handle they prefer (the Amazon customer number)? This isn't a theoretical problem, it's quite real. My organization has been offering some PKI/public-key based Web authentication for over a year now, and it's a real problem making the PKI useful to folks who want to offer services to folks with our certs. The trouble is exposing the right combination of handle/attributes to service providers without exposing too much information, or very sensitive info like cleartext social security #s. The system I propose essentially does away with the notion of unique identifiers. Each individual collects affidavits that link sets of facts together. Because we really don't care about identifiers, we care about sets of facts. A suggestion for practical applications for PKI that don't compromise privacy/anonymity needlessly. First example: proving identity at the electronic voting booth of the future. I think individual users need to hold signed attribute-level certificates. Encrypted, too. So my SS# is signed by the SSA, encrypted such that it can be read by me or the SSA. What good is a signed number? Not much. Each attribute would look something like this: --- BEGIN SIGNED MESSAGE --- SocialSecurityNumber = 123-45-6789 LastName = {SHA1}0x245235b1249231479a0987923b080c80d0ef14 FirstName = {SHA1}0x9471239479134c2314913478799a79879be793 DateOfBirth = {SHA1}0x49873984797d973984b08a08098e080809808d --- BEGIN SIGNATURE --- etc. So I present my signed SS# to the voting registration desk (after decrypting it) via infrared (nice and unidirectional, cheap). I have already given my name (of course) so those one-way hashes check out. Their device tells mine it needs to verify my DOB, so I send that, and it checks out, too. (Obviously for MANY fields, salted hashes are very, very important. E.G., date of birth; there are relatively few plausible birthdates, so the DOB field should use a very large, user-supplied salt -- user-supplied so you can have more faith in the randomness that is so important for protecting the attributes. It might be the case that virtually all facts are stored as salted hashes, and some facts might be stored with multiple hashes, e.g. both salted SHA and MD5, to make forgery more difficult) The registration desk checks out a few other signed facts, and eventually is satisfied. This prevents me from needing a global identifier, which is good from a privacy perspective. And it puts me in control of my data, also good. If I'm worried about car crashes, I encrypt certain facts such that appropriate emergency staff can read them without my intervention. My affidavit would be signed for the Global Emergency Services key and would give things like my insurance number, name, etc. The emergency folks could decrypt that plaintext data, and use the signed one-way hashes to verify it. For instance, my insurance company would give me an affidavit with hashes of things like name, date of birth, policy number, coverage details, etc. The emergency crews could use that to verify coverage with more certainty than some easily forged coated identification card. It lets me hold facts more easily used by service providers. For instance, General Motors sends me a signed affidavit that I own my automobile (identified by year, model, make, VIN): I present this to valet services to reclaim my car after dinner. The cross-reference hashes could include my name, physical description, even a hash of a digital photograph that my personal info wallet would hold. So I'd let the valet see that GM associated the ID picture with the VIN, and that's that. Anonymity and security. Another very good application: government ID cards. How many Americans have seen Department of Defense ID cards? I have. Well, I think I have. How would I know? With user-stored attributes such as I propose. A DOD employee would have an affidavit with facts like - name - agency - rank - photograph - security clearance When the DOD employee shows me their "ID" they do noting more than beam my PDA - their photo - a statement of the facts I need (photo, name, agency, rank) - the DOD-signed affidavit If I don't already have the DOD public key, signed by a trusted authority (Verisign?), my PDA retrieves the DOD public key from the net. I visually compare the photo to their face while my PDA checks the crypto sigs and calculates the checksums to verify the "facts" the person presented. If I have a network connection, my PDA also checks the DOD certificate revocation database to make sure this DOD affidavit is still valid (maybe the person was sacked last week). In the end, even though I have never seen a DOD "ID", I can be quite confident that the ID holder is legit. Even local police agencies could use this -- ever hear of black hats dressing as cops to pull scams? This would make that a hell of a lot more difficult, especially with a live (wireless?) net connection to allow checking the police department's realtime certificate revocation list. In the same way that we geeks sign each other's GPG keys, we could sign affidavits about each other. I could vouch for the identity of my family members and close friends, and build a web of authenticity. (Such affidavits would probably include both facts and identifying photographs, possibly also distinct arbitrary statements. E.G., I might sign an affidavit for Jay Beale with hashes of assertions like Jay is male, lives in Maryland, works for MandrakeSoft, likes a certain kind of food, and works on Bastille. Jay could show only a subset of these to others if he wished, e.g. if Jay liked filet mignon but was talking to a devout Hindu, he might not want to reveal that fact.) Technically, all an individual needs is data storage. A compactflash card, a Java ring, etc. Though the elite and paranoid might prefer to use a trusted device, for better security (after all, your private key is needed to decrypt some certificates for others). Sure, third parties could abuse this by demanding information that lets them compare notes and correlate data, but it's a very straightforward technical solution to several problems, including both increasing privacy and decreasing the costs involved in integrating PKI into different industries. -Peter Watkins original posted May 2001 edited/updated July 2001 $Id: anon.txt,v 1.1 2001/07/18 03:36:37 peterw Exp peterw $