Internet Draft C. Adams (Entrust Technologies) PKIX Working Group M. Myers (VeriSign) draft-ietf-pkix-cmmf-00.txt Expires in 6 months February 1998 Internet X.509 Public Key Infrastructure Certificate Management Message Formats <draft-ietf-pkix-cmmf-00.txt> 1. 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). 2. Abstract This is a draft of the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Messages Formats (CMMF). It establishes harmonized message formats to be used in conjunction with security protocol implementations that require interaction with a Public Key Infrastructure (PKI). This draft is being discussed on the ''ietf-pkix'' mailing list. To subscribe, send a message to ietf-pkix-request@tandem.com with the single word subscribe in the body of the message. 3. Introduction This document defines message formats to be used between a PKI client and a PKI server or service(where a PKI is defined to encompass the roles of Registration Authority and Certification Authority). Using these message formats, a PKI client may: - Request public key certification - Responses may include CA-generated key pairs - Request revocation of a certificate - Receive announcements directly from a PKI on: - CA Key Update - Renewed Certificates - Subscriber Revocation notices - CRL refresh Myers, Adams [Page 1]
INTERNET DRAFT February 1998 - Request data of a PKI, including: - Ones own or others certificate - CRL download The specification of a transaction protocol using these message formats is beyond the scope of this document. It is expected that such protocols will be defined with a view towards localized interoperability needs. Where requirements exist to exchange information which is substantially aligned with the message content in this document, such protocols should reference these message formats. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. 4. Common Data Structures Several structures are common to more than one message format. These are: - Status information - Failure information - Certificate identification - Encrypted values 4.1 Status Information Responses may include status information pertaining to a prior request. 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 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 keyUpdateWarning (6) -- update already done for the oldCertId specified in -- FullCertTemplate } Myers, Adams [Page 2]
INTERNET DRAFT February 1998 4.2 Failure Information The following values may be used to provide more information about failure cases. PKIFailureInfo ::= BIT STRING { -- since we can fail in more than one way! -- More codes may be added in the future if/when required. badAlg (0), -- unrecognized or unsupported Algorithm Identifier badMessageCheck (1), -- integrity check failed (e.g., signature did not verify) badRequest (2), -- transaction not permitted or supported badTime (3), -- messageTime was not sufficiently close to the system time, -- as defined by local policy badCertId (4), -- no certificate could be found matching the provided criteria badDataFormat (5), -- the data submitted has the wrong format wrongAuthority (6), -- the authority indicated in the request is different from the -- one creating the response token incorrectData (7), -- the requester's data is incorrect (used for notary services) missingTimeStamp (8) -- when the timestamp is missing but should be there (by policy) } PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusString PKIFreeText OPTIONAL, failInfo PKIFailureInfo OPTIONAL } 4.3 Certificate Identification In order to identify particular certificates the following data structure is used. CertId ::= SEQUENCE { issuer GeneralName, serialNumber INTEGER } 4.4 Encrypted Values Certain values in responses may require encryption beyond that that which may be performed in a PKI protocol. For example, a CA may generate key pairs for subscribers but deliver them via an RA. As a general rule RAs should be prohibited from unnecessary or inadvertent contact with a subscribers private keys. Myers, Adams [Page 3]
INTERNET DRAFT February 1998 EncryptedData ::= CHOICE { encryptedValue [0] EncryptedValue, cMSEnveloped [1] EnvelopedData, pKCS8 [2] EncryptedPrivateKeyInfo, pKCS12 [3] KeysAndCertificates } The syntax of encryptedValue is defined below. The EnvelopedData syntax of cMSEnveloped is defined by [CMS]. The EncryptedPrivateKeyInfo syntax of pKCS8 is defined by [PKCS8]. The KeysAndCertificates syntax is defined by [pKCS12]. EncryptedValue ::= SEQUENCE { encValue BIT STRING, -- the encrypted value itself intendedAlg [0] AlgorithmIdentifier OPTIONAL, -- the intended algorithm for which the value will be used symmAlg [1] AlgorithmIdentifier OPTIONAL, -- the symmetric algorithm used to encrypt the value encSymmKey [2] BIT STRING OPTIONAL, -- the (encrypted) symmetric key used to encrypt the value keyAlg [3] AlgorithmIdentifier OPTIONAL -- algorithm used to encrypt the symmetric key } Use of this data structure requires that the creator and intended recipient respectively be able to encrypt and decrypt. Typically, this will mean that the sender and recipient have, or are able to generate, a shared secret key. For Diffie-Hellman keys, the encSymmKey field of EncryptedValue is not included. For RSA, encSymmKey is a symmetric key encrypted under the subscribers public RSA key. 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 recipients public key. 5. Message Formats 5.1 Certification Request [CRMF] defines the preferred structure for production of certification requests. It is a flexible mechanism designed to enable mandatory and optional cryptographic algorithms, centralized key generation, a variety of proof-of-possession options and several other control features useful to a robust PKI client enrollment capability. Current industry practice can be supported for clients through use of the following structure. PKCSReq ::= SEQUENCE { endEntityInfo EndEntityInfo, regInfo OCTET STRING OPTIONAL } Myers, Adams [Page 4]
INTERNET DRAFT February 1998 The endEntityInfo field is used to carry a public key, to prove possession of the public key and to provide additional ASN.1 attributes useful to production of the resulting certificate. The regInfo field contains supplementary information related to the context of the certification request when such information is required to fulfill a certification request. This information could include subscriber contact information, billing information or other ancillary information useful to fulfillment of the certification request. Current industry practice has established two structures for producing a signed public key. The use of explicit tagging below allows disambiguation among these options while maintaining bits on the wire compatibility with prior implementations: endEntityInfo :: CHOICE { pKCS10 CertificationRequest, signedKey [0] SignedPublicKeyAndChallenge } SignedPublicKeyAndChallenge :: SEQUENCE { publicKeyAndChallenge PublicKeyAndChallenge, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } PublicKeyAndChallenge :: SEQUENCE { spki SubjectPublicKeyInfo, challenge IA5String } CertificationRequest ::= SEQUENCE { certificationRequestInfo SEQUENCE { version INTEGER, subject Name, subjectPublicKeyInfo SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } attributes [0] IMPLICIT SET OF Attribute } signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } The client MAY incorporate one or more standard X.509 v3 extensions in the request as an ExtensionReq attribute: ExtensionReq ::= SEQUENCE OF Extension where Extension is imported from PKIX Part 1 and ExtensionReq is identified by the OID value {pkcs-9 14}. Myers, Adams [Page 5]
INTERNET DRAFT February 1998 5.2 Certification Response Two options are established for the response to a certification request: a simple form that enables basic interoperability and a form that enables generation of subscriber private keys by the CA. 5.2.1 Use of SignedData [CMS] supports a degenerate case of the SignedData content type where there are no signers on the content. This degenerate case is used to convey certificate and CRL information. Certification Authorities MAY use this format for returning certificate information resulting from the successful fulfillment of a certification request. The certificate response MUST include the actual subject certificate corresponding to the information in the certification request. The response SHOULD include other certificates which link the issuer to higher level certification authorities and corresponding CRLs. CertRep ::= SEQUENCE { response SignedData, OPTIONAL rspInfo OCTET STRING } Successful requests would include the resulting certificate(s) in the response field along with any additional {name, value} information useful to client-side processing of a successful request. In the event of an unsuccessful request, the rspInfo field contains information regarding the failure which may be useful to the requesting entity. RspInfo content MAY include state information the PKI client needs such as the contents of the regInfo in the CRMF ( see [CRMF]). Other additional data could include detailed error information that uniquely identifies an information field supplied in the original regInfo; e.g. the Zip Code was incorrect for the specified address or locale or billing failed because credit card information was in error. 5.2.2 CertRepContent A CertRepContent data structure contains a CA public key, a status value and optionally failure information, a subject certificate, and an encrypted private key. CertRepContent ::= SEQUENCE { caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, response SEQUENCE of CertResponse } CertResponse ::= SEQUENCE { certReqId INTEGER, -- to match this response with corresponding request (a value -- of -1 is to be used if certReqId is not specified in the -- corresponding request) status PKIStatusInfo, certifiedKeyPair CertifiedKeyPair, OPTIONAL } Myers, Adams [Page 6]
INTERNET DRAFT February 1998 CertifiedKeyPair ::= SEQUENCE { certOrEncCert CertOrEncCert, privateKey [0] EncryptedValue OPTIONAL, publicationInfo [1] PKIPublicationInfo OPTIONAL } CertOrEncCert ::= CHOICE { certificate [0] Certificate, encryptedCert [1] EncryptedValue } Given an EncryptedCert and the relevant decryption key the certificate may be obtained. The purpose of this is to allow a CA to return the value of a certificate, but with the constraint that only the intended recipient can obtain the actual certificate. The benefit of this approach is that a CA may reply with a certificate even in the absence of a proof that the requester is the end entity which can use the relevant private key (note that the proof is not obtained until confirmation of receipt is received by the CA). Thus the CA will not have to revoke that certificate in the event that something goes wrong with the proof of possession. 5.3 GetCertInitial The GetCertInitial message is used to poll for the certificate associated with prior request if the response to that prior request was a CertRep message with a status of PENDING. Certificates are normally referenced using the CA DN and the certificate serial number. In this case however a certificate has not yet been issued. Thus the CA and Subject DNs are present in the message as a means to identify the requested certification. IssuerAndSubject ::= SEQUENCE { issuer Name, subject Name } 5.4 GetCRL This operation is used to retrieve CRLs from a certificate server or services repository. This message is useful in circumstances where a fully-deployed Directory is either infeasible or undesired. The GetCRL message body consists of the following syntax: GetCRL ::= SEQUENCE { issuerName Name, cRLName GeneralName, OPTIONAL time GeneralizedTime, OPTIONAL reasons ReasonFlags OPTIONAL } The Name component is the value of the Issuer DN in the subject certifi- cate. The cRLName component may be the value of CRLDistributionPoints in the subject certificate or equivalent value in the event the certificate does not contain such a value. The time component is used by the client Myers, Adams [Page 7]
INTERNET DRAFT February 1998 to specify from among potentially several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. In the absence of a time component, the CA always returns with the most recent CRL. The reasons field can be used to specify from among CRLs partitioned by reason codes. 5.5 Revocation Request Two options are established to enable programmatic submission of a revocation request. 5.5.1 RevRequest RevRequest ::= SEQUENCE { issuerName Name, serialNumber INTEGER, reason ReasonFlags, passphrase OCTET STRING OPTIONAL, comment PrintableString OPTIONAL } For a revocation request to become a reliable object in the event of a dispute, a strong proof of originator authenticity is required. A Registration Authoritys digital signature on the request can provide this proof for certificates within the scope of the RAs revocation authority. However, in the instance when an end-entity has lost use of their signature private key, it is impossible to produce a reliable digital signature. [CRMF] provides for the use specification of a passphrase during enrollment which may be used as an alternative authenticator in the instance of loss of use. The acceptability of this practice is a matter of local security policy. 5.5.2 RevReqContent When requesting revocation of a certificate (or several certificates) the following data structure is used. RevReqContent ::= SEQUENCE OF RevDetails RevDetails ::= SEQUENCE { certDetails CertTemplate, -- allows requester 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 Draft Amendment (DAM), so CA knows what to use in -- Distribution point badSinceDate GeneralizedTime OPTIONAL, -- indicates best knowledge of sender crlEntryDetails Extensions -- requested crlEntryExtensions } Myers, Adams [Page 8]
INTERNET DRAFT February 1998 5.6 Revocation Response The response to the above message. If produced, this is sent to the requester of the revocation. (A separate revocation announcement message MAY be sent to the subject of the certificate for which revocation was requested.) RevRepContent ::= SEQUENCE { status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, -- in same order as was sent in RevReqContent revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, -- IDs for which revocation was requested (same order as status) crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL -- the resulting CRLs (there may be more than one) } 5.7 Challenge-Response Proof Of Possession [CRMF] establishes the basis for a challenge-response proof of possession technique. The challenge-response messages for proof of possession of a private decryption key are specified as follows (see [MvOV97, p.404], for details). POPODecKeyChallContent ::= SEQUENCE OF Challenge -- One Challenge per encryption key certification request (in the -- same order as these requests appear in FullCertTemplates). Challenge ::= SEQUENCE { owf AlgorithmIdentifier OPTIONAL, -- MUST be present in the first Challenge; MAY be omitted in any -- subsequent Challenge in POPODecKeyChallContent (if omitted, -- then the owf used in the immediately preceding Challenge is -- to be used). witness OCTET STRING, -- the result of applying the one-way function (owf) to a -- randomly-generated INTEGER, A. [Note that a different -- INTEGER MUST be used for each Challenge.] challenge OCTET STRING -- the encryption (under the public key for which the cert. -- request is being made) of Rand, where Rand is specified as -- Rand ::= SEQUENCE { -- int INTEGER, -- - the randomly-generated INTEGER A (above) -- sender GeneralName -- - the sender's name (as included in PKIHeader) -- } } POPODecKeyRespContent ::= SEQUENCE OF INTEGER -- One INTEGER per encryption key certification request (in the -- same order as these requests appear in FullCertTemplates). The -- retrieved INTEGER A (above) is returned to the sender of the -- corresponding Challenge. Myers, Adams [Page 9]
INTERNET DRAFT February 1998 5.8 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 5.9 Announcements >From time to time a PKI may need to distribute information to its clients or subscribers. These messages are generally unsolicited and consequently reverse the flow of request-response behavior. Implementers of protocols that use these message formats should take this effect into account. 5.9.1 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 } To change the key of the CA, the CA 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 6.Export the new CA public key so that end entities may acquire it using the "out-of-band" mechanism (if required). 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 securely acquired the new CA public key. The "old with new" certificate must have a validity period starting at the generation time of the old key pair and ending at the expiry date of the old public key. Myers, Adams [Page 10]
INTERNET DRAFT February 1998 The "new with old" certificate must 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 (at the latest, the expiry date of the old public key). The "new with new" certificate must have a validity period starting at the generation time of the new key pair and ending at the time by which the CA will next update its key pair. 5.9.2 Certificate Announcement This structure MAY be used to announce the existence of certificates. Note that this message 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 5.9.3 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 5.9.4 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, willBeRevokedAt GeneralizedTime, badSinceDate GeneralizedTime, crlDetails Extensions OPTIONAL -- extra CRL details(e.g., crl number, reason, location, etc.) } 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. The willBeRevokedAt field contains the time at which a new entry will be added to the relevant CRLs. 5.10 Key recovery Response For key recovery responses the following syntax is used. For some status values (e.g., waiting) none of the optional fields will be present. Myers, Adams [Page 11]
INTERNET DRAFT February 1998 KeyRecRepContent ::= SEQUENCE { status PKIStatusInfo, newSigCert [0] Certificate OPTIONAL, caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL } 5.11 PKI General Message content >From time to time a PKI MAY announce other information not explicitly called out in this specification. In such cases the following structure MAY be used to unambiguously identify this information when transmitted as a PKI message. InfoTypeAndValue ::= SEQUENCE { infoType OBJECT IDENTIFIER, infoValue ANY DEFINED BY infoType OPTIONAL } -- Example InfoTypeAndValue contents include, but are not limited to: -- { CAProtEncCert = {id-it 1}, Certificate } -- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier } -- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier } -- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier } -- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent } -- { CurrentCRL = {id-it 6}, CertificateList } -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4} -- This construct MAY also be used to define new PKIX Certificate -- Management Protocol request and response messages, or general- -- purpose (e.g., announcement) messages for future needs or for -- specific environments. GenMsgContent ::= SEQUENCE OF InfoTypeAndValue -- May be sent by EE, RA, or CA (depending on message content). -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically -- be omitted for some of the examples given above. The receiver is -- free to ignore any contained OBJ. IDs that it does not recognize. -- If sent from EE to CA, the empty set indicates that the CA may send -- any/all information that it wishes. 5.12 PKI General Response content GenRepContent ::= SEQUENCE OF InfoTypeAndValue -- The receiver is free to ignore any contained OBJ. IDs that it does -- not recognize. 5.13 Error Message ErrorMsgContent ::= SEQUENCE { pKIStatusInfo PKIStatusInfo, errorCode INTEGER OPTIONAL, Myers, Adams [Page 12]
INTERNET DRAFT February 1998 -- implementation-specific error codes errorDetails PKIFreeText OPTIONAL -- implementation-specific error details } 6. SECURITY CONSIDERATIONS This entire memo is about security mechanisms. One cryptographic consideration is worth explicitly spelling out. In the protocols specified above, when an end entity is required to prove possession of a decryption key, it is effectively challenged to decrypt something (its own certificate). This scheme (and many others!) could be vulnerable to an attack if the possessor of the decryption key in question could be fooled into decrypting an arbitrary challenge and returning the cleartext to an attacker. Although in this specification a number of other failures in security are required in order for this attack to succeed, it is conceivable that some future services (e.g., notary, trusted time) could potentially be vulnerable to such attacks. For this reason we re-iterate the general rule that implementations should be very careful about decrypting arbitrary "ciphertext" and revealing recovered "plaintext" since such a practice can lead to serious security vulnerabilities. 7. References [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 9594-8: 1990 & 1993 (1995:E), July 1995. [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - PKCS #11: Cryptographic token interface standard", RSA Data Security Inc., Redwood City, California, April 28, 1995. [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing for Message Authentication", Internet Request for Comments 2104, February, 1997. Myers, Adams [Page 13]
INTERNET DRAFT February 1998 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet Request for Comments 2119 (Best Current Practice: BCP 14), March, 1997. [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 December, 1996. [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, Certificate Request Message Format, <draft-ietf-pkix-crmf-00.txt>, February, 1998 [CMS] R. Housley, Cryptographic Message Syntax <draft-ietf-smime-cms-02.txt> December, 1997 [PKCS8] Private Key Information Syntax Standard, v1.2 RSA Laboratories Technical Note November 1, 1993 Authors' Addresses Michael Myers VeriSign, Inc. 1390 Shorebird Way, Mountain View, CA 94043 mmyers@verisign.com Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08, Ottawa, Ontario Canada K1V 1A7 cadams@entrust.com
