Simple Public Key Certificate Carl M. Ellison INTERNET-DRAFT CyberCash, Inc. Expires: 22 September 97 Bill Frantz Periwinkle Brian M. Thomas Southwestern Bell 17 March 1997 Simple Public Key Certificate ------ ------ --- ----------- Status of This Document This document is a slightly modified copy of the draft dated 26 November 1996 which was not submitted to the Internet Drafts directory. A second draft is in preparation at this time and will supercede this one. 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 ``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 Ellison, Frantz, Thomas [Page 1] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 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). Ellison, Frantz, Thomas [Page 2] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 Abstract With the proliferation of public key cryptography on the Internet, there arises a need for certification of keys. In the literature, the word "certificate" is generally taken to mean "identity certificate" -- a signed statement which binds a key to the name of an individual and has the intended meaning of delegating authority from that named individual to the public key. (See, for example, RFC 1422). Establishing identity is not the problem of interest. A process using public key authentication (telnet, ftp, an electronic commerce server, etc.), and verifying a public key certificate in the process, needs to check that the indicated key (i.e., the key holder) has authority to access the controlled data or perform the requested function. An SPKI certificate is an authorization certificate. It grants a specific authority to a public key rather than binding an "identity" (such as a person's name) to that key. For example, one SPKI certificate might grant permission for a given public key to authenticate logins over TELNET as user CME on host CYBERCASH.COM for some period of time. For completeness, SPKI certificates are defined below which grant "all authority of the indicated person" to a key -- and are therefore identity certificates -- but it is not clear that those will be needed. Acknowledgments Several independent contributions, published elsewhere on the net or in print, worked in synergy with our effort. Especially important to our work were: [SDSI], [BFL] and [DNSSEC]. The inspiration we received from the notion of CAPABILITY in its various forms (SDS-940, Kerberos, DEC DSSA, [SRC-070]) can not be over-rated and we must thank Butler Lampson for most of this inspiration. Significant contributions to this effort by the members of the SPKI mailing list and especially the following persons (listed in alphabetic order) are gratefully acknowledged: Steve Bellovin, Mark Feldman, John Gilmore, Phill Hallam-Baker, Bob Jueneman, David Kemp, Paul Lambert, Jon Lasser, Jeff Parrett, Ron Rivest, Bill Sommerfeld, Simon Spero. Ellison, Frantz, Thomas [Page 3] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 Table of Contents Status of This Document....................................1 Abstract...................................................3 Acknowledgments............................................3 Table of Contents..........................................4 1. Overview of Contents....................................7 2. Scope Of This Effort....................................8 2.1 Charter of the SPKI group..............................8 2.2 Areas Covered And Not Covered..........................8 2.2.1 Key and certificate storage..........................8 2.2.2 Protocols to use public key authentication...........9 2.3 Other Certificate Formats..............................9 2.4 Goals of this effort..................................10 2.5 Rejection of X.509 and ASN.1..........................10 2.6 Roles for Commercial Certification Authorities........11 2.7 CRCerts and Use of Non-SPKI Certificates..............11 2.8 Validation of Identity................................12 2.9 SPKI Certificates vs. Capabilities....................12 2.10 Chosen standard formats..............................13 3. Assumptions, Definitions and Design Issues.............14 3.1 Binding of key to principal...........................14 3.2 Directional Bindings in an Identify Certificate.......16 3.2.1 Address -> Key......................................17 3.2.2 Key -> Address......................................17 3.2.3 PGP key signatures..................................18 3.3 Meaning of a certificate..............................18 3.4 ACL versus SPKI Certificate...........................18 3.4.1 From ACL to Certificate.............................19 3.4.2 From Certificate to ACL.............................19 3.5 Certification chains..................................20 3.6 Source of a certification chain.......................20 3.6.1 Direct SPKI certificate.............................20 3.6.2 Certificate Result Certificate (CRCert).............21 3.6.3 CRCert as a Product.................................21 3.7 Role of Identity......................................22 3.8 Certificate Structure.................................22 3.9 Policy Structures.....................................23 3.10 Certifying Identity with SPKI Certificates...........24 3.11 SDSI: Global versus Local Names......................24 3.12 Certificate validity periods.........................26 3.13 Unwanted Attributions................................27 3.14 Secret Certificates..................................28 4. Certificate Formats....................................29 Ellison, Frantz, Thomas [Page 4] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 4.1 Certificate Fields....................................29 4.1.1 Subject.............................................29 4.1.2 Subject-Cert........................................29 4.1.3 Issuer..............................................30 4.1.4 Issuer-Cert.........................................30 4.1.5 ..............................................30 4.1.6 ..........................................30 4.1.7 .........................................31 4.2 Complex Policy Programs...............................31 4.3 Boundary lines BEGIN and END..........................32 4.4 Binary Format.........................................32 4.5 Date Format...........................................32 5. Field Examples..................................33 5.1 Delegation............................................33 5.2 Internet Access Control...............................33 5.3 Public Key Protected File System......................34 5.4 HTTP Access...........................................34 5.5 New fields.....................................34 5.6 SET Certificates......................................35 5.7 Identity Certificates.................................36 5.7.1 Authority flow from Name to Key.....................36 5.7.2 SDSI Name...........................................37 5.7.3 PGP-like Reference..................................37 5.7.4 Location Information................................38 5.7.5 Informational Self-binding..........................38 5.7.6 Dating Service Bindings.............................38 5.8 Authority to spend money..............................39 5.9 Comments to human readers.............................39 5.10 Group membership.....................................39 5.10.1 Authorization groups...............................39 5.10.2 SDSI groups........................................40 5.11 Other Certificate....................................40 5.12 Certificate for Blind Signatures.....................40 6. Fields......................................42 6.1 Expiration............................................42 6.2 Re-validation.........................................42 6.3 CRL...................................................42 6.4 Validity by Chained Hash..............................43 6.5 Session modifier......................................43 7. Field and Key Definitions..................44 7.1 Signature Format......................................44 7.2 Dual Signature Requirement............................44 7.3 Key Format............................................44 8. Examples...............................................46 Ellison, Frantz, Thomas [Page 5] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 9. Binary Format..........................................47 9.1 Tag definitions.......................................47 9.1.1 Non-auth fields.....................................47 9.1.2 Auth fields.........................................47 9.2 Integer format........................................48 9.3 Date format...........................................48 9.4 String format.........................................48 9.5 Algorithm definitions.................................49 9.6 Hash fields...........................................49 References................................................50 Authors' Addresses........................................52 Expiration and File Name..................................52 Ellison, Frantz, Thomas [Page 6] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 1. Overview of Contents This document contains the following sections: Section 2 describes the scope of both the SPKI working group and this particular Internet Draft. Section 3 gives necessary background for understanding the SPKI certificate structure. It details assumptions, definitions and design issues behind this structure design and is recommended reading for anyone who did not follow the discussion on the working group mailing list. Section 4 describes the SPKI certificate formats -- listing the fields in a certificate and giving two encoding methods: binary and RFC822 in ISO 10646/UTF-8. Section 5 describes SPKI fields. These are the meat of an SPKI certificate, since they carry the authority or other information being bound to a subject public key. Section 6 describes SPKI fields. These have three options, depending on whether one wants to use CRLs, short-expiration or long-expiration to control the time period of certificate validity. The three methods are shown to be functionally equivalent but differing in performance. Section 7 describes the SPKI certificate field. Section 8 gives some examples of SPKI certificate chains for practical uses. Section 9 gives details of the binary certificate format. The References section lists all documents referred to in the text as well as readings which might be of interest to anyone reading on this topic. The Authors' Addresses section gives the addresses, telephone numbers and e-mail addresses of the authors. Ellison, Frantz, Thomas [Page 7] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 2. Scope Of This Effort 2.1 Charter of the SPKI group Many Internet protocols and applications which use the Internet employ public key technology for security purposes and require a public key infrastructure to manage public keys. The task of the working group will be to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use. For purposes of the working group, the resulting formats and protocols are to be known as the Simple Public Key Infrastructure, or SPKI. The SPKI is intended to provide mechanisms to support security in a wide range of internet applications, including IPSEC protocols, encrypted electronic mail and WWW documents, payment protocols, and any other application which will require the use of public key certificates and the ability to access them. It is intended that the Simple Public Key Infrastructure will support a range of trust models. 2.2 Areas Covered And Not Covered This particular draft is concerned only with certificate and signature formats, using the certificates defined here both for verification of identity and for proof of authorization. We do not cover the other elements of a full public key infrastructure (PKI): key/certificate storage and acquisition. We also do not cover all the applications or protocols which must be modified to employ public key authentication or privacy. 2.2.1 Key and certificate storage There are several independent efforts at this time to provide a database of keys or certificates for the Internet. One, the DNS Security Working Group draft [DNSSEC], specifies an efficient key storage and distribution mechanism. It may be possible to store an SPKI certificate in a KEY Resource Record (RR) or to Ellison, Frantz, Thomas [Page 8] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 create a new RR type for SPKI certificates, under the DNSSEC design, but that effort has not been undertaken yet. The PGP key server at MIT operating both as a web page and as an e- mail driven service provides another example of efficient certificate storage and retrieval for the net at large. 2.2.2 Protocols to use public key authentication Proposals for modification of applications to employ public key authentication are proceeding independently, e.g., [PKLOGIN]. We expect to write drafts detailing the use of SPKI certificates for each of these specific applications, one at a time, but encourage other developers to do so independently as they develop strong authentication protocols or applications using public keys for confidentiality. 2.3 Other Certificate Formats We are aware of a number of actual and proposed kinds of signed public keys which, by some definition, qualify as certificates: 1. PGP signed keys 2. X.509 identity certificates, from a number of sources 3. X.509 SET (Secure Electronic Transaction) certificates 4. DNS Security Extension signed keys It is not our intention to coerce these other certificate formats into our mold, although they are welcome to switch over. The certificate structure defined below is flexible enough to accommodate all of the above. However, we recognize that a real world system will involve some mixture of SPKI and non-SPKI certificates as well as traditional Access Control Lists (ACLs). Our design accommodates these through the Certificate Result Certificate process, allowing all these to be merged into a single, simple format as far as application software is concerned. Ellison, Frantz, Thomas [Page 9] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 2.4 Goals of this effort In keeping with the design goals enumerated in section 3 of RFC1958, it is our goal to keep the SPKI certificate pruned to the minimum information necessary to accomplish the job at hand -- which is secure authentication and authorization of access control and confidentiality for the Internet. We use well tested formats with a long history of success and have chosen those which require the bare minimum of tool software so that applications remain as small and efficient as possible. We offer the bare minimum of options, in order to reduce program size and complexity. We also recognize that some kinds of certification (such as notarized identity certification) can carry risks of invasion of privacy for the individual. We have therefore designed these certificates to reveal the minimum information necessary to get the job done, whatever that job happens to be. In many cases, the user can remain anonymous in the traditional sense while exercising strongly verified authorization. 2.5 Rejection of X.509 and ASN.1 For several years certification has been assumed to mean use of X.509 identity certificates with their intricate ASN.1 formulation. We of the SPKI working group have observed that X.509 suffers from several failings, many brought on by the use of ASN.1. We also believe that any use of ASN.1 requires either difficult hand coding or the use of a large and sometimes costly ASN.1 compiler. Although the subjects of ASN.1 and X.509 have led to protracted debate on the SPKI list and elsewhere, we have made a decision to stop our own participation in the debate and avoid both X.509 and ASN.1 in the certificate structure presented here. Although the SPKI certificate format can be considered an alternative to X.509, its main value in our eyes is as both a simplification and a generalization of the certificate concept rather than as a mere change of format. Those who wish background information on this decision can consult the SPKI archives (through majordomo@c2.org). Ellison, Frantz, Thomas [Page 10] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 2.6 Roles for Commercial Certification Authorities Current commercial certification authorities (CAs) generate X.509 certificates but our rejection of X.509 should not be construed as a rejection of the role of commercial CAs. A CA has a definite role to perform, in some circumstances. What a CA offers is not a mere X.509 facility. Rather, it offers a carefully crafted policy statement, published for the world to read; well engineered physical plant security and personnel security; careful processing of individual transactions, etc. These attributes are independent of certificate format. A commercial CA could issue PGP certificates or SPKI certificates as well as X.509, should the market demand these other formats with the level of assurance a commercial CA offers, granting some authority delegation the CA is qualified to perform. 2.7 CRCerts and Use of Non-SPKI Certificates Few certificates live in a vacuum. Most relate to some other certificate so that the process of validating a certificate involves validating a thread or sub-mesh of certificates embedded in a connected mesh. We expect some certificates in such a thread to be non-SPKI. At the same time, we desire to save application developers from having to parse all the various certificate types (especially X.509). The result of certificate validation can be a single access permission but in the process of performing a validation, the verifier has determined and can record a period of time during which the same answer will occur (because none of the certificates and CRLs involved will have expired). The verifier can therefore cache the certificate result with its own expiration time. It can also sign that certificate result cache entry, to generate an SPKI certificate giving the specific access permission to that key for that period of time. We call this last process the generation of a Certificate Result Certificate (CRCert). The CRCert is presumably valid only at the verifier itself or possibly its siblings. This process opens the possibility that a large enough site could maintain a single trusted machine capable of evaluating non-SPKI certificates and elaborate policies, yielding single SPKI certificates which the working servers actually check, saving them the code to understand all certificate formats and policies. Ellison, Frantz, Thomas [Page 11] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 2.8 Validation of Identity "Without a KMI [Key Management Infrastructure] of trusted certificate authorities, users cannot know with whom they are dealing on the network...." [IWG] "..identity-based certificates create an artificial layer of indirection between the information that is certified (which answers the question "who is the holder of this public key?") and the question that a secure application must answer ("can we trust this public key for this purpose?")." [BFL] An SPKI certificate delegates authority directly to a public key. It is the responsibility of the delegator of that authority to verify the identity of the key owner, if that is important, prior to issuing an SPKI certificate. The identity thus determined need not be represented in the certificate itself beyond the public key. Traditional identity certificates could have a role at this step but it is not always necessary to use identity certificates to validate identity. [IDENT] (See section 3.6.1 for a discussion of bypassing identity certificates.) It is also not always sufficient to validate identity through an identity certificate. Any substantial pool of users will include those with the same common name. Therefore, some information needs to be added to those names to make them unique before identity certificates can be issued. The information added may not be known to the person or entity validating the certificate in question, leaving the verifier with an ambiguous (and therefore worthless) identity mapping. Only if the subject of an identity certificate communicates his unique name over a secure and pre-authenticated channel to the certificate verifier, can the verifier know which certificate to honor for the intended person -- but if that process is followed, the subject can communicate his public key over that same secure, pre-authenticated channel and avoid certificates entirely. 2.9 SPKI Certificates vs. Capabilities An SPKI certificate is closer to a "capability" as defined by Butler Lampson et al. than to an identity certificate. There is the difference that in a capability system, the capability itself is a Ellison, Frantz, Thomas [Page 12] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 secret ticket, the possession of which grants some authority. It is anonymous (cash rather than a check). Therefore, if you grant authority to read a capability, you have delegated the ability to use it. An SPKI certificate identifies the specific individual or group to whom it grants authority and therefore the ability to read the certificate grants no authority and the certificate itself does not need to be as tightly controlled. 2.10 Chosen standard formats We have adopted a stream-oriented binary format, easy for parsing in normal languages such as C. We provide (in a separate file) C programs for translating from binary format to RFC822 style format and back. We recommend using ISO 10646/UTF-8 for all text, since it includes ASCII as a subset and if the text fits within ASCII, no difference is noticed. We have kept options to a minimum, to simplify parsing and use of certificates. We provide some field definitions which we know will be useful but leave open a method for application programmers to define new fields as the need arises. As such become popular, we plan to amend this document to define tag fields and specific formats for those new fields. There was a strong move, inspired by [SDSI], to use S-expressions as the readable format. S-expressions provide some interesting possibilities, especially when programs are part of the certificate (as with [BFL]), but we have chosen not to require their use for fear of forcing all applications to implement list-processing primitives. Ellison, Frantz, Thomas [Page 13] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 3. Assumptions, Definitions and Design Issues There were a number of discussion topics involved in the design of the SPKI certificates and we summarize them here for the reader who was not part of the SPKI discussion. This section should at least be skimmed by even the reader with a solid grounding in classical (identity) certification. Some of these might be new concepts. Some provide definitions for terms which traditional discussions of certification frequently leave undefined. 3.1 Binding of key to principal The most important issue is the notion of the binding of a key to a principal. By PRINCIPAL, we mean an entity (e.g., person, processor, process, device (such as a printer), ...) which supplies a service or requests action in a distributed computer system. Discussions of certification frequently speak of binding of keys to an "identity" (specifically, under X.509, to a Distinguished Name) as if the "identity" were the same as the principal and as if the identity certificate accomplished the binding of key to principal. We observe that the binding between a public key and a principal has nothing to do with certificates. Here we distinguish between a principal and its name or "identity", however one defines that latter term. For any public key cryptosystem to work, it is essential that a principal keep its private key to itself. In the case of a human being, this might involve keeping the private key encrypted under a high-entropy passphrase and storing it only on the person's own personal computer or floppy disks. Some humans might even keep the private key in a tamper-resistant PCMCIA card which will never release it and will in fact destroy it after too many failed attempts to gain access. In the case of a network node, this might involve keeping the private key in a tamper-resistant cryptographic processor which generated it and which will destroy it if tampering is attempted. If the principal does not keep the private key protected (if the private key gets out to others to use) then one can not know what entity is using that key and no certificates will be able to restore Ellison, Frantz, Thomas [Page 14] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 the resulting broken security. Therefore, we are forced to assume that all private keys are kept private and bound tightly to the one principal to which they belong. We will have to provide for methods of announcing the compromise of such private keys whenever this assumption proves false, but we must assume that unless such notification is delivered, each private key is secure and attached to its owner. Note: We have specifically included the possibility for a holder of authority to delegate that authority on his own, in order to reduce if not eliminate the motivation for one principal to loan a private key to another. We do not expect every person, process and device in the Internet to employ true tamper resistance. Many people will keep and use private keys on an insecure personal computer or workstation. However, we are forced to assume protection of the private key or give up any notion of cryptographically strong authorization tests. This assumption binds a key to one principal. That key is then a surrogate for the principal, in cyberspace. In the language of [SRC-070], the key speaks for the principal. This is true even without establishing the identity of that principal in any other way. That binding of key to principal does not require any certificates. It is a tautology. For each key, there is one principal, identified as "the keyholder". The keyholder has sole possession of the private key by definition and could be identified by that key, but that key is secret. There is only one private key to match a given public key, so the keyholder can be identified by the public key just as uniquely. Similarly, there is only one public key which hashes to a given secure hash (by definition of "secure hash", assuming we are limited in computation power), so the secure hash of a public key can also be used to identify the keyholder. DEFINITION: Keyholder -- a principal who holds a given private key. The private key is indicated by either its corresponding public key or a secure hash of that public key. Every key has a keyholder, by definition. There is no implication in the word "keyholder" that anything else is known about this principal except the fact that it holds the indicated private key. Ellison, Frantz, Thomas [Page 15] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 Without certificates, we might not know anything else about the principal (such as name, gender or even if the principal is a living being) but we do know enough to link together separate messages from the same principal. For some purposes, that is sufficient identification (for example, when a person is first encountered on- line via signed messages and there is no intention of linking that person to any physical being, only to his or her own other messages). However, there are other applications for which the ability to link together separate messages from an anonymous source is not adequate and therefore for which certificates are required. 3.2 Directional Bindings in an Identify Certificate When the authorization is specific (e.g., "the keyholder is permitted FTP access to FTP.CLARK.NET as user CME"), the nature of the delegation of authority is clear. However, when a certificate is used to bind identity in some form to a public key, as frequently occurs in the traditional certification literature, there is sometimes confusion about what is specifically being delegated. There is some transfer of authority between the named principal and the public key, but the direction of that transfer is left unspecified. The traditional certification literature was written in the days before cyberspace exploded. In those days, all relationships and all authority were in the physical world and therefore any transfer of authority was from the physical world into cyberspace. Certificates of that time were assumed to transfer authority from a named physical entity to a public key. Now that a significant number of persons are on-line, it has become common for people to establish relationships on-line. Any authority tied to those relationships lives in cyberspace and if it is to be linked to a physical entity, a certificate would transfer the authority from a public key to a physical entity. With the addition of this flow of authority from cyberspace to physical space it is important to recognize that bindings are not bi- directional. It is imperative that an identity certificate capture the direction of the flow of authority. Take for example a certificate binding a public key and an e-mail address. Ellison, Frantz, Thomas [Page 16] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 3.2.1 Address -> Key That certificate might be intended to mean: "The person who is known to the world as the one who logs in and exchanges mail as xxx@yyy.zzz has the indicated key." In this case, authority flows from the e- mail address (as a name for a physical being) to the key and the certificate should be signed by the system administrator responsible for that e-mail address creation. This is precisely the situation with [DNSSEC]. In this case, we must be concerned about the care with which the zone owner verified possession of the private key by the indicated user as well as about the general trustworthiness of the zone owner. In general, we note that when authority flows from physical space into cyberspace, one must establish trust in the physical- space entity delegating that authority. This leads to the real work, legal contracts and expense of a commercial Certification Authority establishing trustworthiness and being explicit about the process used to verify the identity and key of the key holder. The only sure way to bypass this risky and complex process is when the physical space entity is one's self -- that is, when one generates his or her own certificates. 3.2.2 Key -> Address That certificate might be intended to mean: "I, the person bound to this private key, can receive encrypted mail at this e-mail address". In that case, authority is flowing from the key (as surrogate for the (unnamed) principal) to the e-mail address and the certificate should be signed by the key itself. We can trust this statement without qualification because the owner of the key is the final authority on where he or she can receive e-mail. There is no motivation to lie about this. Mail sent to the wrong place will not reach the keyholder and the person it does reach will not be able to decrypt it. In general, we note that when authority flows from cyberspace into physical space, a key itself is usually a final authority and certification is then relatively simple and secure. Ellison, Frantz, Thomas [Page 17] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 3.2.3 PGP key signatures In the case of PGP, which usually binds keys and e-mail addresses, it is probably the (Address->Key) interpretation which users assume although the signers are not the owners of the appropriate DNS zone, so they are not authorized to make the statement they are assumed to be making. PGP attempts to make up for that lack of authorization by allowing multiple witnesses to sign a key. Common practice with PGP calls for the owner of the key to sign the association (UserID,key) also -- in which case the (Key->Address) interpretation holds as well, although that interpretation is usually overlooked by PGP users. 3.3 Meaning of a certificate As shown in the PGP example above, identity certificates rarely have explicit meanings. RFC1422 certificates had meanings specified in part by a policy statement on file in the office of a PCA (Policy Certification Authority). However, those meanings applied to an entire zone of a tree of certificates and could not specify for each certificate the direction of transfer of authority, as in the example of the previous section. More to the point, those identity certificates were not intended to delegate any specific authority, as SPKI certificates are. We have chosen to make the meaning of a certificate explicit as a required field in each certificate. Since an SPKI certificate transfers authority to a key, the meaning field is referred to here as and must specify the specific authority being delegated by the certificate. If the certificate is an identity certificate, the direction(s) of transfer of authority is specified as well. 3.4 ACL versus SPKI Certificate An Access Control List (ACL) is a mapping from some named principal or named group of principals to one or more access permissions. If a principal is identified only via an identity certificate, any process faced with a request to give access to that principal must also check an ACL or its equivalent to determine whether or not to grant access. The ACL is central to secure operation and must itself be kept very securely. The ability to write an ACL, in systems which use them, is Ellison, Frantz, Thomas [Page 18] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 the ability to have any access to the controlled resource. 3.4.1 From ACL to Certificate A process or device which grants access can keep an ACL in protected storage. As long as this is possible, the straight ACL is a very efficient mechanism. If the ACL were to grow beyond the capacity of protected storage or if it would need to be shared with sibling processes or devices, then it might need to be protected cryptographically by digital signature. One can digitally sign an entire ACL, for example to back it up in an insecure place. Alternatively, one can sign individual ACL entries. In both cases, the signature key used is that of the process or device which owns and must trust the ACL. No certification of that key is necessary, as long as the same process both generates and reads ACL entries. If individual entries are signed and if the semantics of an ACL is independent of order of its entries, then the signed entries can be given individually to the principals to whom they grant access. Those principals are specially motivated to preserve their own ACL entries and present them to the verifier when requesting access. For large ACLs, this could substantially reduce the data management burden of an access-granting process. The builder of an ACL has a choice of how to name the principals involved. One choice is to use a key or its hash to identify the keyholder. A signed ACL entry of that form is an SPKI certificate. 3.4.2 From Certificate to ACL An SPKI certificate grants a specific authority to a key. Once a verifying process reads such a certificate, it must validate it (by checking its signature) and probably validate a chain or mesh of authority certificates in order to determine that the delegation can be trusted. Once the verifier has established that trust, it can generate what we call a Certificate Result cache entry -- a data structure kept in trusted memory, noting the delegation of the given authority to the given key. That cache entry is equivalent to an ACL entry, using the key as a name for the principal. If that cache entry is then signed Ellison, Frantz, Thomas [Page 19] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 and returned to the supplicant as an SPKI certificate, we call the result a Certificate Result Certificate (CRCert). 3.5 Certification chains A single certificate is often not adequate to provide assurance that the given principal is authorized to receive the access or service it is requesting. The certificate grants or delegates some authority from an issuing key to a subject key. This leaves open the question of whether the issuing key has the authority to perform that grant or delegation. Unless the issuer is the same entity as the verifier of the certificate, this latter authority needs to be checked via a certificate or ACL entry. 3.6 Source of a certification chain There can be only one source of a chain of authority: the verifier of the certificate chain. Even if the world may think there is a globally recognized source of a chain of authority delegation, that source must be trusted or not by the certificate verifier. That declaration of trust calls for a certificate (or ACL entry, if memory is adequately protected) issued by the verifier, making the verifier the source of the chain. Under this model, all verifiers are at least potentially also issuers of certificates. There are two cases in which this might be literally true. 3.6.1 Direct SPKI certificate A verifier (or the system administrators who control a verifying process) can issue direct SPKI authorization certificates for a given public key. (We anticipate this being a very common occurrence.) For example, one often gets a corporate account on some workstation or LAN by physically appearing at the office of a corporate system administrator and being introduced as a new employee. The employee chooses a login name and a new account is created with a password to be changed on first login. During this process, the new employee could present not only a choice of login name but also a public signature key -- and the system administrator could generate an SPKI TELNET and FTP certificate for the new user on the spot. Ellison, Frantz, Thomas [Page 20] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 For another example, one normal process of setting up a home ISP account involves filling in an on-line form, over a dial-up line, with or without custom software running on the user's PC to do the registration. That form typically communicates a credit card account number to be used to pay the ISP's monthly service fees together with whatever identifying information is needed by the credit card company. One could provide a public key at the same time, in the same form, and have the ISP generate the SPKI certificate for access appropriate to the kind of account being purchased. 3.6.2 Certificate Result Certificate (CRCert) As noted in Sections 2.7 and 3.4.2, the process of verifying permission to gain access might involve the testing of multiple certificates -- perhaps an identity certificate chain as well as an authorization certificate or set of them, representing signed ACL entries. Once that process is complete, the verifier has a single result -- positive or negative. If the result is positive, the verifier can also know the validity period of that result. This information can be cached by the verifier as an ACL (with expiration time) or converted into an SPKI certificate, issued by the verifier. We refer to such a certificate as a Certificate Result Certificate or CRCert. Examples of CRCert formation are given in Section 8 of this document. 3.6.3 CRCert as a Product One use of a CRCert is to convert from one certificate format to another. For example, one might invest in an X.509-aware certificate processing engine but not wish to burden all access-granting applications with that volume of code and with the validation of chains of certificates. CRCerts give the option of validating the X.509 certificate chain in an off-line process within the same facility as the access-granting application and reducing that chain to a single CRCert which expires at the time of the earliest certificate (or CRL) of the chain. That CRCert is valid only within the trust domain of the key which signed it -- typically a single computing facility or LAN -- but can be used in place of the full certificate (and ACL) chain. One might even set up a commercial enterprise whose purpose is the translation of certificates, certificate chains and CRLs into SPKI Ellison, Frantz, Thomas [Page 21] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 certificates, but of course one then introduces the question of trust of this commercial enterprise. 3.7 Role of Identity The fact that a verifying process cares only about a specific authority delegation to a specific key has led the design of an SPKI certificate to provide precisely that information. However, there are other activities which care about the identity of the principals involved. There is likely to be an audit log, for example, in which all accesses are recorded and that log may need to be interpreted by a human security officer whose desire is not to grant access but rather to locate a given principal in physical space. SPKI permits relatively anonymous secure access but it does not require anonymity. A number of certificate options are presented below for mapping from a key to an individual principal in physical space. These mappings, by themselves, do not delegate authorization so they are considered informational. One could imagine policies for granting access which require the existence of such a location certificate as part of the principal's certificate package but we give no examples of such policies. 3.8 Certificate Structure An SPKI certificate has five conceptual fields: ISSUER: the public key of the issuing party, both as a means for verifying the certificate signature and as a name for the issuing principal. SUBJECT: the public key receiving authority via this certificate. AUTHORITY: the specific authorization(s) being delegated in this certificate. Section 5 gives details about fields. VALIDITY: at least an expiration date but possibly a more complex procedure for determining certificate validity. Section 6 gives details about validity fields. SIGNATURE: a signature by the issuer (and, optionally, by the subject) of the fields above. Section 7 gives details about signature fields. Ellison, Frantz, Thomas [Page 22] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 A valid certificate can be represented by three quantities: (,,) and by reference to these, policy structures can be constructed. This certificate is taken to mean that " says that has attribute ", where is typically a specific authorization. One could form indirect certificates as well, of the form: (,(,,)) meaning " says that says that has attribute ", but we do not advocate such constructs -- instead preferring to establish enough trust in to be able itself to assert the 's permission and map that construct into: (,,) 3.9 Policy Structures [BFL] introduces a language called PolicyMaker in which one can express security policy statements -- the specific certificate requirements by which a given action will be authorized. The actual requirements are written in a safe language which program is then bound to a key or set of keys by an issuer's signature. It is possible to include a PolicyMaker assertion or policy as an of an SPKI certificate. However, we leave that activity to the authors of [BFL]. In a separate document, we describe a simple language consisting of lines of the form: (,,) where and can be: 1) internal variable names to indicate equality of keys between certificates; 2) explicit keys; or 3) parameter names to allow specification of simple policies to cover most cases. These Ellison, Frantz, Thomas [Page 23] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 lines would be interpreted much as one interprets a PROLOG program, but are much more tightly constrained, to simplify both understanding and execution. If such a program occurs as the of an SPKI certificate, that certificate constitutes a promise by the to grant access (or generate a certificate granting access) in return for certificates satisfying the templates. Such a process was mentioned in sections 2.7, 3.6.2 and 3.6.3 above. However, this signed policy statement (or one in PolicyMaker) gives the advantages: 1) that the interpreter does not have to store all such policy statements; 2) that a single processor can generate CRCerts from a wide variety of policies; and 3) that the user of that CRCert processor can know ahead of time exactly what certificates to present and can pre-validate them. 3.10 Certifying Identity with SPKI Certificates It is possible to certify identity with an SPKI certificate, although we are skeptical about the value of a traditional identity certificate (cf., section 2.8). Section 5.7 includes lines for establishing and making explicit the common kinds of identity association. 3.11 SDSI: Global versus Local Names [SDSI] recognized that all names are local, even those generated by an allegedly global CA. More importantly, for a name to be meaningful, it must be known by the person or program using it (the verifier) and unambiguously associated by that verifier with the person or object (the subject) to which it refers. In the case of a person as verifier, this name space is inherently limited in size and complexity by the capacity of a human memory. SDSI achieves a global name space by linking together local name spaces. That is, two people, Alice and Bob, may each have a friend they call Carol. To each of them, the name (carol) is used. If David knows both Alice and Bob, then David might have occasion to speak with each of them about Carol. Not necessarily having met Ellison, Frantz, Thomas [Page 24] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 Alice's or Bob's Carol, David uses the names (alice's carol) and (bob's carol). David might be able to tell that Alice and Bob know the same Carol by inspecting the certificates issued by Alice and Bob for Carol: (K-alice,K-carol,"(carol)") (K-bob,K-carol',"(carol)") If K-carol = K-carol', then Alice and Bob know the same Carol. However, Alice and Bob are free to reorganize their local name spaces at will, without notifying anyone who might have learned name mappings, so this equality of keyholders can be considered valid only for the shorter of the two certificate validity periods. Under SDSI, a name might be an individual or it might be a group. One could think of an individual as a group of one member, in which case all SDSI names can be thought of as groups. The entity defining that name is responsible for issuing certificates binding a key to the name or declaring that the principal (the key) is a member or not a member of the named group. As names get communicated from entity to entity, they get longer (not unlike UUCP delivery addresses). The "'s" of the examples above is only for human consumption and is not actually present in a SDSI name -- so one might have a name, for example: (carl jon zorak) which identifies a keyholder also known as (tom mary kathleen) if the keyholder's given name were Kathleen and Jon's nickname for her were Zorak. The binding of a key to a SDSI name requires a certificate for each name in the list, issued by the preceding entity. That is, if the verifier has key K0 and Kathleen(=Zorak) has key K1, the example above would include certificates: (K2,K1,"(zorak)") (K3,K2,"(jon)") (K0,K3,"(carl)") (K4,K1,"(kathleen)") (K5,K4,"(mary)") (K0,K5,"(tom)") Ellison, Frantz, Thomas [Page 25] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 and might include certificates such as: (K0,K1,"(carl jon zorak)") or (K3,K1,"(jon zorak)") although those latter certificates should be valid only for as long as the shortest validity of the underlying certificates. 3.12 Certificate validity periods Our experience with credit cards has influenced the way we consider validity periods of certificates. A credit card is issued with an expiration date 1 to 3 years later than the date of issue, yet one can revoke a credit card and have that revocation be effective within a day of the request. That credit card has a validity period of one day (or less) in spite of its expiration date. At one time, credit card validity was verified at a checkout counter by looking the card number up in a book of revoked cards. The validity period of a card not listed in such a book was the time until that book was updated and the card had to be looked up again. This practice has migrated into the digital world through the CRL (Certificate Revocation List) construct. Modern systems accepting credit cards perform an on-line validity check, in which case the validity period can be very short and is determined by the time it takes to make a database update from a report of a lost or stolen card. An authorization certificate can be stored in read-write storage, since it is protected from tampering by its digital signature(s). Therefore, it has a third option for short-term validity checks. It can hold a guaranteed validity time which is re-written as needed during an on-line check, but can be trusted without the on-line check until that time. All of these methods of validity checking are functionally equivalent but they have different performance impacts. CRL: If one can afford to keep a copy of the CRL, there is the communications load of accepting periodic additions to the CRL (hopefully very small and relatively infrequent). Each verification then requires a local memory reference. Ellison, Frantz, Thomas [Page 26] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 If the CRL must be delivered by the supplicant or fetched from an on-line source with each verification, then the communications load of CRL usage is proportional to CRL size and can become very high. On-line: The communications load for on-line checking is constant. Periodic-revalidation: If a certificate is used more than once during its validity period, periodic-revalidation provides a caching effect, saving the communications load for on-line checking. It also permits the supplicant to perform the on-line check and distributes that load away from the verifier. Because of the time it takes to communicate and the need to allow for clock skew, a validity period can never go to zero. The shorter the period, the less risk an issuer runs of having a withdrawn authorization active in the world. The longer the period, the less communication and revalidation overhead is incurred. Choice of validity period is left up to the issuer of the certificate. 3.13 Unwanted Attributions There is a potential problem that a certificate might be issued which the keyholder does not want. For example, a keyholder, Alice, has a signature key, K, being used to sign digital lab notebooks for later use in patent applications. That key is certified as hers by her company through an SPKI identity certificate with an EMPLOYEE field. Bob learns Alice's public key and builds a certificate using his own name and her key, getting it signed by some reputable commercial CA. Now when it comes time to dispute prior art on Alice's patent(s), Bob produces his certificate and claims that Alice had copied not only his work but his private signature key. For another example, Bob could give Alice read-write access to a directory structure Bob intends to corrupt, blaming that corruption on Alice. To resolve this, some certificates should be signed by the as well as by the . An identity certificate is one such. At Ellison, Frantz, Thomas [Page 27] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 this time we leave that option up to the builder of certificates, as indicated by the DUAL-SIG option. 3.14 Secret Certificates A concern was raised on the list about possible leaking of sensitive information in the contents of a certificate. Should it ever develop that a certificate needs to be issued whose is itself private information, such fields can be encrypted in a key known only by the intended verifier before being returned to the subject. Presumably the subject knows the effect of the certificate but anyone observing the certificate on the network would be prevented from gaining knowledge of it. Similarly, an entire certificate could be encrypted in a key known only to the issuer, with the same effect. Ellison, Frantz, Thomas [Page 28] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 4. Certificate Formats We define a single certificate format, in binary, but rather than pepper this document with pictures of binary structures, we define an equivalent format in ISO 10646/UTF-8 (ASCII) and use that format in the body of this text. In a separate file, we provide C programs for converting between binary and UTF-8 formats. We take as a rule that the thing signed is the binary thing transmitted, even if it is expressed in UTF-8 format. 4.1 Certificate Fields The following fields make up an SPKI certificate. 4.1.1 Subject SUBJECT: , The subject of a certificate is a keyholder and is indicated by the hash of the subject's public key. By hash we mean a pair of values: hash algorithm name and hash value. The actual key is assumed to be in the verifier's possession although a given protocol might call for transmitting that key during the same communication that carries the certificate using it. 4.1.2 Subject-Cert SUBJECT-CERT: The subject-cert field gives the location of the subject public key and a self-signed validity certificate for that key. The of that certificate can be anything -- e.g., a comment. If the private key is ever compromised, then this self-signed certificate is revoked or not renewed, depending on the keyholder's choice of validity method. Such a location might be a URL or domain name (for lookup in the DNS database). A self-signed validity certificate has no SUBJECT-CERT field. A is a text string. Ellison, Frantz, Thomas [Page 29] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 4.1.3 Issuer ISSUER: , The issuer of a certificate is a keyholder and is indicated by the hash of the issuer's public key. 4.1.4 Issuer-Cert ISSUER-CERT: The issuer-cert field gives the location of the issuer public key and any certificate(s) needed to establish the authority to do the delegation represented by this certificate. 4.1.5 As described in section 5, this class of field includes a large number of options and carries the meat of a certificate. There are fields for each kind of authorization or authority being delegated as well as for establishing identity certification or simply providing information. An SPKI certificate is assumed to contain 0 or more fields, but we expect most to contain only one. 4.1.6 As described in section 6, this class of field includes options. A certificate can have no field and be valid forever, have a simple expiration date, or require periodic revalidation. That latter can be achieved by having a certificate itself revalidated or by having the certificate not show up on a CRL. The "validity time" of a certificate is the time until it expires or needs to be revalidated or needs a new CRL update, whichever comes first. The latter two cases are periodic and that period is the certificate's "validity period". Ellison, Frantz, Thomas [Page 30] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 4.1.7 There is one option for certificate signature. Every SPKI certificate must be signed by the . However, if the certificate body contains the DUAL-SIG field, then the certificate must also be signed by the in order to be valid. 4.2 Complex Policy Programs A simple certificate is assumed to be part of a single thread of authorizations -- a chain. There are policy programs which have been considered [BFL] which would refer back to more than one certificate and therefore not be part of a single chain. The node which indicates which certificates to apply to which program in order to acquire that program's need not be a certificate itself. That is, there is no reason for it to be signed. All of its integrity protection exists in the protection of the program which is executed and of the individual certificates which are that program's parameters. However, it may be useful to consider it a certificate for the purpose of storage and display of certificate meshes (chains). A complex policy "certificate" would have more than one and would refer to a rather than state an . The parameter to such a program is a certificate, granting in effect a partial authority. That is, the program is used to combine the effects of multiple authorizations. For that purpose, let us define: PP-PARAM: ,, giving Policy Program Parameter number n, and PP-PROG: , where gives the node or TCP port (or other location) at which one submits the group of certs (ie., this block) in order to get a specific permission or, more likely, a CRCert for that permission. Ellison, Frantz, Thomas [Page 31] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 4.3 Boundary lines BEGIN and END Any multiple-line object, such as a certificate body or a signature, is bounded by the lines: BEGIN: <(possibly empty) comment or name> and END: <(possibly empty) comment or name> Name matching is not performed but one can use the same name or comment on corresponding BEGIN and END lines in order to make a set of certificate bodies more readable to a human examining it. There is no occasion to nest BEGIN-END pairs. The hash of an object includes the BEGIN and END and their comments. 4.4 Binary Format Each tag is assigned a binary value. For now we use single unsigned bytes but reserve bytes in the range 128-255 to indicate that the value is extended by one more unsigned byte. It is unlikely that there would be a need for more than 2^15 different tags -- especially given the ability to define tags in UTF-8. The table of tag definitions is given in section 9 and is left incomplete at this point, until the list reaches consensus on which fields are viable enough to be given binary encodings. 4.5 Date Format Dates in binary are assumed to be in the form of a 32-bit unsigned integer, giving seconds since 1970-01-01.00:00:00 UTC. In UTF-8 (ASCII) the date and time can be expressed in the form: YYYY-MM-DD.HH:MM:SS assumed to be UTC, with lower significance time fields optional and taken to be 0 if missing. (We assume that this standard will be supplanted by something better prior to the year 2106.) Ellison, Frantz, Thomas [Page 32] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 5. Field 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 which verifies a certificate, e.g., to grant access. Listed here are fields we know to be useful. For cases we have not anticipated, there is a field "AUTH:" to handle arbitrary new fields. Not all of the fields described below have binary tag formats, in which case "AUTH:" format needs to be used (or the binary tag list needs to be updated). When one grants some authority, it might be desired also to grant the permission to delegate that authority to others. Each is assumed to have a modifier, "MAY-DELEGATE:", specifying the 's permission to delegate. 5.1 Delegation MAY-DELEGATE: MAY-DELEGATE is a modifier of any , specifying whether the has permission to delegate that to other keys. is an integer in the range [0,254], giving the depth of delegation permitted, or the value "infinity" (represented in ASCII as "*" and in binary as 255). Verification of a certificate chain requires the of a 's cert to be less than the of the 's cert (where (*)<(*) and ((*)-1)=(*)). If there is no MAY-DELEGATE modifier, then is assumed to be 0 and the cert in question does not grant permission to delegate. 5.2 Internet Access Control FTP: , TELNET: , USER: , These fields give permission to perform the indicated protocol on the machine as user , and maybe permission to Ellison, Frantz, Thomas [Page 33] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 delegate that authority (or a subset of it) to others. The USER statement stands for *: -- ie., all protocols. 5.3 Public Key Protected File System PKPFS:/// () PKPFS://// () refers to a hypothetical distributed file system whose access is controlled by public key challenge/response. If ends in "/" (as in the second example), access is to an entire subtree. Otherwise, it is to an indicated file (or set of files via "*"). is a set of letters: R: for read W: for (over-)write A: for add to directory (or append to file) D: for delete Such a file system has not been constructed and may never be, but this example is included to illustrate the potential of field construction. 5.4 HTTP Access HTTP:/// HTTP://// Following the pattern for PKPFS, but using a real protocol, we can permit read access to web pages -- either a selected set of pages (via "*") or an entire directory subtree. 5.5 New fields AUTH: ,, The final arbiter of what needs to be an and what parameters a particular needs is the designer of the code which verifies a certificate. For those who want to define new fields without waiting for the assignment of tag numbers, we provide the AUTH: tag. Ellison, Frantz, Thomas [Page 34] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 is a text version of the new tag. There is no attempt to make globally unique. It is assumed to be defined and unique only among certificates from a given . is the number of parameters to follow. are N (text or byte) string parameters. The verifying application is responsible for establishing formats. There is no desperate need for different applications to use the same format so there is no need to standardize definitions before they are first implemented. In Internet tradition as new formats are invented for a particular purpose, they can be published and, if found to meet the needs of others, generally adopted. Once they are adopted by enough applications, they can be codified in the form of a binary format with its own tag definition. 5.6 SET Certificates The SET (Secure Electronic Transactions) standard work has come up with authorization and identity certificates using X.509 format. The corresponding SPKI formats (for CRCerts of SET certificates) might have lines: SET-BLIND: , identifying card holders, where is effectively a random value used as a key in keyed-MD5 for generating from the card holder's Primary Account Number; SET-MER: , identifying merchants, where is the name of a credit card brand and is the ID for that merchant assigned by that card association; SET-CCA: identifying cardholder certification authorities; SET-MCA: identifying merchant certification authorities; SET-PGWY: identifying an approved payment gateway; SET-PCA: identifying a payment gateway certification authority; Ellison, Frantz, Thomas [Page 35] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 SET-GCA: identifying a regional certification authority (for approving CCA, MCA or PCA); SET-BCA: identifying a brand certification authority (for approving GCA); SET-ROOT: identifying the SET root authority. 5.7 Identity Certificates A traditional identity certificate doesn't fit the SPKI model. It lacks an explicit transfer of authority. One can assume that it is intended to imply that all the authority of the indicated person is to transfer over to the subject key, but that is both unstated in the certificate (and in many CA policy statements) and a very broad delegation of authority. However, some policy definitions will require identity certification. The identity certificate forms listed below cover the most frequently cited cases. 5.7.1 Authority flow from Name to Key EMPLOYEE: , , implies that the subject is an employee named of (with optional further specification by division of the company). POSTAL-PATRON: ,
signed by the post office, implies that the indicated person has demonstrated to the post office the possession and use of the associated private key (possibly through a mail exchange). TELEPHONE-CUSTOMER: , signed by the phone company, implies that the indicated person has demonstrated to the telephone company the possession and use of the associated private key (possibly through a message exchange via modem). Other delegations of authority should be structured similarly, if any others are of interest. These are the ones the literature most often Ellison, Frantz, Thomas [Page 36] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 cites. In all of these cases, a COMMENT field can be included to give an explanation of how the association between key and person was established. 5.7.2 SDSI Name NAME: implies that the issuer uses the name for the subject keyholder (i.e., for the subject key), according to SDSI usage. That is, is strictly local for the issuer [SDSI]. The can be a single name or a SDSI name chain. For example, (carl ron butler) means that whoever the issuer knows as "carl" has a local name "ron" for some entity which has a local name "butler" for the entity with which the issuer associates the key. If this certificate is self-signed (if = ) then it can be taken to mean "I go by the name " or "I prefer to be called ". (See also MEMBER and NON-MEMBER in Section 5.10.2 for SDSI group definitions.) 5.7.3 PGP-like Reference KNOWN-TO-ME-AS: , is the commonly assumed meaning of a PGP key signature and implies that the subject principal (ie., key holder) is known to the issuer under the (presumably global) name . The optional field indicates the degree to which key ownership has been verified, for example: signed challenge in person key fingerprint net contact ranging from having signed a random challenge while the issuer watched the process to the issuer's never having met the person except over the net. Ellison, Frantz, Thomas [Page 37] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 5.7.4 Location Information LOCATION: RESPONSIBLE-PARTY: For some purposes, such as interpretation of an audit log, it is necessary to locate a keyholder (device or person) in physical space. This binding of information to the keyholder (therefore, to the key) is provided by a security office, a physical plant office, inventory control office, etc., which needs to issue and sign the LOCATION or RESPONSIBLE-PARTY certificate. If there arise programmatic interpretations of such location fields, then there might be a need to specialize them by choice of tag name, but as long as these fields are for human consumption only, all specialization (e.g., person's name, room number, license plate of vehicle, ...) can be indicated in the free form text parameter. 5.7.5 Informational Self-binding MAILTO: lists an address at which the keyholder can receive e-mail. This transfers authority from key to e-mail address, not the other way around. These certificates should be signed by the subject key -- that is, the issuer and subject should be the same. (See section 3.2.2) 5.7.6 Dating Service Bindings There is some information which might be certified for a fee by a commercial on-line dating service: MARITAL-STATUS: BIRTH-YEAR: HEIGHT: WEIGHT: PICTURE: , Ellison, Frantz, Thomas [Page 38] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 5.8 Authority to spend money SPENDING-AUTHORITY: , indicates that the subject has authority to authorize spending up to per purchase order. The purchasing authority can be limited to a particular kind of purchase, optionally, but that optional field will have to be interpreted by humans at this point. No guidance is given for its contents. If (cf., 5.1) is greater than 0, the subject is authorized to delegate SPENDING-AUTHORITY to others under the rule that the delegated be less than the subject's and that the delegated be less than or equal to the subject's while the (a text field) is the same or more limited. Interpretation of that last might require human intervention. (If human intervention is required in the interpretation of a SPENDING- AUTHORITY certificate chain, it might be prudent always to generate a CRCert of the result.) 5.9 Comments to human readers COMMENT: These fields are completely unconstrained and included by the for human interpretation. 5.10 Group membership 5.10.1 Authorization groups DELEGATE-ALL: A group is an entity to which authority is delegated in order for that authority to be delegated to all group members. If authority is delegated strictly via SPKI certificates, the group declares that is a member by issuing a: (,,"DELEGATE-ALL") certificate. Ellison, Frantz, Thomas [Page 39] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 DELEGATE-ALL is a wild card field which stands for any and all fields which the has permission to delegate -- each with one less than that in the 's cert. (See 5.1 for the definition of .) This construct is especially for passing along the rights of a group of users to the members of the group but it can also be used by an individual user to delegate all if his or her own authority to a temporary key for a limited period of time. If the DELEGATE-ALL certificate includes a MAY-DELEGATE field, then the effective of that certificate for a given is the minimum of the given and one less than that of the 's certificate. 5.10.2 SDSI groups MEMBER: NON-MEMBER: The subject key (ie., principal) is positively confirmed to be a member (or non-member, respectively) of the indicated SDSI group. The group name is in the name space of the certificate issuer (as in SDSI). 5.11 Other Certificate CERTIFICATE: This means that the has validated the indicated certificate to its own satisfaction. No clear use of this construct is envisioned at this time, but it is included here as an example of the kind of field which can be defined. 5.12 Certificate for Blind Signatures There is sometimes a desire to create a blind signature on a key. Current methods call for a blinded quantity to be given to the prospective issuer which signs it and gives the signed quantity back to the subject. The subject unblinds the quantity, yielding a signed quantity which the issuer has never seen in the clear. Ellison, Frantz, Thomas [Page 40] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 If this blinded quantity were an SPKI certificate, the issuer would have no control over the or fields. One possible solution to this problem employs the field modifier INDIRECT-SUBJECT: In the following certificate: BEGIN: SUBJECT: K1 (...) INDIRECT-SUBJECT: END: the INDIRECT-SUBJECT indicates that the combination of this certificate and a key, K2, signed by K1 is taken to be functionally equivalent to the certificate: BEGIN: SUBJECT: K2 (...) END: Ellison, Frantz, Thomas [Page 41] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 6. Fields As described in section 3.12, a certificate has some validity period. Its use will be limited by the validity period of any certificates on which it depends but it can have its own validity limitations. If there is no validity specification, a certificate is assumed to be valid forever. 6.1 Expiration EXPIRES: gives a firm expiration date for the certificate, before which a replacement must be issued with a new expiration date. RENEW-LOCATION: This is the location (URL, SMTP name, DNS name or TCP port) to get the certificate's VALID-TO date changed, get a new CRL (update) or get ECR revalidation. 6.2 Re-validation VALID-TO: gives a temporary validity date and time. The certificate needs to be re-issued with an updated validity date and time if the indicated time has passed. (This is equivalent to EXPIRES and is included as a separate item in case the issuer has a special procedure which must be followed to reissue a certificate on the EXPIRES date (perhaps involving payment of a fee).) 6.3 CRL CRL: where gives the lifetime of a CRL in seconds. ((Format of the CRL itself is TBD, but should probably involve the ability to issue incremental CRL changes, on the assumption that a CRL can grow very large and that a process which verifies validity by Ellison, Frantz, Thomas [Page 42] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 CRL will therefore maintain a copy of the CRL and want to receive only updates.)) 6.4 Validity by Chained Hash [ECR] gives a mechanism using chained hash values rather than public key operations to indicate continued validity or revocation of a certificate or CRL. (This method may be covered by one or more patents.) When applied to a certificate, one might have: ECR-PARAMS: ,,,,, where: : is the start date and time (date of issue) -- T; : is the number of seconds between revalidations -- S; : is the name of the hash algorithm used; : is the number of hashes of the original seed (so that the certificate can be revalidated until time T+(S*N)); : is the hash value whose pre-image is to be returned if the certificate has been revoked; and : is the N'th hash of the original seed. If a certificate is still valid, the on-line validation service will return the ((X-T)/S)'th pre-image of V, where X is the current time. That hash value can be bundled with a certificate without needing to be signed and provided as proof of current validity. 6.5 Session modifier GOOD-ONLY-FOR-SESSION: This modifier of a certificate limits its validity to a particular session (e.g., a TELNET connection or HTTP shopping session). is a text string. Ellison, Frantz, Thomas [Page 43] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 7. Field and Key Definitions 7.1 Signature Format The signature on a certificate (or, optionally, anything else) has the format: SIGNATURE: ,,, where: is the name of the algorithm used to compute the hash being signed; is the name of the public key algorithm used to compute the signature, including specification of any padding or internal formatting; is the value of the signature; and is an optional field indicating the object being signed by giving its hash. If this field is missing, the SIGNATURE is taken to apply to the preceding BEGIN-END block. 7.2 Dual Signature Requirement DUAL-SIG: This line inside a certificate body means that the certificate is not valid unless the has also signed it. Anticipated primarily for identity certificates, this line makes explicit the good CA practice of having the customer sign the subject key and accept the issuance of the given certificate. 7.3 Key Format A public key is described as: KEY: , For example, the two common ones (for signature keys) are: Ellison, Frantz, Thomas [Page 44] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 KEY: RSA,, KEY: DSA,,,

