Internet Draft S. Farrell (SSE) PKIX Working Group C. Adams (Nortel) draft-ietf-pkix-ipki3cmp-00.txt W. Ford (Nortel) Expires in 6 months June 1996 Internet Public Key Infrastructure Part III: Certificate Management Protocols Status of this Memo 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 6 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This is the third draft of the Internet Public Key Infrastructure X.509 Certificate Management Protocols. This document is based on sections 7, 9 and 10 of draft-ietf-pkix-ipki-00.txt. Many changes have been made as a result of discussion at the Dallas IETF in December 1995, the Los Angeles IETF in March 1996, and discussion on the ietf-pkix@tandem.com mail list. The intent of this document is to generate further productive discussion and to build consensus. 1. Executive Summary << To be supplied. >> 2. PKI Management Overview The PKI must be structured to be consistent with the types of individuals who must administer it. Providing such administrators Farrell, Adams, Ford [Page 1]
INTERNET-DRAFT June 1996 with unbounded choices complicates not only the software required but also increases the chances that a subtle mistake by an administrator or software developer will result in broader compromise. Similarly, restricting administrators with cumbersome mechanisms will cause them not to use the PKI. Management protocols are required to support on-line interactions between Public Key Infrastructure (PKI) components. For example, a management protocol might be used between a CA and a client system with which a key pair is associated, or between two CAs which cross- certify each other. 2.1 PKI Management Model Before specifying particular message formats and procedures we first define the entities involved in PKI management and their interactions (in terms of the PKI management functions required). We then group these functions in order to accomodate different identifiable types of end entities. 2.1.1. Definitions of PKI Entities The entities involved in PKI management include the end entity (i.e. the entity to be named in the subject field of a certificate) and the certification authority (i.e. the entity named in the issuer field of a certificate). A registration authority may also be involved in PKI management. 2.1.1.1. Subjects and End Entities The term "subject" is used here to refer to the entity named by the subject field of a certificate; when we wish to distinguish the tools and/or software used by the subject (e.g. a local certificate management module) we will use the term "subject equipment". It is important to note that the end entities here will include not only human users of applications, but also applications themselves (e.g. for IP security). This factor influences the protocols which the PKI management operations use; e.g., applications software is far more likely to know exactly which certificate extensions are required than are human users. PKI management entities are also end entities in the sense that they are sometimes named in the subject field of a certificate or cross-certificate. Where appropriate, the term "end- entity" will be used to refer to end entities who are not PKI management entities. All end entities require secure local access to some information -- at a minimum, their own name and private key, the name of a CA which is directly trusted by this subject and that CA's public key (or a digest of the public key where a self-certified version is available elsewhere). Implementations may use secure local storage for more than this minimum (e.g. the end entity's own certificate or Farrell, Adams, Ford [Page 2]
INTERNET-DRAFT June 1996 application-specific information). The form of storage will also vary -- from files to tamper resistant cryptographic tokens. Such local trusted storage is referred to here as the end entity's Personal Security Environment (PSE). << The PSE content is not defined further here as it is very dependent on equipment, et cetera. However, an interchange format for a generic PSE might be useful - we could consider using a CertRep message for this.>> 2.1.1.2. Certification Authority The certification authority (CA) may or may not actually be a real "third party" from the end entity's point of view. Quite often, the CA will actually belong to the same organisation as the end entities it supports. Again, we use the term CA to refer to the entity named in the issuer field of a certificate; when it is necessary to distinguish the software or hardware tools used by the CA we use the term "CA equipment". The CA equipment will often include both an "off-line" component and an "on-line" component, with the CA private key only available to the "off-line" component. This is, however, a matter for implementors (though it is also relevant as a policy issue). 2.1.1.3. Registration Authority In addition to end entities and CAs, many environments call for the existence of a registration authority (RA) separate from the certification authority. The functions which the registration authority may carry out will vary from case to case but may include personal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs, et cetera. This document views the RA as an optional component - when it is not present the CA is assumed to be able to carry out the RA's functions so that the PKI management protocols are the same from the end entity's point of view. Again, we distinguish, where necessary, between the RA and the tools used (the "RA equipment"). Note that an RA is itself an end entity. We further assume that all RAs are in fact certified end entities and that the RA private key is usable for signing. How a particular CA equipment identifies some end entities as RAs is an implementation issue (so there is no special RA certification operation). We do not mandate that the RA is certified by the CA with which it is interacting at the moment (so one RA may work with more than one CA whilst only being certified once). Farrell, Adams, Ford [Page 3]
INTERNET-DRAFT June 1996 In some circumstances end entities will communicate directly with a CA even where an RA is present. For example, for initial registration and/or certification the subject may use its RA, but communicate directly with the CA in order to refresh its certificate. The reasons which justify the presence of an RA can be split into those which are due to technical factors and those which are organizational in nature. Technical reasons include the following. -If hardware tokens are in use, then not all end entities will have the equipment needed to initialize these; the RA equipment can include the necessary functionality (this may also be a matter of policy). -Some end entities may not have the capability to publish certificates; again, the RA may be suitably placed for this. -The RA will be able to issue signed revocation requests on behalf of end entities associated with it, whereas the end entity may not be able to do this (if the key pair is completely lost). Some of the organisational reasons which argue for the presence of an RA are the following. -It may be more cost effective to concentrate functionality in the RA equipment, than to supply functionality to all end entities (especially if special token initialization equipment is to be used). -Establishing RAs within an organization can reduce the number of CAs required, which is sometimes desirable. -RAs may be better placed to identify people with their "electronic" names, especially if the CA is physically remote from the end entity. -For many applications there will already be in place some administrative structure so that candidates for the role of RA are easy to find (which may not be true of the CA). 2.1.2. PKI Management Requirements The protocols given here meet the following requirements on PKI management. 2.1.2.1. PKI management must conform to ISO 9594-8 and the associated draft amendment (DAM) 2.1.2.2. PKI management must conform to the other parts of this series. Farrell, Adams, Ford [Page 4]
INTERNET-DRAFT June 1996 2.1.2.3. It must be possible to regularly update any key pair without affecting any other key pair 2.1.2.4. The use of confidentiality in PKI management protocols must be kept to a minimum in order to ease regulatory problems 2.1.2.5. PKI management protocols must allow the use of different industry-standard cryptographic algorithms, (specifically including, RSA, DSA, MD5, SHA-1) -- this means that any given CA, RA, or end entity may, in principal, use whichever algorithms suit it for its own key pair(s). 2.1.2.6. PKI management protocols must not preclude the generation of key pairs by the end entity concerned, an RA, or a CA -- key generation may also occur elsewhere, but for the purposes of PKI management we can regard key generation as occurring wherever the key is first present at an end entity, RA or CA. 2.1.2.7. PKI management protocols must support the publication of certificates by the end entity concerned, an RA or a CA. Different implementations and different environments may choose any of the above approaches. 2.1.2.8. PKI management protocols must support the production of CRLs by allowing certified end entities to make requests for the revocation of certificates - this must be done in such a way that the denial-of-service attacks which are possible are not made simpler. 2.1.2.9. PKI management protocols must be usable over a variety of "transport" mechanisms, specifically including, mail, http, TCP/IP and ftp. 2.1.2.10. Final authority for certification creation rests with the CA; no RA or end entity equipment should assume that any certificate issued by a CA will contain what was requested -- a CA may alter certificate field values or may add, delete or alter extensions according to its operating policy; the only exception to this is the public key, which the CA may not modify (assuming that the CA was presented with the public key value). In other words, all PKI entities (end entities, RAs and CAs) must be capable of handling responses to requests for certificates in which the actual certificate issued is different from that requested -- for example, a CA may shorten the validity period requested. 2.1.2.11. A graceful, scheduled change-over from one non-compromised CA key pair to the next must be supported (CA key update). 2.1.2.12. A subject whose PSE contains the new CA public key (following a CA key update) must also be able to verify certificates verifiable using the old public key. Farrell, Adams, Ford [Page 5]
INTERNET-DRAFT June 1996 2.1.2.13. End entities who directly trust the old CA key pair must be able to verify certificates signed using the new CA private key (following a CA key update). This is required for situations where the old CA public key is "hardwired" into the end entity's cryptographic equipment (e.g., smartcard memory). 2.1.2.14. The Functions of an RA may, in some implementations or environments, be carried out by the CA itself. The protocols should be designed so that end entities will use the same protocol regardless of whether the communication is with an RA or CA. 2.1.3. PKI Management Operations The following diagram shows the relationship between the entities defined above in terms of the PKI management operations. The numbers in the diagram indicate "protocols" in the sense that a defined set of PKI management messages can be sent along each of the numbered lines. cert. publish +------------+ +---+ +------------ | End Entity | Operations | C | | 7 +------------+ | e | <--------+ | ^ initial | r | 1 | | 2 registration/ | t | PKI "users" | | certification | | | | key pair recovery | / | | | key pair update | | | | certificate update | C | V | revocation request | R | -------+-+-----+-+------+-+----- | L | PKI management | ^ | ^ | | entities 1 | | 2 1 | | 2 | | V | | | | R | 7 +------+ 4 | | | e | <------------ | RA | <-----+ | | | p | cert. | | ----+ | | | | o | publish +------+ 3 | | | | | s | | | | | | i | V | V | | t | 8 +------------+ 9 | o | <------------------------| CA |-------> | r | +------------+ "out-of-band" | y | cert. publish | ^ publication | | CRL publish | | +---+ | | cross-certification | | 6 cross-certificate | | update | | V | +------+ | CA-2 | +------+ Figure 1 - PKI Entities Farrell, Adams, Ford [Page 6]
INTERNET-DRAFT June 1996 At a high level the set of functions for which management messages are defined is as follows. -CA establishment: When establishing a new CA, certain steps are required (e.g., production of initial CRLs). -export of CA public key for "out-of-band" mechanisms: CAs must provide their public keys to end-entities. In order to facilitate interoperability between different CA and end-entity implementations a data structure for this purpose is required. -initial registration/certification: This is the process whereby a subject first makes itself known to a CA or RA, prior to the CA issuing a certificate or certificates for that user. The end result of this process (when it is successful) is that a CA issues a certificate for an end entity's public key, and returns that certificate to the subject and/or posts that certificate in a public repository. This process may, and typically will, involve multiple "steps", possibly including an initialization of the end entity's equipment. For example, the subject equipment must be securely initialized with the public key of a CA, to be used in validating certificate paths. Furthermore, a subject typically needs to be initialized with its own key pair(s). -key pair update: Every key pair needs to be updated regularly (i.e., replaced with a new key pair), and a new certificate needs to be issued. -certificate update: As certificates expire they may be "refreshed" if nothing relevant in the environment has changed. -certificate publication: Having gone to the trouble of producing a certificate some means for publishing it is needed. Note that the above three functions will often be combined. -key pair recovery: As an option, user client key materials (e.g., a user's private key used for decryption purposes) may be backed up by a CA, an RA or a key backup system associated with a CA or RA. If a subject needs to recover these backed up key materials (e.g., as a result of a forgotten password or a lost key chain file), a protocol exchange may be needed to support such recovery. -revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation. Farrell, Adams, Ford [Page 7]
INTERNET-DRAFT June 1996 -CA key pair update: As with end entities, CA key pairs need to be updated regularly; however, different mechanisms are required. -cross-certification: Two CAs exchange the information necessary to establish cross-certificates between those CAs. -cross-certificate update: Similar to a normal certificate update but involving a cross-certificate. -CRL publication: As for certificates. Note that on-line protocols are not the only way of implementing the above functions. For all functions there are off-line methods of achieving the same result, and this specification does not mandate use of on-line protocols. For example, when hardware tokens are used, many of the functions may be achieved as part of the physical token delivery. Later sections define a set of standard protocols supporting the above operations. The protocols for conveying these exchanges in different environments (on-line, E-mail, and WWW) are also specified. <> 3. Data Structures This section contains descriptions of the data structures required for PKI management messages. Section 4 describes constraints on their values and the sequence of events for each of the various PKI management operations. Section 5 describes how these may be encapsulated in various transport mechanisms. 3.1 Overall PKI Message PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection PKIProtection } 3.1.1. PKI Message Header All PKI messages require some header information for addressing and transaction identification. Some of this information will also be present in a transport-specific envelope; however, if the PKI message is signed then this information is also protected (i.e. we make no assumption about secure transport). Farrell, Adams, Ford [Page 8]
INTERNET-DRAFT June 1996 The following data structure is used to contain this information: PKIHeader ::= SEQUENCE { pvno INTEGER { ietf-version1 (0) }, messageType MessageType, transactionID [1] OCTET STRING OPTIONAL, -- identifies the transaction, i.e. this will be the same in -- corresponding request, response and confirmation messages messageID [2] OCTET STRING OPTIONAL, -- identifies this message uniquely (if needed) senderNonce [3] OCTET STRING OPTIONAL, recipNonce [4] OCTET STRING OPTIONAL, -- nonces used to provide replay protection, senderNonce -- is inserted by the creator of this message; recipNonce -- is a nonce previously inserted in a related message by -- the intended recipient of this message messageTime UTCTime OPTIONAL, -- time of production of this message sender GeneralName, -- identifies the sender for addressing purposes recipient GeneralName, -- identifies the intended recipient for addressing purposes protectionAlg AlgorithmIdentifier OPTIONAL, -- to include the alg. in e.g. signature calculation freeText CHOICE { IA5String, BNPString } OPTIONAL, -- this may be used to indicate context-specific -- instructions (this field is intended for human -- consumption) } MessageType ::= INTEGER { InitReq (0), -- message asking for initialization InitRep (1), -- response to above CertReq (2), -- message asking for a cert. CertRep (3), -- response to above KeyUpdReq (4), -- msg asking for new cert for pub key KeyUpdRep (5), -- response to above KeyRecReq (6), -- msg. asking for key recovery KeyRecRep (7), -- response to above RevReq (8), -- message asking for revocation RevRep (9), -- response to above CrossCertReq (10), -- message asking for cross-certification CrossCertRep (11), -- response to above CAKeyUpdAnn (12), -- announcement of CA key pair update CertAnn (13), -- announcement of a certificate Farrell, Adams, Ford [Page 9]
INTERNET-DRAFT June 1996 RevAnn (14), -- announcement of revocation of a cert CRLAnn (15), -- announcement of CRL PKIConfirm (16) -- used for confirmation in 3-way protocols } The transactionID field within the message header is required so that the recipient of a response message can correlate this with the request issued. In the case of an RA there may be many requests "outstanding" at a given moment. The value of this field should be unique from the sender's perspective in order to be useful. <> 3.1.2. PKI Message Body PKIBody ::= CHOICE { -- message-specific body elements [0] InitReqContent, [1] InitRepContent, [2] CertReqContent, [3] CertRepContent, [4] KeyUpdReqContent, [5] KeyUpdRepContent, [6] KeyRecReqContent, [7] KeyRecRepContent, [8] RevReqContent, [9] RevRepContent, [10] CrossCertReqContent, [11] CrossCertRepContent, [12] CAKeyUpdAnnContent, [13] CertAnnContent, [14] RevAnnContent, [15] CRLAnnContent, [16] PKIConfirmContent, } 3.1.3. PKI Message Protection Some PKI messages will be protected for integrity. In that case the following structure is used: PKIProtection ::= SEQUENCE { alg AlgorithmIdentifier OPTIONAL, -- when both this field and the protectionAlg field of the -- PKIHeader are present, they must be the same protectionBits BIT STRING } Farrell, Adams, Ford [Page 10]
INTERNET-DRAFT June 1996 The input to the calculation of the protectionBits is the DER encoding of the following data structure: ProtectedPart ::= SEQUENCE { PKIHeader, PKIBody} Note that this is equivalent to the ASN.1 notation: PKIProtection ::= SIGNATURE SEQUENCE { PKIHeader, PKIBody} The protocols required for PKI management use this structure differently, there are four possibilities: - no protection: e.g. to pass an "out-of-band" CA public key - symmetric protection: used in some registration schemes - single signature protection: e.g., when an RA signs a request - double signature protection: e.g., when both end entity and RA sign a request 3.1.3.1. Unprotected PKI messages <> 3.1.3.2. Symmetric protection of PKI messages <> 3.1.3.3. Single signatures on PKI messages <> 3.1.3.4. Double signatures on PKI messages <> Some PKI messages may be signed twice. In this case the PKIProtection structure is also used as follows: pkix-double-sig-alg-id ::= AlgorithmIdentifier -- value TBS -- just an OID; no parameters Farrell, Adams, Ford [Page 11]
INTERNET-DRAFT June 1996 The protectionBits field will contain the DER encoding of the following data structure: TwoSigProtection ::= SEQUENCE { firstAlgId [0] AlgorithmIdentifier OPTIONAL, firstSig BIT STRING, secondSigner GeneralName, secondAlgId [1] AlgorithmIdentifier OPTIONAL, secondSig BIT STRING} Where secondSig contains the signature of the DER encoding of the following: secondSigInput ::= SEQUENCE { PKIHeader, PKIBody, PKIProtection, -- version from 1st signer GeneralName, AlgorithmIdentifier OPTIONAL } 3.2 Common Data Structures Before specifying the specific types which may be placed in a PKIBody we define some useful data structures which are used in more than one case. 3.2.1. Requested Certificate Contents Various PKI management messages require that the originator of the message indicate some of the fields which are required to be present in a certificate. The CertTemplate structure allows an end entity or RA to specify as much as they can about the certificate they require. ReqCertContent is basically the same as a Certificate but with all fields optional. Note that even if the originator completely specifies the contents of a certificate they require, a CA is free to modify fields within the certificate actually issued. CertTemplate ::= SEQUENCE { version [0] Version OPTIONAL, -- used to ask for a particular syntax version serial [1] INTEGER OPTIONAL, -- used to ask for a particular serial number signingAlg [2] AlgorithmIdentifier OPTIONAL, -- used to ask the CA to use this alg. for -- signing the cert subject [3] Name OPTIONAL, validity [4] OptionalValidity OPTIONAL, Farrell, Adams, Ford [Page 12]
INTERNET-DRAFT June 1996 issuer [5] Name OPTIONAL, publicKey [6] SubjectPublicKeyInfo OPTIONAL, issuerUID [7] UniqueIdentifier OPTIONAL, subjectUID [8] UniqueIdentifier OPTIONAL, extensions [9] Extensions OPTIONAL, } -- the extensions which the requester would like in the cert. OptionalValidity ::= SEQUENCE { notBefore [0] UTCTime OPTIONAL, notAfter [1] UTCTime OPTIONAL } CertTemplates ::= SEQUENCE OF CertTemplate 3.2.2. Encrypted Private Key Where private keys are sent in PKI messages the following data structure is used. EncryptedPrivKey ::= SEQUENCE { privKey BitsAndAlgs, -- the private key encrypted encSymmKey BitsAndAlgs OPTIONAL -- a symmetric key used to encrypt the private key } BitsAndAlgs ::= SEQUENCE { encKey BIT STRING, encAlg [0] AlgorithmIdentifier OPTIONAL, -- algorithm used to encrypt the key keyAlg [1] AlgorithmIdentifier OPTIONAL -- algorithm for which the key is intended to be used } EncryptedPrivKeys ::= SEQUENCE of EncryptedPrivKey Use of this data structure requires that the creator and intended recipient are respectively able to encrypt and decrypt. Typically, this will mean that the end entity has been issued with a secret key shared with the generator of the key pair. If the recipient of the PKIMessage already possesses a private key usable for decryption, then the encSymmKey field may contain a session key encrypted using the recipient's public key. 3.2.3. Status codes and Failure Information for PKI messages All response messages will include some status information. The following values are defined. PKIStatus ::= INTEGER { granted (0), -- you got exactly what you asked for grantedWithMods (1), -- you got something like what you asked for; the -- requester is responsible for ascertaining the differences Farrell, Adams, Ford [Page 13]
INTERNET-DRAFT June 1996 rejection (2), -- you don't get it, more information elsewhere in the -- message waiting (3), -- the request body part has not yet been processed, -- expect to hear more later revocationWarning (4) -- this message contains a warning that a revocation is -- imminent revocationNotification (5) -- notification that a revocation has occurred } Responders may use the following syntax to provide more information about failure cases. PKIFailureInfo ::= BIT STRING { -- since we can fail in more than -- one way! badAlg (0), badMessageCheck (1) -- <> } StatusInfo ::= SEQUENCE { status PKIStatus, failInfo PKIFailureInfo OPTIONAL } 3.2.4. Certificate Identification In order to identify particular certificates the following data structure is used. CertId ::= SEQUENCE { issuer GeneralName, serialNumber INTEGER } Furthermore, a list of certificates is identified as follows. Certs ::= SEQUENCE OF Certificate 3.2.5. Publication Information <> In order to allow requesters to indicate where and/or how certificates should be published, or to allow responders to indicate where and/or how certificates have been published, the following syntax is used. PublicationInfo ::= SEQUENCE OF SEQUENCE { pubMethod OBJECT IDENTIFIER, pubDetails OCTET STRING OPTIONAL} Farrell, Adams, Ford [Page 14]
INTERNET-DRAFT June 1996 3.2.6. "Out-of-band" CA public key Each CA must be able to publish its current public key via some "out- of-band" means. While such mechanisms are beyond the scope of this document, we define data structures which can support such mechanisms. There are generally two methods available; either the CA directly publishes its public key and associated attributes, or this information is available via the Directory (or equivalent) and the CA publishes a hash of this value to allow verification of its integrity before use. OOBCert ::= Certificate OOBCertHash ::= SEQUENCE { hashAlg AlgorithmIdentifier OPTIONAL, certId CertId OPTIONAL, hashVal BIT STRING} -- hashVal is calculated over DER encoding of an entire OOBCert 3.3 Operation-Specific Data Structures 3.3.1. Initialization Request An Initialization request message (InitReq) contains an InitReqContent data structure which specifies the requested certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each certificate requested. InitReqContent ::= SEQUENCE { referenceNum INTEGER, protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL, certTemplates CertTemplates } 3.3.2. Initialization Response An Initialization response message (InitRep) contains an InitRepContent data structure which has for each certificate requested a StatusInfo field, a subject certificate, and possibly a private key (encrypted with a session key, which is itself encrypted with the protocolEncKey). InitRepContent also contains a CA signature certificate. InitRepContent ::= SEQUENCE { caSigCert Certificate, response SEQUENCE OF CertResponse } Farrell, Adams, Ford [Page 15]
INTERNET-DRAFT June 1996 3.3.3. Registration/Certification Request A Registration/Certification request message (CertReq) contains a CertReqContent data structure which specifies the requested certificate. CertReqContent ::= CertTemplates 3.3.4. Registration/Certification Response A registration response message (CertRep) contains a CertRepContent data structure which has a CA public key, a status value and optionally failure information, a subject certificate, and an encrypted private key. CertRepContent ::= SEQUENCE { caPub [1] OOBCert OPTIONAL, response SEQUENCE OF CertResponse } CertResponse ::= SEQUENCE { status StatusInfo, certifiedKeyPair CertifiedKeyPair OPTIONAL, } CertifiedKeyPair ::= SEQUENCE { certificate [1] Certificate OPTIONAL, privateKey [2] EncryptedPrivKey OPTIONAL } Only one of the failInfo (in StatusInfo) and certificate fields should be present in CertRepResponse (depending on the status). For some status values (e.g., waiting) neither of the optional fields will be present. 3.3.5. Key update request content For key update requests the following syntax is used. Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each key to be updated. As well, an encryption certificate, or a signature certificate, or both, would typically be specified in latestCerts. KeyUpdReqContent ::= SEQUENCE { endEntityName GeneralName, latestCerts SEQUENCE OF CertId, protocolEncKey [1] SubjectPublicKeyInfo OPTIONAL, certTemplates [2] CertTemplates OPTIONAL } Farrell, Adams, Ford [Page 16]
INTERNET-DRAFT June 1996 3.3.6. Key Update response content For key update responses the syntax used is identical to the initialization response. KeyUpdRepContent ::= InitRepContent 3.3.7. Key Recovery Request content For key recovery requests the syntax used is identical to the initialization request InitReqContent. Typically, SubjectPublicKeyInfo and KeyId are the template fields which may be used to supply a signature public key for which a certificate is required. KeyRecReqContent ::= InitReqContent 3.3.8. Key recovery response content For key recovery responses the following syntax is used. For some status values (e.g., waiting) none of the optional fields will be present. KeyRecRepContent ::= SEQUENCE { status StatusInfo, caCerts Certs OPTIONAL, newSigCert Certificate OPTIONAL, keyPairHist SEQUENCE OF CertifiedKeyPair OPTIONAL, } 3.3.9. Revocation Request Content When requesting revocation of a certificate (or several certificates) the following data structure is used. The name of the requestor is present in the PKIHeader structure. RevReqContent ::= SEQUENCE OF RevDetails RevDetails ::= SEQUENCE { certDetails CertTemplate, -- allows requestor to specify as much as they can about -- the cert. for which revocation is requested -- (e.g. for cases in which serialNumber is not available) revocationReason ReasonFlags, -- from the DAM, so that CA knows which Dist. point to use badSinceDate UTCTime OPTIONAL, -- indicates best knowledge of sender crlEntryDetails Extensions} -- requested crlEntryExtensions 3.3.10. Revocation Response Content The response to the above message. If produced, this is sent to the requestor of the revocation. (A separate revocation announcement message may be sent to the subject of the certificate for which revocation was requested.) Farrell, Adams, Ford [Page 17]
INTERNET-DRAFT June 1996 RevRepContent ::= SEQUENCE { status StatusInfo, revCerts [0] SEQUENCE OF CertId OPTIONAL, -- identifies the certs for which revocation was requested crls [1] SEQUENCE OF CertificateList OPTIONAL -- the resulting CRLs (there may be more than one) } 3.3.11. Cross certification request content Cross certification requests use the same syntax as for normal certification requests. CrossCertReqContent ::= CertReqContent 3.3.12. Cross certification response content Cross certification responses use the same syntax as for normal certification responses. CrossCertRepContent ::= CertRepContent 3.3.13. CA Key Update Announcement content When a CA updates its own key pair the following data structure may be used to announce this event. CAKeyUpdAnnContent ::= SEQUENCE { oldWithNew Certificate, -- old pub signed with new priv newWithOld Certificate, -- new pub signed with old priv newWithNew Certificate -- new pub signed with new priv } 3.3.14. Certificate Announcement This data structure may be used to announce the existence of certificates. Note that this structure (and the CertAnn message itself) is intended to be used for those cases (if any) where there is no pre-existing method for publication of certificates; it is not intended to be used where, for example, X.500 is the method for publication of certificates. CertAnnContent ::= Certificate Farrell, Adams, Ford [Page 18]
INTERNET-DRAFT June 1996 3.3.15. Revocation Announcement When a CA has revoked, or is about to revoke, a particular certificate it may issue an announcement of this (possibly upcoming) event. RevAnnContent ::= SEQUENCE { status PKIStatus, certId CertId, revocationTime UTCTime, badSinceDate UTCTime, crlEntryDetails [0] Extensions OPTIONAL, -- crlEntryExtensions (e.g. reason) crlDetails [1] Extensions OPTIONAL, -- crlExtensions (e.g. crl number) } A CA may use such an announcement to warn (or notify) a subject that its certificate is about to be (or has been) revoked. This would typically be used where the request for revocation did not come from the subject concerned. 3.3.16. CRL Announcement When a CA issues a new CRL (or set of CRLs) the following data structure may be used to announce this event. CRLAnnContent ::= SEQUENCE OF CertificateList 3.3.17. PKI Confirmation content This data structure is used in three-way protocols as the final PKIMessage. Its content is the same in all cases - actually there is no content since the PKIHeader carries all the required information. PKIConfirmContent ::= NULL Farrell, Adams, Ford [Page 19]
INTERNET-DRAFT June 1996 4. PKI Management Operations The certificate management protocol exchanges defined in this section support management communications between client systems, each of which supports one or more users, and CAs. In addition, one management protocol exchange is defined for use between two CAs, for the purpose of establishing cross-certificates. Each exchange is defined in terms of a sequence of messages between the two systems concerned. This section defines the contents of the messages exchanged. The protocols for conveying these exchanges in different environments (on-line, E-mail, and WWW) are specified in Section 5. The protocol exchanges defined in this document are as follows. 1. Registration/Certification One-Step Registration/Certification User Initialization/Certification 2. End-Entity Key Pair Update Update for Client-Generated Key Pair Update for Centrally-Generated Key Pair Centrally-Initiated Key Pair Update 3. Encryption Key Pair Recovery 4. Revocation Request 5. Cross-Certification 6. CA Key Pair Update 7. Certificate Publication 8. Revocation Publication 9. CRL Publication 10. Certificate Update 11. Cross-Certificate Update The following notes apply to the protocol exchange descriptions: -In exchanges between a client system and a CA, the protocol exchange is initiated by the client system. The one exception to this is the Centrally-Initiated Key Pair Update exchange. -To provide an upgrade path, a protocol version indicator is always included in the first message of an exchange. -A message type indicator is included in the protected part of all messages. -All messages include an optional transaction identifier which is used to assist correlation of request and response messages for one transaction. This identifier is generated by the initiator of the exchange and will typically include the initiator's name plus a transaction sequence number. -The initial message from the client to the CA may optionally contain the client system time. This is used to facilitate the correction of client time problems by central administrators. -Responses from CA to client include the CA system time. The client can use this time to check that its own system time is within a reasonable range. -Random numbers are used in some of the protocols to prevent replay of the exchanges. Farrell, Adams, Ford [Page 20]
INTERNET-DRAFT June 1996 -Responses can be aborted at any time. An enumerated error code is sent from the aborting end and can be decoded into a user readable error string at the other end. Error codes are not specified in this version of this document. -Items in square brackets [] are optional. -In every instance in which a public key is transferred, it is transferred in the form of X.509 subjectPublicKeyInfo, including algorithm identifier and (optional) parameters. -When a new key pair is generated by a client, a key identifier may optionally be sent to the CA along with the public key for inclusion in the certificate. However, the CA may override this value with a key identifier of its own. If the client is concerned about the key identifier value used, it should check the new certificate. -Where this description refers to an encryption key pair, this could be a key pair for RSA key transport or could be key pair for key establishment using, for example, a Diffie-Hellman based algorithm. 4.1 Registration/Certification There are various approaches to this operation. 4.1.1. One-Step Registration/Certification For simple end entities this operation involves an out-of-band (or indeed implicit) request to an RA or CA. If no RA is involved then the CA in question simply prepares a PSE for the end entity. When an RA is involved the RA creates a certification request (CertReq) message for the end entity in question and sends this to the appropriate CA. When an RA is involved the steps required are as follows. 1.The RA gathers the information required for the certification request. 2.The RA creates the certification request message (CertReq); at this point the RA may provide the end entity with its PSE if the PSE doesn't need to contain the end entity's own certificate(s). 3.The CertReq message is transported to the CA. 4.The CA processes the CertReq; this results in the creation of a certification response (CertRep) message. 5.The CertRep message is transported to the RA. 6.The RA processes the CertRep. Depending on its content some looping may be required; that is, the RA may have to await further responses or generate a new CertReq for this end entity <>. Once the required certificates have been acquired the RA can prepare the end entity's PSE (assuming that the PSE contains the end entity's certificates). 7.The end entity receives the PSE and if necessary verifies that the CA public key contained therein is correct. Farrell, Adams, Ford [Page 21]
INTERNET-DRAFT June 1996 We impose the following constraints on the certification request message. 1.The RA must provide the protectionAlg field of the PKIHeader and must protect the CertReq message. The name in the sender field of the PKIHeader must be usable when verifying the protection. 2.The messageType field of the PKIMessage must contain the CertReq value. 3.The CertReqContent supplied must contain values for the following fields (i.e. these are mandated for this operation): - version - subject - validity. 4.If the RA does not provide the subjectPublicKeyInfo field this indicates that the RA is requesting a centrally-generated key pair and that the CA return the end entity's private key encrypted (using an EncPrivKey structure) for the end-entity or for the RA according to policy (and the type of PSE in use). If the RA does provide the subjectPublicKeyInfo field this does not mean that the RA need have generated the end entity's key pair, (which is an option) but simply that the RA has a "good" copy of the end entity's public key. All conforming CA implementations must be able to process any certification request received. Some CA implementations may however, only ever be able to reject requests which contain specific options (e.g., some CA implementations may not allow RAs to request a particular serial number for a certificate). 4.1.2. Initialization 4.1.2.1. End-Entity-Generated Encryption Key Pair 4.1.2.1.1. Overview of Exchange This protocol exchange is used to support client initialization, including certificate issuance, for one user, with provision for simultaneously establishing and certifying separate key pairs for digital signature and encryption (or encryption key exchange) purposes. Both key pairs are generated by the client and no private key is exposed to the CA. Generation and certification of the encryption key pair is optional. Prior to conducting this exchange, the user must have registered with the CA, using either a face-to-face registration exchange or some other means. Following registration, the CA creates a secret data item, called an authorization code, and transfers this data item by out-of-band means to the user. The authorization code is used to establish authentication and integrity protection of the user initialization/certification on-line exchange. This is done by generating a symmetric key based on the authorization code and using this symmetric key for generating Message Authentication Codes (MACs) on all exchanges between client and CA. Farrell, Adams, Ford [Page 22]
INTERNET-DRAFT June 1996 In the first two messages exchanged, the client sends its user signature public key (and, optionally, a client-generated encryption public key) to the CA and the CA returns the currently valid CA certificate(s). This exchange of public keys allows the client and CA to authenticate each other. 4.1.2.1.2. Detailed Description The user receives a reference number and a secret machine-generated authorization code from the CA administrator. Both pieces of information are transferred to the user in a secure manner which preserves their integrity and confidentiality. The reference number is used to uniquely identify the client at the CA and the authorization code is used to secure the exchange in terms of integrity. The reference number is used instead of a DN to uniquely identify the client because a DN may be lengthy and difficult for a user to manually type without error. After the reference number and authorization code have been entered by the user, the client generates: - a client random number, - (if a new user signature key pair is required) a new user signature key pair, - (if a new client-generated encryption key pair is required) a new encryption key pair. The client securely stores locally any new signature private key and/or client-generated encryption private key. The client then sends the message InitReq to the CA. The entire structure is protected from modification with a MAC based on the authorization code. Upon receipt of the InitReq message, if the CA recognizes the reference number and if the protocol version is valid, it saves the client random number, generates its own random number (CA random number), and validates the MAC. Then for the user encryption public key, it creates: - a new certificate for the user's digital signature public key, - (if a new client-generated encryption key pair is required) a new certificate for the user's encryption public key. The CA responds to the client with the message InitRep. The entire structure is protected from modification with a MAC based on the authorization code. Upon receipt of the InitRep message, the client checks that its own system time is sufficiently close to the CA system time, checks the client random number, and validates the MAC. The client then securely stores the new certificates and acknowledges the transaction by sending back the message PKIConfirm. The fields in this message are protected from modification with a MAC based on the authorization code. Farrell, Adams, Ford [Page 23]
INTERNET-DRAFT June 1996 Upon receipt of the PKIConfirm message, the CA checks the random numbers and validates the MAC. If no errors occur, the CA archives the new user public-key certificate(s). 4.1.2.2. Centrally-Generated Encryption Key Pair 4.1.2.2.1. Overview of Exchange This protocol exchange is used to support client initialization, including certificate issuance, for one user, with provision for simultaneously establishing and certifying separate key pairs for digital signature and encryption (or encryption key exchange) purposes. The digital signature key pair is generated by the client. Optionally, a new encryption key pair is generated by (and, optionally, backed up by) a central facility associated with the CA. Prior to conducting this exchange, the user must have registered with the CA, using either a face-to-face registration exchange or some other means. Following registration, the CA creates a secret data item, called an authorization code, and transfers this data item by out-of-band means to the user. The authorization code is used to establish authentication and integrity protection of the user initialization/certification on-line exchange. This is done by generating a symmetric key based on the authorization code and using this symmetric key for generating Message Authentication Codes (MACs) on all exchanges between client and CA. In the first two messages exchanged, the client sends its user signature public key to the CA and the CA returns the currently valid CA certificate(s). This exchange of public keys allows the client and CA to authenticate each other. If a centrally-generated encryption key pair is to be established, the private key of the newly generated key pair is sent from the CA to the client. The client first generates a protocol encryption key pair and sends the public protocol encryption key to the CA. The CA creates a random symmetric key called the session key and encrypts the user encryption private key with it and then encrypts the session key with the public protocol encryption key it received from the client. The CA sends the encrypted user encryption private key and encrypted session key back to the client. The client uses its private protocol decryption key to decrypt the session key and then uses the session key to decrypt the encryption private key. The protocol encryption key pair and session key are discarded after the exchange. Farrell, Adams, Ford [Page 24]
INTERNET-DRAFT June 1996 4.1.2.2.2. Detailed Description The user receives a reference number and a secret machine-generated authorization code from the CA administrator. Both pieces of information are transferred to the user in a secure manner which preserves their integrity and confidentiality. The reference number is used to uniquely identify the client at the CA and the authorization code is used to secure the exchange integrity-wise. The reference number is used instead of a DN to uniquely identify the client because a DN may be lengthy and difficult for a user to manually type without error. After the reference number and authorization code have been entered by the user, the client generates: - a client random number, - (if a new user signature key pair is required) a new user signature key pair, - (if a new centrally-generated encryption key pair is required) a protocol encryption key pair. The client securely stores locally any new signature private key and/or client-generated encryption private key. The client then sends the message InitReq to the CA. The entire structure is protected from modification with a MAC based on the authorization code. Upon receipt of the InitReq message, if the CA recognizes the reference number and if the protocol version is valid, it saves the client random number, generates its own random number (CA random number), and validates the MAC. It then creates: - a new certificate for the user's digital signature public key, - (if a new centrally-generated encryption key pair is required) a session key, a new user encryption key pair, and a new certificate for the user encryption public key. The CA responds to the client with the message InitRep. If a new centrally-generated encryption key pair is being generated, the user encryption private key is encrypted using the session key and the session key is encrypted with the protocol encryption public key. The entire structure is protected from modification with a MAC based on the authorization code. Upon receipt of the InitRep structure, the client checks that its own system time is sufficiently close to the CA system time, checks the client random number, and validates the MAC. If a new centrally- generated encryption key pair is included, the client decrypts the encryption private key. The client then securely stores the new certificates and encryption private key (if present) and acknowledges the transaction by sending back the message PKIConfirm. The fields in this message are protected from modification with a MAC based on the authorization code. Farrell, Adams, Ford [Page 25]
INTERNET-DRAFT June 1996 Upon receipt of the PKIConfirm message, the CA checks the random numbers and validates the MAC. If no errors occur, the CA archives the new user public-key certificate(s) and (if there is a new centrally-generated encryption key pair and key recovery is to be supported) the encryption private key. 4.2 End Entity Key Pair Update 4.2.1. End-Entity-Generated Key Pair(s) 4.2.1.1. Overview of Exchange This exchange is used to update the signature key pair and/or client- generated encryption key pair of a user, (e.g., as a result of routine cryptoperiod expiry). A user must have a valid signature key pair in order to do this exchange. It is up to the client to determine when a new signature key pair should be generated; this has to be done prior to the expiration of its signature public-key certificate. A key pair update request from a client is digitally signed using the original user signature private key, this signature being verifiable using an existing signature certificate. If the key pair update is for a new user digital signature key, then the client signs the request message once more (including the first signature), this time using the new signature private key. The reason for this second signature is to prove to the CA that the client possesses both the new and old private keys. The request is verified at the CA by using the matching user signature public key. A protocol signature key pair is used to authenticate messages from the CA to the client. CA responses are signed with the protocol signature private key. A CA response is validated at the client by using a protocol signature public-key certificate which is included in the CA response. The protocol signature public-key certificate can be validated by using the CA certificate stored at the client. A new user initialization (as in Section 4.1) or key pair recovery (as in Section 4.5) must be done if the user signature key pair becomes invalid. Farrell, Adams, Ford [Page 26]
INTERNET-DRAFT June 1996 In some client system implementations, local key materials are stored in an encrypted key data disk file. A user may have several copies of this key data file on different computers. It is possible that a key update could occur and the user could forget to copy the updated key data file to all the computers they use. To help keep the client using the latest keys, the client sends the CA the serial number of the latest user signature public-key certificate it has in the key update request. Serial numbers are sent so that the CA can check if the client has the latest key pair. If the client does not have the latest signature private key and the signature public-key certificate serial number is equal to that of a previous certificate, the CA sends back an error code which indicates that the client has an old version of the key data file. After this, the client can either find the latest key data file or, if that fails, initiate a key recovery exchange. 4.2.1.2. Detailed Description The client initiates the key update exchange by creating a new signature and/or encryption key pair and generating a random number (client random number). The client then sends the message KeyUpdReq to the CA . The fields in this message are protected from modification and authenticated by a digital signature using the pre- existing user signature private key. If the update includes a new signature key pair, the result is additionally signed using the new user signature private key. Upon receipt of the KeyUpdReq message, the CA checks the protocol version, checks the serial number, saves the client random number, generates its own random number (CA random number) and verifies the signature using the previous user verification key which is archived at the CA. If a user digital signature key pair is being updated, the CA also checks the second signature. It then generates new user signature and/or encryption public-key certificate(s). The CA responds with the message KeyUpdRep. The fields in this message are protected from modification and authenticated by a digital signature using the CA protocol signature private key. Upon receipt of the KeyUpdReq message, the client verifies the digital signature using the protocol verification key contained in the protocol signature public-key certificate, checks that its own system time is close to the CA system time, and checks the received client random number. The client then securely stores locally the new user public-key certificate(s). It responds with the message PKIConfirm. The fields in this message are protected from modification and authenticated by a digital signature using the pre- existing user signature private key. Upon receipt of the PKIConfirm message, the CA checks that the client and CA random numbers are the same as the ones initially generated, and verifies the received signature using the previous user signature public key which is archived at the CA. The CA then archives the new user public-key certificate(s) and updates its data stores to reflect the new status of the user. Farrell, Adams, Ford [Page 27]
INTERNET-DRAFT June 1996 4.2.2. Centrally-Generated Encryption Key Pair 4.2.2.1. Overview of Exchange This exchange is used to update the encryption key pair of a user, under the assumption that encryption key pairs are generated (and, optionally, backed up) centrally. A user must have a valid signature key pair in order to do this exchange. It is up to the client to determine when a new encryption key pair should be generated; this must be done some time before the expiration date in its encryption public-key certificate. 4.2.2.2. Detailed Description The client initiates the exchange by generating a random number (client random number) and a protocol encryption key pair. The client then sends the CA the message KeyUpdReq. The fields in this message are protected from modification and authenticated by a digital signature using the latest user signature private key. Upon receipt of the KeyUpdReq message, the CA checks the protocol version, checks the serial numbers, saves the client random number, generates its own random number (CA random number), generates a session key, and verifies the received signature using the latest user signature public key which is archived at the CA. It then generates a new end-user encryption key pair and encryption public- key certificate for the user. In the case where the encryption public- key certificate serial number is the second latest, the CA does not generate any keys and uses the latest encryption public-key certificate and encryption private key that it has. The CA responds with the message KeyUpdRep. In this message, the new or latest encryption private key is encrypted with the session key and the session key is encrypted with the protocol encryption key. The fields in this message are protected from modification and authenticated by a digital signature using the protocol signature private key. Upon receipt of the KeyUpdRep message, the client verifies the digital signature using the protocol signature public-key certificate, makes sure its own system time is close to the CA system time, and checks the received client random number. The client then decrypts the new or latest encryption private key and securely stores locally the new or latest user encryption public-key certificate and encryption private key. It responds with the message PKIConfirm. The fields in this message are protected from modification and authenticated by a digital signature using the latest user signature private key. Upon receipt of the PKIConfirm message, the CA checks that the client and CA random numbers are correct and verifies the signature using the latest user signature public key which is archived at the CA. If no errors occur, the CA archives the new user encryption public-key certificate and encryption private key, and updates its data stores to reflect the new status of the user. Farrell, Adams, Ford [Page 28]
INTERNET-DRAFT June 1996 4.2.3. Centrally-Initiated Key Pair Update 4.2.3.1. Overview of Exchange This exchange is used to update the encryption key pair of an user, under the assumption that encryption key pairs are generated (and, optionally, backed up) centrally. This exchange differs from the preceding exchange (Key Pair Update for Centrally-Generated Encryption Key Pair) in that the exchange is initiated by the CA rather than the client. 4.2.3.2. Detailed Description << To be supplied >> 4.3 Encryption Key Pair Recovery 4.3.1 Overview of Exchange This protocol exchange is used to support recovery in the event that a client no longer has a valid signature key pair (due to expiration or revocation), or client system key materials have been lost (e.g., as a result of a forgotten user password). This exchange assumes a system in which an encryption key pair has been centrally generated and backed up (by a central system associated with a CA). This exchange is very similar to the exchange for User Initialization/Certification with Centrally-Generated Encryption Key Pair. The client and CA start without a way to trust one another; that is, they have no reliable shared key pairs. 4.3.2 Detailed Description The user must first receive, by out-of-band means, a reference number and a secret machine-generated authorization code from the CA administrator. The on-line exchange then consists of a sequence of KeyRecReq, KeyRecRep and PKIConfirm, which are the same as the exchange in 4.1.2 except for two differences. First, the CA does not generate (or archive) a new encryption key pair and encryption public- key certificate for the user. Second, the user's entire encryption key history (list of encryption public-key certificates and matching encryption private keys) are sent back to the client with KeyRecRep. Farrell, Adams, Ford [Page 29]
INTERNET-DRAFT June 1996 4.4 Revocation Request 4.4.1 Overview of Exchange This protocol exchange is used to support a revocation request from a user or other authorized party. 4.4.2 Detailed Description << To be supplied >> 4.5 Cross-Certification The initiating CA is the CA which will become the subject of the cross-certificate, the responding CA will become the issuer of the cross-certificate. The initiating CA must be "up and running" before initiating the cross-certification operation. As with registration/certification there are a few possibilities here. 4.5.1. One-way request-response scheme: The cross-certification scheme is essentially a one way operation, that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross- certificates be created in "both directions" then each CA in turn must initiate a cross-certification operation (or use another scheme). The followings steps occur: 1.The initiating CA gathers the information required for the cross certification request 2.The initiating CA creates the cross-certification request message (CrossCertReq); 3.The CrossCertReq message is transported to the responding CA 4.The responding CA processes the CrossCertReq; this results in the creation of a cross-certification response (CrossCertRep) message. 5.The CrossCertRep message is transported to the initiating CA 6.The initiating CA processes the CrossCertRep; depending on its content some looping may be required, that is, the initiating CA may have to await further responses or generate a new CrossCertReq for this end entity <> Notes: 1.The CrossCertReq should contain a "complete" certification request, that is, all fields (including e.g. a BasicConstraints extension) should be specified by the initiating CA. 2.The CrossCertRep message should contain the OOBcert of the responding CA - the initiating CA should then verify this via the "out-of-band" mechanism. Farrell, Adams, Ford [Page 30]
INTERNET-DRAFT June 1996 4.5.2. Two-way request-response scheme: 4.5.2.1. Overview of Exchange This cross certification exchange allows two CAs to simultaneously certify each other. This means that each CA will create a certificate that contains the CA verification key of the other CA. Cross certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the on- line exchange. The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating Message Authentication Codes (MACs) on all messages exchanged. Serial numbers and protocol version are used in the same manner as in the above CA-client exchanges. 4.5.2.2. Detailed Description The requester CA initiates the exchange by generating a random number (requester random number). The requester CA then sends the responder CA the message CrossReq. The fields in this message are protected from modification with a MAC based on the authorization code. Upon receipt of the CrossReq message, the responder CA checks the protocol version, saves the requester random number, generates its own random number (responder random number) and validates the MAC. It then generates and archives a new requester certificate which contains the requester CA public key and is signed with the responder CA signature private key. The responder CA responds with the message CrossRep. The fields in this message are protected from modification with a MAC based on the authorization code. Upon receipt of the CrossRep message, the requester CA checks that its own system time is close to the responder CA system time, checks the received random numbers and validates the MAC. It then generates and archives a new responder certificate which contains the responder CA public key and is signed by the requester CA signature private key. The requester CA responds with the message PKIConfirm. The fields in this message are protected from modification with a MAC based on the authorization code. Upon receipt of the PKIConfirm message, the responder CA checks the random numbers, archives the responder certificate, and validates the MAC. It writes both the request and responder certificates to the Farrell, Adams, Ford [Page 31]
INTERNET-DRAFT June 1996 Directory. It then responds with its own PKIConfirm message. The fields in this message are protected from modification with a MAC based on the authorization code. Upon receipt of the PKIConfirm message, the requester CA checks the random numbers and validates the MAC. The requester CA writes both the requester and responder certificates to the Directory. 4.6 CA Key Pair Update The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus when a CA updates its key pair it must generate two new cACertificate attribute values if certificates are made available using an X.500 directory. When a CA changes its key pair those entities who have acquired the old CA public key via "out-of-band" means are most affected. It is these end entities who will need access to the new CA public key protected with the old CA private key. However, they will only require this for a limited period (until they have acquired the new CA public key via the "out-of-band" mechanism). This will typically be easily achieved when these end entity's certificates expire. The data structure used to protect the new and old CA public keys is a standard certificate (which may also contain extensions). There are no new data structures required. Notes: 1.This scheme does not make use of any of the X.509 v3 extensions as it should be able to work even for version 1 certificates. The presence of the KeyIdentifier extension would make for efficiency improvements. 2.While the scheme could be generalized to cover cases where the CA updates its key pair more than once during the validity period of one of its end entity's certificates, this generalization seems of dubious value. This means that the validity period of a CA key pair must be greater than the validity period of any certificate issued by that CA using that key pair. 3.This scheme forces end entities to acquire the new CA public key on the expiry of the last certificate they owned which was signed with the old CA private key (via the "out-of-band" means). Certificate and/or key update operations occurring at other times do not necessarily require this (depending on the end entity's equipment). Farrell, Adams, Ford [Page 32]
INTERNET-DRAFT June 1996 4.6.1. CA Operator actions To change the key of the CA, the CA operator does the following: 1.Generate a new key pair. 2.Create a certificate containing the old CA public key signed with the new private key (the "old with new" certificate). 3.Create a certificate containing the new CA public key signed with the old private key (the "new with old" certificate). 4.Create a certificate containing the new CA public key signed with the new private key (the "new with new" certificate). 5.Publish these new certificates via the directory and/or other means. (A CAKeyUpdAnn message.) 6.Export the new CA public key so that end entities may acquire it using the "out-of-band" mechanism. The old CA private key is then no longer required. The old CA public key will however remain in use for some time. The time when the old CA public key is no longer required (other than for non-repudiation) will be when all end entities of this CA have acquired the new CA public key via "out-of-band" means. The "old with new" certificate should have a validity period starting at the generation time of the old key pair and ending at the time at which the CA will next update its key pair. The "new with old" certificate should have a validity period starting at the generation time of the new key pair and ending at the time by which all end entities of this CA will securely possess the new CA public key. The "new with new" certificate should have a validity period starting at the generation time of the new key pair and ending at the time at which the CA will next update its key pair. <> 4.6.2. Verifying Certificates. <> Normally when verifying a signature the verifier simply(!) verifies the certificate containing the public key of the signer. However, once a CA is allowed to update its key there are a range of new possibilities. These are shown in the table below. Farrell, Adams, Ford [Page 33]
INTERNET-DRAFT June 1996 Directory contains NEW Directory contains only OLD and OLD public keys public key (due to e.g. delay in publication) PSE PSE Contains PSE Contains PSE Contains Contains OLD public NEW public OLD public NEW public key key key key Signer's Case 1: Case 3: Case 5: Case 7: certifica This is In this case Although the In this case te is the the verifier CA operator the CA protected standard must access has not operator has using NEW case where the updated the not updated public the directory in directory the the directory key verifier order to get verifier can and so the can the value of verify the verification directly the NEW certificate will FAIL verify the public key directly - certificat this is thus e without the same as using the case 1. directory Signer's Case 2: Case 4: Case 6: Case 8: certifica In this In this case The verifier Although the te is case the the verifier thinks this CA operator protected verifier can directly is the has not using OLD must verify the situation of updated the public access the certificate case 2 and directory the key directory without will access verifier can in order using the the verify the to get the directory directory, certificate value of however the directly - the OLD verification this is thus public key will FAIL the same as case 4. 4.6.2.1. Verification in cases 1, 4, 5 and 8. In these cases the verifier has a local copy of the CA public key which can be used to verify the certificate directly. This is the same as the situation where no key change has ever occurred. Note that case 8 may arise between the time when the CA operator has generated the new key pair and the time when the CA operator stores the updated attributes in the directory. Case 5 can only arise if the CA operator has issued both the signer's and verifier's certificates during this "gap" (the CA operator should avoid this as it leads to the failure cases described below). Farrell, Adams, Ford [Page 34]
INTERNET-DRAFT June 1996 4.6.2.2. Verification in case 2. In case 2 the verifier must get access to the old public key of the CA. The verifier does the following: 1.Lookup the CACertificate attribute in the directory and pick the appropriate value (based on validity periods) 2.Verify that this is correct using the new CA key (which the verifier has locally). 3.If correct then check the signer's certificate using the old CA key. Case 2 will arise when the CA operator has issued the signer's certificate, then changed key and then issued the verifier's certificate, so it is quite a typical case. 4.6.2.3. Verification in case 3. In case 3 the verifier must get access to the new public key of the CA. The verifier does the following: 1.Lookup the CACertificate attribute in the directory and pick the appropriate value (based on validity periods). 2.Verify that this is correct using the old CA key (which the verifier has stored locally). 3.If correct then check the signer's certificate using the new CA key. Case 3 will arise when the CA operator has issued the verifier's certificate, then changed key and then issued the signer's certificate, so it is also quite a typical case. 4.6.2.4. Failure of verification in case 6. In this case the CA has issued the verifier's PSE containing the new key without updating the directory attributes. This means that the verifier has no means to get a trustworthy version of the CA's old key and so verification fails. Note that the failure is the CA operator's fault. 4.6.2.5. Failure of verification in case 7. In this case the CA has issued the signer's certificate protected with the new key without updating the directory attributes. This means that the verifier has no means to get a trustworthy version of the CA's new key and so verification fails. Note that the failure is again the CA operator's fault. Farrell, Adams, Ford [Page 35]
INTERNET-DRAFT June 1996 4.6.3. Revocation - Change of CA key As we saw above the verification of a certificate becomes more complex once the CA is allowed to change its key. This is also true for revocation checks as the CA may have signed the CRL using a newer private key than the one that is within the user's PSE. The analysis of the alternatives is as for certificate verification. 4.6.4. Example of CA key update The following example should make the scheme clearer: 1.A CA is established on 1-Jan-1997, its key pair will be used for three years (until 31-Dec-1999, party-time). 2.Alice gets a new certificate valid for one year starting 21- Dec-1999 and acquires the CA public key via the appropriate out of band means. 3.Alice's is the last certificate created by the CA before the CA key update and is the one which will expire latest. 4.The CA generates its new key pair on 31-Dec-1999 and produces the two certificates. The "old-with-new" certificate contains a validity period from 1-Jan-1997 to 31-Dec-2000. The "new-with-old" certificate contains a validity period from 1-Jan-2000 to 31-Dec- 2000. The CA operator deletes the old private key. 5.Bob gets certified (again for a year) on 10-Jan-2000. Bob also acquires the new CA public key via the appropriate "out-of- band" means. 6.On 11-Jan-2000 Alice sends a signed message to Bob. Bob's verification is as described in case 2 above. 7.Bob replies with a signed message, Alice's verification procedure is as given in case 3 above. 8.On 20-Dec-2000 Alice gets a new certificate and acquires the new CA public key via the "out-of-band" means. 9.At midnight on 31-Dec-2000 the CA operator can delete the "new-with-old" certificate from the directory (or wherever else). Farrell, Adams, Ford [Page 36]
INTERNET-DRAFT June 1996 These events are shown in the time-line diagram below. 1996 1997 1998 1999 2000 2001 year ----------+---------------------------+-+-+----+-+----->> | | | | | | | | | | | | | | | | | +-- "new-with-old" | | | | | deleted | | | | | | | | | +-- Alice updated | | | | | | | +-- Bob certified | | | | | +-- CA key update | | | +-- Alice certified +-- CA established "old-with-new" validity: |---------------------------------------------->>>>>> "new-with-old" validity: |-------| "new-with-new" validity: |--------------->>>>>> 4.7 Certificate Publication <> 4.8 Revocation Publication <> This is the announcement of a specific revocation (which occurred as a result of a successful revocation request/response exchange), as opposed to the publication of an actual CRL. 4.9 CRL Publication <> 4.10 Certificate Update <> 4.11 Cross-Certificate Update <> Farrell, Adams, Ford [Page 37]
INTERNET-DRAFT June 1996 5. Transports 5.1 On-line Management Protocol << To be supplied. This subsection will specify a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 over a TCP connection. >> 5.2 Management Protocol via E-mail << To be supplied. This subsection will specify a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via Internet mail. >> 5.3 Management Protocol via HTTP << To be supplied. This subsection will specify a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 over WWW browser-server links, employing HTTP or related WWW protocols. >> 6. Samples The following samples will be further elaborated in later drafts (which will include encodings for the messages, etc.) For now we just present them as walkthroughs. The overall scenario is as follows: A CA is established and an RA is certified. The RA gets a "simple" end entity certified (which is actually a http daemon) and does a few operations involving this end entity. A "sophisticated" end entity gets itself certified by a second CA. The first CA asks to be cross-certified by the second CA. The second CA updates its key pair. We will use the following names: first CA cn=theCA;o=small;c=ie RA cn=theRA;o=sse;c=ie "simple" end entity cn=httpd;o=sse;c=ie second CA cn=caTWO;o=bnr;c=ca "sophisticated" end entity cn=sophisticated;o=bnr;c=ca We will just use the commonName components of the above names in the text below. Farrell, Adams, Ford [Page 38]
INTERNET-DRAFT June 1996 6.1 First CA established theCA has the following characteristics: - it uses RSA and MD5 for its own key pair - it has the following contact points available: theCA@small.ie for mail http://www.small.ie/theCA for http ftp://ftp.small.ie/pub/theCA for ftp cacontact.theCA.small.ie for TCP/IP cn=theCA;o=small;c=ie for X.500 - its key pair will be valid for two years - it is established on Jan. 1st 1997 The following (protocol visible) events occur: - theCA generates its initial key pair and publishes this in various ways - theCA publishes its initial CRL is various ways 6.2 RA Certification theRA has the following characteristics: - it uses RSA and MD5 for its own key pair - it has an email address of: theRA@sse.ie The following events occur - theRA generates its key pair and submits request to theCA - theCA rejects this initial request (public key generated is too short) - theRA submits a new request - theCA accepts request and issues response including certificate (but with reduced validity period since theCA is now in a bad mood:-) - theRA publishes its certificate 6.3 "simple" End entity simple has the following characteristics: - it only needs a key pair for signing (i.e. no encryption) - it is an http daemon Farrell, Adams, Ford [Page 39]
INTERNET-DRAFT June 1996 The following events occur: - theRA generates key pair; sends request to theCA on behalf of httpd - theRA forwards certification information to httpd - theRA publishes certificate on behalf of httpd - httpd (i.e., its administrator) imports certification information - theRA issues certificate update request to theCA - theCA sends response to theRA including new certificate - theRA publishes new certificate - theRA generates new key pair for httpd and issues request for key update to theCA - theCA accepts request and issues response to theRA including cert. - theRA publishes certificate on behalf of httpd - theRA forwards certification information to httpd - theRA asks for httpd's certificate to be revoked - theCA revokes httpd's certificate and publishes the new CRL 6.4 The "sophisticated" end entity sophisticated has the following characteristics: - it deals directly with caTWO - it uses DSA with SHA-1 The following events occur: - end entity receives init. data (containing CA name and public key) - end entity generates key pair and submits request to CA - CA accepts request and issues response to end entity (not including certificate) - CA publishes certificate on behalf of end entity - end entity imports CA response 6.5 Cross-certification In order to allow sophisticated to use httpd theCA must be certified by caTWO. The following events occur: - theCA issues a request for cross-certification to caTWO - caTWO accepts this request and issues a cross-certificate (but with more restrictions than theCA had asked for) - theCA publishes the cross-certificate - theCA asks for the cross-certificate to be updated - caTWO issues the new cross-certificate - theCA publishes the new cross-certificate 6.6 CA Key Update Eventually (in late 1998) theCA decides to update its key pair. The following events occur: - theCA generates a new key pair - theCA publishes its new key (and collateral data structures) Farrell, Adams, Ford [Page 40]
INTERNET-DRAFT June 1996 7. Security Considerations This entire memo is about security mechanisms. Authors' Addresses Stephen Farrell Software and Systems Engineering Ltd. Fitzwilliam Court Leeson Close Dublin 2 IRELAND stephen.farrell@sse.ie Carlisle Adams Nortel Secure Networks PO Box 3511, Station C Ottawa, Ontario Canada KY 4H7 cadams@bnr.ca Warwick Ford Nortel Secure Networks PO Box 3511, Station C Ottawa, Ontario Canada KY 4H7 wford@bnr.ca
