1. Namespaces in SPKI Carl M. Ellison Intel Architecture Labs carl.m.ellison@intel.com

2. 19 August 1999 Diffie, Hellman and Kohnfelder D-H: key management problem is solved. Instead of a courier, if you want to send me a message for my eyes only, look me up in the modified phone book and find my key. Kohnfelder: the central phone book is a bottleneck. Sign the (name,key) entries, call them certificates and let them wander the net.

3. 19 August 1999 Early Assumptions You know the people with whom you deal. Names function as identifiers. Therefore, if you learn the name of a keyholder you can make security decisions. System security depends on the security and practices of the CA.

4. 19 August 1999 New Realizations In the Global Village, names retain their social role but are not good identifiers. Even if there were a name that functioned as an identifier (e.g., a domain name), you probably don’t know the identified person. E.g., do you grant access to classified information to anyone who has a valid passport? …from Iraq?

5. 19 August 1999 Most Basic Flaw A telephone book does not claim to tell you whether a person should have access to classified information. It does not even tell you which Bob Smith is your old friend Bobby from summer camp. It gives clues but lets you do trial and error. Access control needs more than weak clues.

6. 19 August 1999 Certificate Classes (1) Name Key Permission [ID] Certificate ACL / Attribute Certificate

7. 19 August 1999 Authorization (1) Distinguished Name [DN] Key Permission [ID] Certificate ACL / Attribute Certificate Access Control Security Perimeter =

8. 19 August 1999 The Third Attack DN = common name + other information to make it globally unique. The DN’s common name field is defended as an aid to human users. This leads to the potential flaw that a human will look at the common name and assume he knows the person. That flaw can be exploited to create an attack.

9. 19 August 1999 Example (1/3) Date: Mon, 24 Aug 1998 15:48:15 -0400 From: geer@world.std.com (Dan Geer) To: wford@verisign.com, kent@bbn.com, cme@acm.org, perry@piermont.com Subject: discussion next week Cc: blakley@vnet.ibm.com, geer@world.std.com

10. 19 August 1999 Example (2/3) Gentlemen, I've decided to ask Bob Blakley to moderate rather than do it myself. He'll be in touch and if you've already got a lot of format and/or questions worked out, please bring him up to speed. See you next week. --dan

11. 19 August 1999 Example (3/3) So, I saw Bob Blakley outside a conference session on 8/26/98 and I approached him, saying that we needed to talk about the panel session the next week. He responded, “What panel session?” I was speaking to the father, not the son. Worse, the father is Bob Junior.

12. 19 August 1999 Certificate Classes (2) Name KeyPermission [ID] Certificate ACL / Attribute Certificate ACL / Authorization Certificate

13. 19 August 1999 Authorization (2) Name KeyPermission ID ACL / Authorization Certificate Access Control Security Perimeter Lawyer’s Security

14. 19 August 1999 Credential Formats ID Certificates –X.509 –PGP –SDSI/SPKI Attribute Forms –X9 attribute cert –SPKI attribute cert –ACL by name Authorization Forms –SPKI authorization cert –X.509 SSL –X.509v3 extension –X.509 SET –PGPticket –ACL by key ~/.ssh/authorized_keys AADS / X9.59 SSL root key list

15. 19 August 1999 Three Namespaces Global keyholder ID Local human-friendly name Local (to the verifier) permission tag

16. 19 August 1999 1: Key as Global ID The keyholder is the entity holding the private key, by definition. A public key is mathematically associated with a single private key. A public key is a byte string  an ID. A collision-free hash of the public key is also a byte string  an ID of the keyholder.

17. 19 August 1999 Lack of Public Key Anonymity Because a key is a global ID for the keyholder, use of the public key when the key is transmitted in the clear by the protocol, gives the attacker the equivalent of an ID codebook puzzle to solve. The televangelist problem… Need multiple keys, one per function or function class

18. 19 August 1999 2: Local Names People use names. We think with them. The names we use are local to our own heads and can be good identifiers when limited to our own small communities. SDSI defines local names and rules for linking name spaces, with a resulting increase in security.

19. 19 August 1999 Fully-qualified Names (1) To be used away from its locality, a name must be globally unique. Let us call this a fully-qualified name. A name local to one keyholder, paired with the public key of that keyholder, is a global ID, mapping to a key: (name fred) = k 1 (name n 1 n 2 … n N ) = k N

20. 19 August 1999 Fully-qualified Names (2) SDSI name chain reduction, recursively: (name n 1 n 2 … n N ) & (name n 1 ) = k 1  (name n 2 … n N ) Identical to the process with X.509 If there were one naming root, then the root key could be just assumed and not stated. There will never be one root, so all attribute certs need FQNs, probably as shown above.

21. 19 August 1999 3: Tag Namespaces Permissions need to be named to be verified The verifier is in charge of that naming -- and verification is local to it. Anyone delegating that permission must also be aware of it, unless delegation is by group.

22. 19 August 1999 Authorization Flow ACL K 3 do X? Y N Verifier’s Machine AB ACL: I say ( K 1 may delegate or do { X, Y, Z } ) A: K 1 says ( K 2 may delegate or do { X, Y } ) B: K 2 says ( K 3 may do { W, X } )  I say (K 3 may do {X}), by logical reduction Certificates

23. 19 August 1999 Tag Uniqueness A tag is visible only along a verification path. The verifier defines it and can get agreement from its delegates as to the meaning, syntax and use of the tag. Since entities are free to have as many keys as desired, a delegate can create a key for a specific tag delegation.