Ellison, Frantz, Thomas [Page 45] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 8. Examples (to be given) Ellison, Frantz, Thomas [Page 46] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 9. Binary Format 9.1 Tag definitions This table of definitions is subject to extension as fields become widely accepted. 9.1.1 Non-auth fields The following are all the non-auth fields given in this document. 0: END 1: BEGIN 2: SUBJECT 3: SUBJECT-CERT 4: ISSUER 5: ISSUER-CERT 6: EXPIRES 7: RENEW-LOCATION 8: VALID-TO 9: CRL 10: ECR-PARAMS 11: GOOD-ONLY-FOR-SESSION 12: SIGNATURE 13: DUAL-SIG 14: KEY 9.1.2 Auth fields The following are some of the fields given in this document. Only those which we believe to be truly useful are assigned tags. The others may use the AUTH: construct (or, may later be assigned tag numbers). 32: MAY-DELEGATE 33: AUTH 34: FTP 35: TELNET 36: HTTP 37: EMPLOYEE 38: NAME 39: KNOWN-TO-ME-AS Ellison, Frantz, Thomas [Page 47] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 40: LOCATION 41: RESPONSIBLE-PARTY 42: MAILTO 43: SPENDING-AUTHORITY 44: COMMENT 45: DELEGATE-ALL 46: MEMBER 47: NON-MEMBER 48: INDIRECT-SUBJECT 49: USER 9.2 Integer format There are 4 integer sizes: , , and . A is expressed as just the byte. A is encoded as two bytes, higher order byte first. A is encoded as four bytes, most significant byte first. A is a count followed by that number of bytes of the string, most significant byte first. The indication of size of integer is to be built in to the field definition so that no bytes are used to indicate that size. 9.3 Date format A date is a , giving the number of seconds since 1970-01-01.00:00:00 UTC. 9.4 String format A string is a byte count followed by the bytes of the UTF-8 string. (Text strings and byte strings are intentionally encoded the same way.) Ellison, Frantz, Thomas [Page 48] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 9.5 Algorithm definitions The standard algorithms are: 0: ALG 1: MD5 2: SHA-1 3: RSA 4: DSA with room for expansion as new algorithms gain popularity. The ALG option is followed by a text string naming an algorithm, for use when this list of defined algorithms has not yet been updated. 9.6 Hash fields A field is a byte string. Ellison, Frantz, Thomas [Page 49] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 References [BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed Trust Management", Proceedings 1996 IEEE Symposium on Security and Privacy. [DNSSEC] Donald Eastlake and Charles Kaufman, "Domain Name System Security Extensions", (working draft of the DNSSEC Working Group). [DvH] J. B. Dennis and E. C. Van Horn, "Programming Semantics for Multiprogrammed Computations", Communications of the ACM 9(3), March 1966 [ECR] Silvio Micali, "Efficient Certificate Revocation", manuscript, MIT LCS. [HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating Systems Review, v.19 n.4, October 1985. pp 8-25. [IDENT] Carl Ellison, "Establishing Identity Without Certification Authorities", USENIX Security Symposium, July 1996. [IWG] McConnell and Appel, ``Enabling Privacy, Commerce, Security and Public Safety in the Global Information Infrastructure'', report of the Interagency Working Group on Cryptography Policy, May 12, 1996; (quote from paragraph 5 of the Introduction) [KEYKOS] Bomberger, Alan, et al., "The KeyKOS(r) Nanokernel Architecture", Proceedings of the USENIX Workshop on Micro-Kernels and Other Kernel Architectures, USENIX Association, April 1992. pp 95-112 (In addition, there are KeyKOS papers on the net available through http://www.cis.upenn.edu/~KeyKOS/#bibliography) [LANDAU] Landau, Charles, "Security in a Secure Capability-Based System", Operating Systems Review, Oct 1989 pp 2-4 [LEVY] Henry M. Levy, "Capability-Based Computer Systems", Digital Press, 12 Crosby Dr., Bedford MA 01730, 1984 [LINDEN] T. A. Linden, "Operating System Structures to Support Security and Reliable Software", Computing Surveys 8(4), December 1976. [PKCS1] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4. [PKLOGIN] David Kemp, "The Public Key Login Protocol", working draft, 06/12/1996. Ellison, Frantz, Thomas [Page 50] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 [RFC1321] The MD5 Message-Digest Algorithm, R. Rivest, April 16 1992. [SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed Security Infrastructure [SDSI]", http://theory.lcs.mit.edu/~rivest/... [SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for Access Control in Distributed Systems", DEC SRC-070, revised August 28, 1991. Ellison, Frantz, Thomas [Page 51] INTERNET-DRAFT Simple Public Key Certificate 17 Mar 1997 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 Brian Thomas Southwestern Bell One Bell Center, Room 23Q1 St. Louis MO 63101 USA Telephone: +1 314-235-3141 +1 314-331-2755(fax) EMail: bt0008@entropy.sbc.com Bill Frantz Periwinkle 16345 Englewood Ave. Los Gatos, CA 95032 Telephone: +1 408-356-8506 Email: frantz@netcom.com Expiration and File Name This draft expires 22 September 1997. Its file name is draft-ietf-spki-cert-structure-00.txt Ellison, Frantz, Thomas [Page 52]