Internet Draft Editor: Peter Gutmann draft-ietf-pkix-autonomous-certs.txt University of Auckland June 22, 1999 Expires December 1999 X.509 Profile for Autonomous Certificates Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Current X.509 profiles assume the presence of an arbitrarily large and all-encompassing PKI run by third parties in order to function. Unfortunately this doesn't take into account common cases such as the situation where parties have an existing trust relationship and want to share keys (without requiring a third party to issue them certificates), or where an end entity has a signing certificate and wants to issue their own confidentiality keys rather than requiring the cooperation of a third party to do it for them, or where an end entity wishes to distribute their keys via commonly-available mechanisms such as web pages instead of waiting for a Directory capable of performing this task to appear. This profile presents a mechanism for identifying and working with end-entity certificates which fulfil the above requirements. This use of end-entity certified keys, combined with the distribution mechanism described below, allows perfect forward (and backward) secrecy (keys can be rolled over hourly if required) which can be made completely transparent to the user, as well as doing away with the need for the (often unnecessary) reliance on a CA for certification of keys, and with the need for a Directory or similar mechanism for key distribution. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The format of the messages are described in ASN.1:1994 [ASN1]. This draft is being flamed on the "ietf-pkix" mailing list. To join the list, send a message to with the single word "subscribe" in the body of the message. Also, there is a Web site for the mailing list at . 1. Introduction 1.1 Defining the Problem Current X.509 profiles assume the presence of an arbitrarily large and all-encompassing PKI run by third parties in order to function. Unfortunately this doesn't take into account two very common cases: 1. Two parties who have an established trust relationship and want to share keys. This is a common case for businesses who would typically have existing bilateral trading arrangements and neither require, nor care for, an external (or internal) CA. Keys for the other party would be held as part of the standard account records maintained by both sides, which would also contain information such as the account balance information maintained as a standard business practice. Simply registering the other parties public key in the account record represents the easiest and most reliable way of managing the public key. In contrast, using a third-party certificate requires complex (and often nonexistant) certificate handling mechanisms, reliance on third-party CRLs, and the creation of an unnecessary parallel trust infrastructure which adds nothing (apart from complexity) to the existing trust mechanism. A typical example of this would be users who are communicating with the tax department. The tax department knows who its "customers" are, and *everyone* knows who the tax department is. An external CA doesn't fit into this model. 2. An end entity who has a CA (or otherwise) certified authentication cert and wants to use it to issue their own confidentiality key certificates. If an end entity has a signature cert then there is no need for CA-issued confidentiality certs, especially since this grants the end entity a far greater degree of control over their keys. For example the end entity might wish to roll over their confidentiality keys once a month or once a week, a prudent security precaution which could end up bankrupting them if it were attempted with CA-certified keys. Unfortunately both of these items, while perfectly sensible, represent a paradox for X.509, since a certificate is incapable of representing them: There's no way to create a standalone end-entity certificate containing a public key, and there's no way for an end entity to create/certify their own confidentiality keys. An unfortunate side-effect of this is that developers and users are finding their own workarounds to the problem, typically by creating X.509v1 self-signed certificates which are commonly treated as CA root certificates by current software. The documentation provided by some software vendors even encourages users to create their own (effective) CA root certificates, and to aid the users in doing this the vendors provide software tools which create these certificates automatically, including the ability to specify any name the user wants (for example the name of a standard commercial CA). As a result, anyone encountering one of these DIY certificates on the net who uses the standard technique of clicking "OK" until the dialog boxes go away will give the certificate the same weight as the certificate of a large commercial CA. 1.2 Reasons for the Problem The reason a standalone end entity certificate can't exist is that it has to be signed by a CA, but an end entity is by definition not a CA and therefore can't do this. A workaround is for the end entity to create a pseudo-CA certificate whose only task is to sign other certificates, but all this does is add unnecessary complexity. The reason an end entity certified confidentiality key can't exist is again because an end entity isn't a CA, and again because there is no way to specify this in a certificate. Its possible to make the end entity a CA with a path length of zero and a name constraint which only allows them to issue certs to entities below them, but its unlikely that CAs will agree to turn each of their users into mini-CAs, and in any case whats required is that they have the ability to issue certificates only for themselves, not for anyone in the tree below them. If this were to be handled through constraints, what would be required is a purpose constraint, which isn't present in X.509. The reason why people are resorting to measures such as creating (de facto) CA root certificates for end users is because, until now, there was no way to resolve these problems. 1.3 Further Issues Related to the creation of autonomous certificates is the issue of certificate distribution and revocation - creating a mechanism for autonomous certificates is of little use if it relies on a (nonexistant) Directory to distribute them. For this reason this profile recommends the use of web-based certificate distribution and revocation as explained in section 3. 2. Certificate and CRL profile This profile defines two types of certificates, an end entity self-signed (EESS) certificate which is identical to a conventional end entity certificate except that it is issued by an end-entity rather than a CA, and an end entity confidentiality key (EECK) certificate which is identical to a conventional end entity confidentiality certificate except that its intended usage is as a short term certificate renewed frequently using the end entity's authentication certificate. The three usage scenarios for these certificate types are: EESS - Conventional certificate but issued by the end entity EESS -> EECK - Long-term EESS signature certificate used to issue short- term EECK certificates CA -> EE -> EECK - Standard CA-issued long-term signature certificate used to issue short-term EECK certificate The third scenario allows legacy CA-issued signature certificates to be used as a means for issuing EECK certificates. 2.1 Self-signed End Entity Certificates To allow an end entity to issue certificates for themselves we require a means of specifying that the certificate is a self-signed end entity (EESS) certificate. Unfortunately this can't be done with X.509, the best we can do is to add a special-purpose extKeyUsage field which notifies the relying party of this. An EESS certificate shall have the following values in the basicConstraints, keyUsage, and extKeyUsage extensions: basicConstraints The cA field shall be set to FALSE The pathLenConstraint field shall be absent The cA field has a default value of FALSE, therefore the entire basicConstraints extension shall be encoded as a zero-length sequence. This zero-length sequence must be present in order to ensure that the certificate is not treated as a CA root certificate; most current implementations will treat a self-signed certificate with no basicConstraints as a CA root. keyUsage For standard EESS certificates the keyCertSign and crlSign bits shall not be asserted. For EESS certificates which will be used to issue EECK certificates (see section 2.2), the keyCertSign bit shall be asserted. For EESS certificates which will be used to issue CRLs (see section 2.3), the crlSign bit shall be asserted. extKeyUsage This extension shall include 'endEntitySelfSigned' as one of its extended uses: id-endEntitySelfSigned OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 42 1} -- Certificate is a self-signed end entity certificate -- (OID is temporary until a proper one is assigned) In addition EESS certificates must include a subjectKeyIdentifier for the reasons given in section 2.2. 2.1.1 Rationale The zero-length (empty) basicConstraints extension is required in order to avoid having the certificate treated as a CA root certificate by existing implementations. The non-asserted keyCertSign and crlSign bits are used in order to avert other potential problems with existing implementations which may become confused if they see a non-CA certificate with CA keyUsage bits asserted, and to emphasize the fact that the certificate is not usable for certifying other certificates. The extKeyUsage extension is the one which defines the semantics for the certificate. Its presence ensures that implementations which do not conform to this profile will not process the certificate. 2.2 Self-issued End Entity Confidentiality Key Certificates To allow an end entity with an existing signature certificate to issue and manage their own confidentiality certificates, we require a means of specifying that a certificate is an end entity confidentiality-key (EECK) certificate. This certificate may be signed either by an EESS certificate as described in section 2.1, or a standard certificate issued by a third-party CA. A EECK certificate shall have the following value in the extKeyUsage extension: extKeyUsage This extension shall include 'endEntityConfidentialityKey' as one of its extended uses: id-endEntityConfidentialityKey OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 42 2} -- Certificate is an end entity confidentiality-key certificate -- (OID is temporary until a proper one is assigned) EECK certificates must include an authorityKeyIdentifier extension identifying the CA-issued or EESS certificate which used to issue them. A certificate with this type of extended key usage has an implicit name constraint which requires that the subject and issuer DN of the EECK certificate be the same as the subject DN of the issuing certificate and the subject and issuer altName of the EECK certificate be the same as the subject altName of the issuing certificate. This is required in order to prevent the EECK issuer from being able to act as a general-purpose CA. Conforming implementations must verify that both the subject and issuer DN of the EECK match the subject DN of the issuing certificate and that the subject and issuer altName of the EECK match the subejct altName of the issuing certificate. 2.2.1 Rationale The zero-length basicConstraints extension is required in order to avoid having the certificate treated as a CA root certificate by some existing implementations. The extKeyUsage extension is required to indicate that the certifiate follows the EECK semantics, and if the issuing certificate is a standard CA-issued signature certificate to indicate that the issuing certificate (which won't have the keyCertSign bit asserted) is in fact allowed to sign the EECK certificate. [Note that this pushes different semantics back onto the CA-issued signature cert, but it's the only way to ensure that conventional certificates can be used to issue EECK certificates] The authorityKeyIdentifier is required because the implicit name constraint has the potential to result in the existence of large numbers of EECK certificates with the same subject DN, in which case the authorityKeyIdentifier will be required to determine the correct issuing certificate. The implicit name constraint is required in order to prevent the EECK cert issuer from acting as a general-purpose CA. Although this would normally be specified through an explicit name constraint, these are not permitted in end entity certificates, and even if they were permitted are only capable of constraining a subtree, not a fixed name. Although this could be further kludged with path length constraints, most current implementations probably won't handle this properly, making relying on it an uncertain proposition. 2.3 CRLs To allow an end entity with a EESS certificate to explicitly revoke it, a CRL may be used, although this profile recommends instead the use of implicit validity checking via HTTP distribution of certificates or alternatively methods such as implicit revocation through the use of short-lived certificates (this being one of the reasons for having EECK certificates) or revocation through out-of-band means (for example managing it through the accounting system mentioned in the introduction). For EECK certificates it is strongly recommended that revocation be handled implicitly either through the HTTP mechanism described in section 3 or by limiting the validity time of the certificate. If explicit revocations via CRLs is to be used then a prudent practice to follow when creating an EESS certificate is to simultaneously create a "suicide note" CRL to revoke it when required and to store it in a safe place for later use. This can be published when it becomes necessary to revoke the certificate without requiring access to the private key used to create it. The semantics for a EESS CRL differ somewhat from conventional CRLs in that the appearance of the revocation indicates that relying parties should cease using the certificate immediately. The thisUpdate field is meaningless (only one revocation is ever issued) and the revocationDate field can't be determined at the time the CRL is created. It is recommended that these fields be set to the CRL creation date, and that relying parties attach no particular significance to the contents of the fields. 2.3.1 Revocation Issues The original X.509 revocation mechanism relied on CRLs which were intended to be employed in a manner similar to the credit card blacklists used in the 1970's before they were superseded by the use of online validity checks. As with credit card blacklists, the use of CRL's for validity checking involves a two-phase process: 1. Obtain a certificate of unknown validity 2. Obtain a CRL to determine whether the certificate can be relied upon (fans of the Black Adder TV series may recall this protocol being used in the "Here is a purse of money... which I'm not going to give to you" transaction which occurs in the first episode of season 2). In the presence of online checking this two-phase check becomes unnecessary, since it can be simplified to a single step: 1. Obtain a currently valid certificate. The fact that a certificate is available online indicates that it is currently valid; failure to obtain a certificate indicates that there are no valid certificates available. Since publication is controlled by the certificate owner (see section 3), the owner also has full control over certificate usage by relying parties. A variant with a somewhat larger margin of error involves the use of short-term certificates: 1. Obtain a certificate which will be valid for the next hour. This variant is still no worse than the CRL version since CRL's are typically not issued more than once an hour, and is still only a single-step process. 3. Certificate Management In the absence of any other convenient distribution mechanism such as personal contact, trusted courier, or (if a CA-certified signature certificate is being used) PKI-based trust mechanisms, a recommended means of certificate distribution and management is through the world-wide web. This means of certificate publication is almost universally available, and provides a convenient and (relatively) reliable way to publish certificates, perform validity checking, and optionally publish CRLs if they are to be used. It is recommended that certificates be published via the users home page using the following naming scheme: http://www.homepage.com/eesscert.der -- Issuing certificate http://www.homepage.com/eesscrl.der -- Suicide note for EESS cert http://www.homepage.com/eeckcert.der -- EECK certificate http://www.homepage.com/eeckcrl.der -- Suicide note for EECK cert This allows relying parties who wish to obtain the users certificate to fetch it directly from a known location using a single HTTP GET, which can be implemented using a read and write on a socket (it does not require spawning a web browser and having the user cut and paste data across). If CRL's are to be used then the CRL would be created at the same time as the self-issued certificate, acting as a "suicide certificate" for the actual certificate as discussed in section 2.3. When it becomes necessary to revoke the certificate, the pre-generated CRL is published at the location indicated in the certificate. Since the certificate publication mechanism makes it extremely easy to generate new certificates, it is recommended that confidentiality keys be rolled over frequently both for security reasons (frequent key changes limit the exposure of any one key) and as a simple key revocation mechanism - a key with a lifetime measured in days needs very little extra support in terms of an infrastructure for revocation. In the most extreme case a new key can be generated for every message, with the server serving a new eeckcert.der for each HTTP GET request. Note that while this option provides a high level of security (since a new key is used for each message), it imposes an extra load on the server, which needs to generate new keys in response to HTTP requests (possibly leading to a denial-of-service attack) and needs to dynamically update the content rather than simply serving a static file (leading to a need for server-side scripting rather than simply placing a file in the appropriate directory). This option therefore provides a high level of security at the expense of requiring extra work to be performed by the server. 3.1 Identifying EESS Certificates to Relying Parties The problem of distributing current CA root certificates is typically addressed by hardcoding them into web browsers and mail programs and decreeing them to be implicitly trusted, unfortunately this luxury isn't available to holders of EESS certificates. Where these certificates are distributed through personal contact (for example by exchange of business cards) it is recommended that the information specified include the URL of the web page containing the certificate(s) (from which the full URL of the certificates and CRL's can be trivially constructed), and the fingerprint (SHA-1 hash) of the EESS certificate at that location, truncated to fit the space available if required. Where a truncated hash is used, the truncation is performed to the right, in other words the leftmost bytes of the hash are retained and an appropriate quantity of rightmost bytes are discarded. It is recommended that the hash not be truncated to less than 64 bits. This method provides an out-of-band identification mechanism similar to the one which has been in wide use for PGP for a number of years. As an illustration, the previously-used sample certificates might be identified on a business card with: Cert location: http://www.homepage.com/ Cert fingerprint: 07 2C BD 10 24 37 0F 1D 3.2 Rationale Since virtually everyone seems to have a home page somewhere, certificate publication via the web provides a convenient key distribution mechanism while users wait for a Directory to appear. The online certificate fetch ensures that the latest certificate will always be used and that the certificate will be a currently valid one. Updating or revoking a key managed in this way is a relatively simple matter and doesn't require the cooperation of third parties to perform. In terms of centralised vs distributed PKIs, one way to break a conventional Directory-based PKI is to perform a denial-of-service (DOS) attack on the server through which the CRL is published to ensure that the CRL is never delivered. The typical workaround for this is a complicated timestamp-based one which is intended to indicate that some sort of revocation information should have been made available at some point but wasn't, like a number of other esoteric PKI aspects this has very little implementation support. In contrast performing a DOS attack on the server will simply make the certificate itself unavailable, indicating to the relying party that something is wrong. 4. Usage Example 4.1 Scenario 1 Alice wants to communicate with Bob without Mallet being able to intercept their communications. She obtains a free certificate from a commercial CA and uses it to create an EECK certificate with a validity of one week which she puts on her home page. When Bob wants to send Alice mail, he fetches her certificate from her home page with an HTTP GET. Once a week, Alice generates a new EECK certificate and uses it to replace the existing one on her home page. If she suspects her EECK key has been compromised, she rolls over the EECK certificate before the week is up. Explicit revocation is unnecessary and not used. 4.2 Scenario 2 Alice wants to communicate with Bob as before. She creates an EESS certificate and puts the URL and fingerprint on her business card. She also creates an EECK certificate and puts both certificates on her home page. When she and Bob next meet, she hands him her card, which Bob can use to verify her EESS certifcate. When Bob wants to send Alice mail, he fetches her certificate from her home page with an HTTP GET. Once a week, Alice generates a new EECK certificate and uses it to replace the existing one on her home page. If she suspects her EECK key has been compromised, she rolls over the EECK certificate before the week is up. Explicit revocation is unnecessary and not used. 5. Security Considerations The security of autonomous certificates rest on the security of the mechanisms used to authenticate them. Relying parties should ensure that the certificates they are working with meet their requirements in terms of assurance of authenticity. Author Address Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand pgut001@cs.auckland.ac.nz References ASN1 Recommendation X.680: Specification of Abstract Syntax Notation One (ASN.1), 1994. RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels, S.Bradner, March 1997. Full Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.