SPKI Examples Carl M. Ellison INTERNET-DRAFT CyberCash, Inc. Expires: 15 September 1998 Bill Frantz Electric Communities Butler Lampson Microsoft Ron Rivest MIT Laboratory for Computer Science Brian M. Thomas Southwestern Bell Tatu Ylonen SSH 10 March 1998 SPKI Examples ---- -------- Status of This Document This document supersedes the draft filed under the name draft-ietf- spki-cert-examples-00.txt. This draft contains examples of SPKI structures for various applications. The structure definition is to be found in draft-ietf-spki-cert-structure-*.txt and the theory behind SPKI certificates is to be found in draft-ietf-spki-cert- theory-*.txt. Distribution of this document is unlimited. Comments should be sent to the SPKI (Simple Public Key Infrastructure) Working Group mailing list or to the authors. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a Ellison, et al. [Page 1] INTERNET-DRAFT SPKI Examples 10 March 1998 ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). Abstract SPKI structures are defined for public keys, hash values, access control list (ACL) entries and certificates. This document gives examples of such structures for real world applications. The examples here are not tied to any specific application and should be taken as informative examples rather than standard formats. However, once applications are fielded using such structures and we have experience with them, we can consider publishing those formats as proposed standards. That effort is considered out of scope for this document. Ellison, et al. [Page 2] INTERNET-DRAFT SPKI Examples 10 March 1998 Table of Contents Status of This Document....................................1 Abstract...................................................2 Table of Contents..........................................3 1. SPKI Basic Structures...................................4 2. Tag Examples............................................6 2.1 FTP....................................................6 2.2 HTTP...................................................6 2.3 TELNET.................................................6 2.4 Public Key Protected File System tags..................6 2.5 Authority to spend money...............................8 2.6 Purchase order signing permission......................8 3. Keyholder examples......................................9 3.1 Locator certificate....................................9 3.2 Insurance certificate.................................10 3.3 Auto-certificate......................................10 4. Object certificates....................................11 4.1 PICS-like ratings certificate.........................11 4.2 Virus checking certificate............................11 5. Full sequence, with auto-certificate...................12 Authors' Addresses........................................14 Expiration and File Name..................................15 Ellison, et al. [Page 3] INTERNET-DRAFT SPKI Examples 10 March 1998 1. SPKI Basic Structures An SPKI certificate has five fields of interest during trust computations: 1. Issuer -- the principal issuing this certificate and granting the permission or rights it communicates 2. Subject -- the principal or name acquiring the permission or rights 3. Delegation -- a flag noting whether the Subject is also acquiring the right to delegate all or part of the permission it acquires through this certificate 4. Authorization -- a field specifying the permission being communicated 5. Validity -- a specification of the dates or on-line conditions under which the certificate is assumed to be valid An SPKI ACL entry generates the same five fields, for trust computation, but does not need to contain them all. The Issuer is always "self" and is omitted from the structure. If the ACL is held in editable memory, then the Validity fields can be omitted on the assumption that if the owner of the ACL wants to declare an entry invalid, he can edit it immediately. However, for ACLs built into executable software, running remotely, this assumption may not hold true and one might want validity fields. The purpose of SPKI structures is to communicate permission or rights from one keyholder to another. If we consider this flow to go horizontally from left to right, at the left end of the flow one finds the injection of permission. This is always in the form of an access control list (ACL) entry. An ACL entry is like a certificate, except that it has no issuer and is not signed. It is protected in the application by other means. To the right of the ACL entry, one finds certificates. At least for the sake of discussion, there are two forms of certificate: one that communicates permissions and one that defines names. It is possible to unify the two, but for our purposes, they will be considered separately. A basic SPKI certificate communicates a permission from one key to another key (equivalently from one principal to another principal or from one keyholder to another keyholder). In the process, it can pass all permissions it has been handed, in which case it uses (tag (*)) as its tag field or it can pass only certain permissions. The former can be considered a group membership certificate. That is, the subject key is a full member of the group defined by the issuer key. Any permissions given the issuer are inherited by the subject. If the subject is a name rather than a key, then the permission is being granted to the named key. That is, it is assumed that the name will be reduced to a key before permissions propagate. This is Ellison, et al. [Page 4] INTERNET-DRAFT SPKI Examples 10 March 1998 especially important when considering the propagation of the permission to delegate. A named key may be given a permission without the permission to delegate, but that name could define a group and could therefore represent implicit delegation. A name certificate maps a name (in the issuer field) to either a key or a name (in the subject field). It is always a group membership style of certificate -- that is with (tag (*)). The bulk of what changes with each example in the next section is the field, so we assume the following certificate template: (cert (issuer (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|)) (subject (hash sha1 |Ve1L/7MqiJcj+LSa/l10fl3tuTQ=|)) ... (not-before "1998-03-01_12:42:17") (not-after "2012-01-01_00:00:00") ) or ACL template: (acl (entry (subject (hash sha1 |Ve1L/7MqiJcj+LSa/l10fl3tuTQ=|)) ... ) ) with a tag and possibly delegation field where the "..." is in the middle of the structures above. Ellison, et al. [Page 5] INTERNET-DRAFT SPKI Examples 10 March 1998 2. Tag Examples The fields listed here are not meant to be an exhaustive list of all possible s. Such is not possible. The final arbiter of what needs to be an and what parameters a particular needs is the designer of the code that verifies a certificate, e.g., to grant access. Listed here are fields we suspect might be useful and we present these here as a guide to the developer's imagination. 2.1 FTP (tag (ftp cybercash.com cme)) This indicates that the Subject has permission to do FTP into host cybercash.com as user cme. 2.2 HTTP (tag (http http://acme.com/company-private/personnel )) This gives the Subject permission to access the web page at the given URI. To give permission for an entire tree under a given URI, one might use: (tag (http (* prefix http://acme.com/company-private/personnel/ ))) 2.3 TELNET (tag (telnet clark.net cme )) This gives the Subject permission to telnet into host clark.net as user cme. 2.4 Public Key Protected File System tags (tag (pkpfs )) refers to a hypothetical distributed file system whose access is controlled by public key challenge/response. The can be a single pathname, a set of files (specified by normal "*" convention) or a directory sub-structure (specified by (* prefix ...)). For Ellison, et al. [Page 6] INTERNET-DRAFT SPKI Examples 10 March 1998 example, (tag (pkpfs //ftp.clark.net/pub/cme/spki.txt (* set read write))) would give read and write access to that one file on that one host machine, while (tag (pkpfs //ftp.clark.net/pub/cme/spki.* (* set read write))) would give read and write access to all files starting with "spki.". (tag (pkpfs //ftp.clark.net/pub/cme/ add)) would give permission to add new files to that directory and (tag (pkpfs (* prefix //ftp.clark.net/pub/cme/) read )) would give read permission to all files in that directory. The full specification of possible specifications is up to the implementer of this file system. One might also want to grant disk quotas for this file system, e.g., via: (tag (pkpfs-quota (* range le "50000" ))) One could have used (tag (pkpfs-quota "50000" )) to express the quota, but the (* range ...) form permits the user to delegate a sub-quota to some other user. Accounting for such quotas could be interesting, but one would probably want to charge each K of disk to all users in the certificate delegation chain, since the disk accounting system is not aware of acts of delegation and therefore can not reduce the quota of the delegator. To maintain good accounting, this would require each file to have a list of accounts (key hashes) against which its size is charged -- so that when a file is deleted, the appropriate quotas can be adjusted. Since there would probably be only a small number of different such chains of delegation, one might keep such lists separately from file nodes. However, these are details left to the designer of the PKPFS. Ellison, et al. [Page 7] INTERNET-DRAFT SPKI Examples 10 March 1998 2.5 Authority to spend money (tag (spend (* range le ))) indicates that the subject has authority to authorize spending up to per electronic check from at . For example, (propagate) (tag (spend BankBoston "011000390 436 20608" (* range le "500.00"))) permits someone to spend up to 500.00 per electronic check from the indicated checking account at BankBoston. [The account number above was chosen randomly and is hopefully not a valid BankBoston account.] (propagate) implies that this account holder has the permission to delegate check-writing ability to others (e.g., family members or temporary public keys (for use on a laptop while traveling)). 2.6 Purchase order signing permission (tag (purchase (* range le ) (* set <> ))) might indicate permission to issue a purchase order. The amount of the purchase order is limited by the second element of the (purchase ) S-expression and, optionally, a list of purchasable items is given as the third element. The company whose purchase orders are permitted to be signed here will appear in the certificate permission chain leading to the final purchase order. Specifically, that company's key will be the issuer at the head of the (purchase ) chain. Ellison, et al. [Page 8] INTERNET-DRAFT SPKI Examples 10 March 1998 3. Keyholder examples The set of examples in this section deals with (keyholder) subjects. These are for human consumption, since the subject is a human being (the keyholder of a particular key) rather than a key in cyberspace. Note that it is not meaningful for a keyholder certificate to have the (propagate) flag. 3.1 Locator certificate A locator certificate is one that is issued by a company that promises to keep track of the indicated keyholder until the not-after date, and promises to serve the keyholder with papers for the indicated fee in the indicated currency, up until the not-after date. This kind of certificate might be used to back up a legal contract in which the keyholder might have to pay damages at some future date, in the event of non-performance, so that it becomes important to know how to sue that keyholder at that later date. An old fashioned "identity certificate" doesn't serve as well here because it lists some information about the keyholder that might be used to track that person down, but that information is old by the time the contract is signed and it is the ability to locate that keyholder at the end of the contract that is important. Maintaining that ability costs money and therefore the issuer of the locator certificate expects to be paid for its services. The issuer might also charge the keyholder at the time of certificate issuance, but that fee need not be indicated in the certificate. For example: (cert (issuer (hash md5 |u2kl73MiObh5o1zkGmHdbA==|)) (subject (keyholder (hash md5 |kuXyqx8jYWdZ/j7Vffr+yg==| ))) (tag (tracking-fee "150" USD)) (not-after "2003-01-01_00:00:00") ) {KDQ6Y2VydCg2Omlzc3Vlcig0Omhhc2gzOm1kNTE2OrtpJe9zIjm4eaNc5Bp h3WwpKSg3OnN1YmplY3QoOTprZXlob2xkZXIoNDpoYXNoMzptZDUxNjqS5fK rHyNhZ1n+PtV9+v7KKSkpKDM6dGFnKDEyOnRyYWNraW5nLWZlZTM6MTUwMzp VU0QpKSg5Om5vdC1hZnRlcjE5OjIwMDMtMDEtMDFfMDA6MDA6MDApKQ==} notes in its tag field that the issuer will serve papers on the indicated keyholder for a tracking fee of $150 until the beginning of 2003. Ellison, et al. [Page 9] INTERNET-DRAFT SPKI Examples 10 March 1998 3.2 Insurance certificate Instead of tracking down a keyholder and serving papers on him or her, the person relying on a certificate might prefer that some insurance company pay the penalty amount in the event of non- performance, and then worry on its own about collecting that fee (plus damages, no doubt) from the keyholder. This kind of certificate, like an insurance policy, will cost the user of the certificate money at the time it is issued. It is therefore good for only one user. For example: (cert (issuer (hash md5 |u2kl73MiObh5o1zkGmHdbA==|)) (subject (keyholder (hash md5 |kuXyqx8jYWdZ/j7Vffr+yg==| ))) (tag (insured "50000" USD) (to (hash md5 |1r8ICXryJw6v/B4MQdTU/Q==|)) (for "Failure to perform under contract (on file): " (hash md5 |gPA50iM6yETsixLgo2kVlA==|))) (not-after "2003-01-01_00:00:00") ) represents a promise to pay $50000 to |1r8ICXryJw6v/B4MQdTU/Q==| in the event that the keyholder of |kuXyqx8jYWdZ/j7Vffr+yg==| fails to fulfill the contract, |gPA50iM6yETsixLgo2kVlA==|. 3.3 Auto-certificate There are some pieces of information about which the proper issuer is the subject. The name a keyholder prefers to be called, the phone number or e-mail address at which the keyholder can be reached, etc., are all items of information about which the keyholder is the best authority. (cert (issuer (hash sha1 |1QvsTPF0/vqHPGODX/yEN8ro+sc=|)) (subject (keyholder (hash sha1 |1QvsTPF0/vqHPGODX/yEN8ro+sc=|))) (tag (* set (name "Carl") (e-mail "cme@acm.org") ) ) ) {KDQ6Y2VydCg2Omlzc3Vlcig0Omhhc2g0OnNoYTEyMDrVC+xM8XT++oc8Y4N f/IQ3yuj6xykpKDc6c3ViamVjdCg5OmtleWhvbGRlcig0Omhhc2g0OnNoYTE yMDrVC+xM8XT++oc8Y4Nf/IQ3yuj6xykpKSgzOnRhZygxOiozOnNldCg0Om5 hbWU0OkNhcmwpKDY6ZS1tYWlsMTE6Y21lQGFjbS5vcmcpKSkp} Ellison, et al. [Page 10] INTERNET-DRAFT SPKI Examples 10 March 1998 4. Object certificates The certificates in this section have subjects that are objects rather than keys or keyholders. As with keyholder certificates, it is not meaningful for object certificates to have the (propagate) flag. 4.1 PICS-like ratings certificate (cert (issuer (hash md5 |Ut9m14byPzdbCNZWdDjNQg==|)) (subject (object-hash (hash md5 |vN6ySKWE9K6T6cP9U5wntA==| http://www.clark.net/pub/cme/home.html))) (tag (ratings (sex "1") (violence "0") (crypto "9"))) ) {KDQ6Y2VydCg2Omlzc3Vlcig0Omhhc2gzOm1kNTE2OlLfZteG8j83WwjWVnQ 4zUIpKSg3OnN1YmplY3QoMTE6b2JqZWN0LWhhc2goNDpoYXNoMzptZDUxNjq 83rJIpYT0rpPpw/1TnCe0Mzg6aHR0cDovL3d3dy5jbGFyay5uZXQvcHViL2N tZS9ob21lLmh0bWwpKSkoMzp0YWcoNzpyYXRpbmdzKDM6c2V4MToxKSg4OnZ pb2xlbmNlMTowKSg2OmNyeXB0bzE6OSkpKSk=} This certificate should be self-explanatory. This assigns attributes to the indicated object (a web page with the indicated hash). 4.2 Virus checking certificate (cert (issuer (hash md5 |Ut9m14byPzdbCNZWdDjNQg==|)) (subject (object-hash (hash md5 |szKSlSK+SNzIsHH3wjAsTQ==| runemacs.exe))) (tag virus-free) ) {KDQ6Y2VydCg2Omlzc3Vlcig0Omhhc2gzOm1kNTE2OlLfZteG8j83WwjWVnQ 4zUIpKSg3OnN1YmplY3QoMTE6b2JqZWN0LWhhc2goNDpoYXNoMzptZDUxNjq zMpKVIr5I3MiwcffCMCxNMTI6cnVuZW1hY3MuZXhlKSkpKDM6dGFnMTA6dml ydXMtZnJlZSkp} This certificate is even simpler. The issuer is declaring that the indicated object has been checked and is virus free, in the issuer's opinion. Ellison, et al. [Page 11] INTERNET-DRAFT SPKI Examples 10 March 1998 5. Full sequence, with auto-certificate For one full example of a real certificate, the following sequence presents the public key used, calls for the verifier to hash it (and store it away, to be referred to later by its hash), gives a certificate body and then a signature (which by side-effect calls for the previous object to be stored and hashed by the signature algorithm's hash function). The example used is a temporary auto- certificate. (sequence (public-key (rsa-pkcs1-md5 (e #11#) (n |ALNdAXftavTBG2zHV7BEV59gntNlxtJYqfWIi2kTcFIgIPSjKlHleyi9s 5dDcQbVNMzjRjF+z8TrICEn9Msy0vXB00WYRtw/7aH2WAZx+x8erOWR+yn 1CTRLS/68IWB6Wc1x8hiPycMbiICAbSYjHC/ghq2mwCZO7VQXJENzYr45| ))) (do hash md5) (cert (issuer (hash md5 |+gbUgUltGysNgewRwu/3hQ==|)) (subject (keyholder (hash md5 |+gbUgUltGysNgewRwu/3hQ==|))) (tag (* set (name "Carl M. Ellison") (street "207 Grindall St.") (city "Baltimore MD") (zip "21230-4103"))) (not-after "1998-04-15_00:00:00")) (signature (hash md5 |54LeOBILOUpskE5xRTSmmA==|) (hash md5 |+gbUgUltGysNgewRwu/3hQ==|) |HU6ptoaEd7v4rTKBiRrpJBqDKWX9fBfLY/MeHyJRryS8iA34+nixf+8Yh/ buBin9xgcu1lIZ3Gu9UPLnu5bSbiJGDXwKlOuhTRG+lolZWHaAd5YnqmV9h Khws7UM4KoenAhfouKshc8Wgb3RmMepi6t80Arcc6vIuAF4PCP+zxc=|) ) ) or, in base64: {KDg6c2VxdWVuY2UoMTA6cHVibGljLWtleSgxMzpyc2EtcGtjczEtbWQ1KDE 6ZTE6ESkoMTpuMTI5OgCzXQF37Wr0wRtsx1ewRFefYJ7TZcbSWKn1iItpE3B SICD0oypR5XsovbOXQ3EG1TTM40Yxfs/E6yAhJ/TLMtL1wdNFmEbcP+2h9lg GcfsfHqzlkfsp9Qk0S0v+vCFgelnNcfIYj8nDG4iAgG0mIxwv4IatpsAmTu1 UFyRDc2K+OSkpKSgyOmRvNDpoYXNoMzptZDUpKDQ6Y2VydCg2Omlzc3Vlcig 0Omhhc2gzOm1kNTE2OvoG1IFJbRsrDYHsEcLv94UpKSg3OnN1YmplY3QoOTp rZXlob2xkZXIoNDpoYXNoMzptZDUxNjr6BtSBSW0bKw2B7BHC7/eFKSkpKDM 6dGFnKDE6KjM6c2V0KDQ6bmFtZTE1OkNhcmwgTS4gRWxsaXNvbikoNjpzdHJ Ellison, et al. [Page 12] INTERNET-DRAFT SPKI Examples 10 March 1998 lZXQxNjoyMDcgR3JpbmRhbGwgU3QuKSg0OmNpdHkxMjpCYWx0aW1vcmUgTUQ pKDM6emlwMTA6MjEyMzAtNDEwMykpKSg5Om5vdC1hZnRlcjE5OjE5OTgtMDQ tMTVfMDA6MDA6MDApKSg5OnNpZ25hdHVyZSg0Omhhc2gzOm1kNTE2OueC3jg SCzlKbJBOcUU0ppgpKDQ6aGFzaDM6bWQ1MTY6+gbUgUltGysNgewRwu/3hSk xMjg6HU6ptoaEd7v4rTKBiRrpJBqDKWX9fBfLY/MeHyJRryS8iA34+nixf+8 Yh/buBin9xgcu1lIZ3Gu9UPLnu5bSbiJGDXwKlOuhTRG+lolZWHaAd5YnqmV 9hKhws7UM4KoenAhfouKshc8Wgb3RmMepi6t80Arcc6vIuAF4PCP+zxcpKQ==} Ellison, et al. [Page 13] INTERNET-DRAFT SPKI Examples 10 March 1998 Authors' Addresses Carl M. Ellison CyberCash, Inc. 207 Grindall Street Baltimore MD 21230-4103 USA Telephone: +1 410-727-4288 +1 410-727-4293(FAX) +1 703-620-4200(main office, Reston, Virginia, USA) EMail: cme@cybercash.com cme@acm.org Web: http://www.clark.net/pub/cme Bill Frantz Electric Communities 10101 De Anza Blvd. Cupertino CA 95014 Telephone: +1 408-342-9576 Email: frantz@netcom.com Butler Lampson Microsoft 180 Lake View Ave Cambridge MA 02138 Telephone: +1 617-547-9580 (voice + FAX) EMail: blampson@microsoft.com Ron Rivest Room 324, MIT Laboratory for Computer Science 545 Technology Square Cambridge MA 02139 Telephone: +1-617-253-5880 +1-617-258-9738(FAX) Email: rivest@theory.lcs.mit.edu Web: http://theory.lcs.mit.edu/~rivest Brian Thomas Southwestern Bell One Bell Center, Room 23Q1 St. Louis MO 63101 USA Telephone: +1 314-235-3141 Ellison, et al. [Page 14] INTERNET-DRAFT SPKI Examples 10 March 1998 +1 314-331-2755(FAX) EMail: bt0008@entropy.sbc.com Tatu Ylonen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: ylo@ssh.fi Expiration and File Name This draft expires 15 September 1998. Its file name is draft-ietf-spki-cert-examples-01.txt Ellison, et al. [Page 15]