PKIX Working Group Michael Myers (VeriSign) Internet Draft Xiaoyi Liu (Cisco) November 11, 1998 Barbara Fox (Microsoft) expires in six months Jeff Weinstein (Netscape) Certificate Management Messages over CMS 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 six months and MAY be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 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), munari.oz.au Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines a Certificate Management protocol using CMS (CMC). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and 2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA- signed certificates with Diffie-Hellman public keys. A small number of additional services are defined to supplement the core certificate request service. Throughout this specification the term CMS is used to refer to both [CMS] and [PKCS7]. For signedData the two specifications are equivalent. For envelopedData CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification. The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in [RFC 2119]. 1. Protocol Requirements Myers, Liu, Fox, Weinstein Page 1 Internet Draft November 1998 - The protocol is to be based as much as possible on the existing CMS, PKCS#10 and CRMF specifications. - The protocol must support the current industry practice of a PKCS#10 request followed by a PKCS#7 response as a subset of the protocol. - The protocol needs to easily support the multi-key enrollment protocols required by S/MIME and other groups. - The protocol must supply a way of doing all operations in a single- round trip. When this is not possible the number of round trips is to be minimized. - The protocol needs to support optional key escrow and key archival for encryption keys. - The protocol will be designed such that all key generation can occur on the client. - The mandatory algorithms must superset the required algorithms for S/MIME. - The protocol will contain POP methods. Optional provisions for multiple-round trip POP will be made if necessary. - The protocol will support deferred and pending responses to certificate request for cases where external procedures are required to issue a certificate. - The protocol needs to support arbitrary chains of local registration agents as intermediaries between certificate requesters and issuers. 2. Protocol Overview An enrollment transaction in this specification is generally composed of a single round trip of messages. In the simplest case an enrollment request is sent from the client to the server and an enrollment response is then returned from the server to the client. In some more complicated cases, such as delayed certificate issuance and polling for responses, more than one round trip is required. This specification supports two different request messages and two different response messages. Public key certification requests are based on the PKCS10 object. The two different request messages are (a) the bare PKCS10 (in the event that no other services are needed), and (b) the PKCS10 (or, optionally, a CRMF message) wrapped in a CMS encapsulation as part of a PKIData object. Public key certification responses are based on the CMS signedData object. The response may be either (a) a degenerate CMS signedData object (in the event no other services are needed), or (b) a ResponseBody object wrapped in a CMS signedData object. No special services are provided for doing either renewal (new certificates with the same key) or re-keying (new certificates on new keys) of clients. Instead a renewal/re-key message looks the same as any enrollment message, with the identity proof being supplied by existing certificates from the CA. A provision exists for Local Registration Agents (LRAs) to participate in the protocol by taking client enrollment messages, wrapping them in a Myers, Liu, Fox, Weinstein Page 2 Internet Draft November 1998 second layer of enrollment message with additional requirements or statements from the LRA and then passing this new expanded request on to the certification authority. This specification makes no assumptions about the underlying transport mechanism. The use of CMS is not meant to imply an email-based transport. Optional services available through this specification are transaction management, replay detection (through nonces), deferred certificate issuance, private key archival, certificate revocation requests and certificate/CRL fetching. 2.1 Terminology There are several different terms used in this document that we define here for convenience and consistency of usage: End-Entity refers to the entity that owns a key pair and for whom a certificate is issued. LRA is a Local Registration Agent. A local registration agent acts as an intermediary between an End-Entity and a Certificate Authority. Multiple LRAs can exist between the End-Entity and the Certificate Authority. CA is a Certificate Authority. A certificate authority is the entity that performs the actual issuance of a certificate. Client refers to an entity that creates a PKI request. In this document both LRAs and End-Entities can be clients. Server refers to the entities that process PKI requests and create PKI responses. CAs and LRAs can be servers in this document. 2.2 Protocol Flow Charts Figure 1 shows the Simple Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.1 and 4.3 below. Simple PKI Request Simple PKI Response ------------------------- -------------------------- +----------+ +------------------+ | PKCS #10 | | CMS "certs-only" | +----------+--------------+ | message | | | +------------------+------+ | Certificate Request | | | | | | CMS Signed Data, | | Subject Name | | no signerInfo | | Subject Public Key Info | | | | (K_PUB) | | signedData contains one | | Attributes | | or more certificates in | | | | the "certificates" | +-----------+-------------+ | portion of the | | signed with | | signedData. | | matching | | | Myers, Liu, Fox, Weinstein Page 3 Internet Draft November 1998 | K_PRIV | | encapsulatedContentInfo | +-------------+ | is empty. | | | +--------------+----------+ | unsigned | +----------+ Figure 1: Simple PKI Request and Response Messages Full PKI Request Full PKI Response ----------------------- ------------------------ +----------------+ +----------------+ | CMS signedData | | CMS signedData | | object | | object | +----------------+--------+ +----------------+--------+ | | | | | PKIData object | | ResponseBody object | | | | | | Sequence of: | | Sequence of: | | * | | * | | *| | * | | * | | * | | * | | | | | | where * == zero or more | | where * == zero or more | | | | | | All certificates issued | | Cert requests are CRMF | | as part of the response | | or PKCS#10 objects. | | are included in the | | Attributes are (OID, | | "certificates" portion | | set of ANY defined by | | of the signedData. | | OID) pairs. | | | | | +---------+---------------+ +-------+-----------------+ | signed by the | | signed (keypair | | CA or an LRA | | used may be pre-| +---------------+ | existing or | | identified in | | the request) | +-----------------+ Figure 2: Full PKI Request and Response Messages Figure 2 shows the Full Enrollment Request and Response messages. The contents of these messages are detailed in Sections 4.2 and 4.4 below. 3. Protocol Elements This section covers each of the different elements that may be used to construct enrollment request and enrollment response messages. Section 4 will cover how to build the enrollment request and response messages. Myers, Liu, Fox, Weinstein Page 4 Internet Draft November 1998 3.1 PKIData Object The new content object PKIData has been defined for this protocol. This new object is used as the body of the full PKI request message. The new body is identified by: id-ct-PKIData ::= {id-pkix } The ASN.1 structure corresponding to this new content type is: PKIData ::= SEQUENCE { controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg } controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 5. Other parties can define additional control attributes. reqSequence consists of a sequence of certificate requests. The certificate requests can be either a CertificateRequest (PKCS10 request) or a CertReqMsg. Details on each of these requests types are found in sections Error! Reference source not found. and Error! Reference source not found. respectively. cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.5 for more details. otherMsgSequence allows for other arbitrary items to be placed into the enrollment protocol. The {OID, any} pair of values allows for arbitrary definition of material. Data objects are placed here while control objects are placed in the controlSequence field. 3.2 ResponseBody Object The new content object ResponseBody has been defined for this protocol. This new object is used as the body of the full PKI response message. The new body is identified by: id-ct-enrollResponse ::= {id-pkix } The ASN.1 structure corresponding to this body content type is: ResponseBody ::= SEQUENCE { controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg } controlSequence consists of a sequence of control attributes. The control attributes defined in this document are found in section 3.4. Other parties can define additional control attributes. Myers, Liu, Fox, Weinstein Page 5 Internet Draft November 1998 cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData and EncryptedData. See section 3.5 for more details. otherMsgSequence allows for other arbitrary items to be placed into the enrollment protocol. The {OID, any} pair of values allows for arbitrary definition of material. Data objects are placed here while control objects are placed in the controlSequence field. 3.3 Certification Requests (PKCS10/CRMF) Certification Requests are based on either PKCS10 or CRMF messages. Section Error! Reference source not found. specifies mandatory and optional requirements for clients and servers dealing with PKCS10 request messages. Section Error! Reference source not found. specifies mandatory and optional requirements for clients and servers dealing with CRMF request messages. 3.3.1 PKCS10 Request Body Servers MUST be able to understand and process PKCS10 request bodies. Clients MUST produce a PKCS10 request body when using the Simple Enrollment Request message. Clients MAY produce a PKCS10 request body when using the Full Enrollment Request message. When producing a PKCS10 request body, clients MUST produce a PKCS10 message body containing a subject name and public key. Some certification products are operated using a central repository of information to assign subject names upon receipt of a public key for certification. To accommodate this mode of operation, the subject name in a CertificationRequest MAY be NULL, but MUST be present. CAs that receive a CertificationRequest with a NULL subject name MAY reject such requests. If rejected and a response is returned, the CA MUST respond with the failInfo attribute of BADREQUEST. The client MAY incorporate one or more standard X.509 v3 extensions in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq attribute is defined as ExtensionReq ::= SEQUENCE OF Extension where Extension is imported from [PKIXCERT] and ExtensionReq is identified by {pkcs-9 14}. Servers are not required to be able to process every v3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example change key usage from key exchange to signing.) If a certification request is denied due to the inability to handle a Myers, Liu, Fox, Weinstein Page 6 Internet Draft November 1998 requested extension and a response is returned, the server MUST respond with the failInfo attribute of UNSUPPORTEDEXT. 3.3.2 CRMF Request Body Servers MUST be able to understand and process CRMF request body. Clients MAY produce a CRMF message body when using the Full Enrollment Request message. This draft imposes the following additional changes on the construction and processing of CRMF messages: - When CRMF message bodies are used in the Full Enrollment Request message, each CRMF message MUST include both the subject and publicKey fields in the CertTemplate. As in the case of PKCS10 requests the subject may be encoded as NULL, but MUST be present. - The regInfo field MUST NOT be used on a CRMF message. Equivalent functionality is provided in the regInfo control attribute (section 5.14). - The indirect method of proving POP is not supported in this protocol. One of the other methods (including the direct method described in this document) MUST used instead if POP is desired. The value of encrCert in SubsequentMessage MUST NOT be used. - Since the subject and publicKeyValues are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey. A server is not required to use all of the values suggested by the client in the certificate template. Servers are not required to be able to process every V3 X.590 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example change key usage from key exchange to signing.) If a certificate request is denied due to the inability to handle a requested extension, the server MUST respond with a failInfo attribute of UNSUPPORTEDEXT. 3.3.3 Production of Diffie-Hellman Public Key Certification Requests Part of a certification request is a signature over the request; Diffie- Hellman is a key agreement algorithm and cannot be used to directly produce the required signature object. [DH-SIG] provides a way to product necessary signature. In brief the "self-signature" method requires either the CA publish a D- H certificate or the client create a temporary D-H key pair. The client then computes an HMAC over the certification content using the key agreement as the shared secret. The details of how this works are found in [DH-SIG]. Myers, Liu, Fox, Weinstein Page 7 Internet Draft November 1998 Clients and servers producing self-signed D-H certification requests MUST support ephemeral D-H signature method. 3.4 Control Attributes The overall control flow of how a message is processed in this document is based on the control attributes. Each control attribute consists of an object identifier and a value based on the object identifier. Servers are permitted to fail the processing of an entire PKIData message if some object identifiers are not fully understood. The set of control attributes that are defined by this draft are found in section 5. 3.5 Content Info objects This specification uses two different wrapping objects from the CMS draft. SignedData is used for authentication purposes as well as a general transport wrapper. EnvelopedData is used for encryption purposes. 3.5.1 Signed Data The signedData object is used in two different locations when constructing enrollment messages. The signedData object is used as a wrapper to an EnrollmentBody as part of the enrollment request message. The signedData object is also used as the outer part of an enrollment response message. For the enrollment response the signedData wrapper allows the server to sign the returning data, if any exists, and to carry the certificates and CRLs for the enrollment request. If no data is being returned beyond the certificates, no signerInfo objects are placed on the signedData object. 3.5.2 Enveloped Data EnvelopedData is the primary method of providing for the protection of sensitive in this protocol. The protocol currently uses EnvelopedData in two different areas: The global shrouding of an entire request (see section 4.5) and the shrouding of private key material. The envelopedData object is also used to wrap private key material when sent as part of either the enrollment request or enrollment response message. Private key archival MAY be supported through the use of the CMS envelopedData. If used, clients generate an encrypted blob and include it in the request message. Senders return this value on later enrollment messages if requested to do so. Servers MUST NOT implement envelopedData according to [PKCS7]. There is an ambiguity (about encrypting content types other than id-data) in the language that has lead to non-interoperability. Myers, Liu, Fox, Weinstein Page 8 Internet Draft November 1998 4. PKI Messages This section discusses the details of putting together the different enrollment request and response messages. 4.1 Simple Enrollment Request The simplest form of an enrollment request is a plain PKCS10 message. If this form of enrollment request is used, the PKCS10 MUST be self- signed. For Diffie-Hellman "self-signed" means that the ephemeral HMAC signature algorithm in [DH-SIG] MUST be used. Servers MUST support the simple enrollment request message. If the simple enrollment request message is supported, servers MUST return the simple enrollment response message (see Section 3.3) if the enrollment request is granted. If the enrollment request fails, the full enrollment response MAY be returned or no response MAY be returned. Private key archival is not supported by the simple enrollment request message. 4.2 Full PKI Request The Full Enrollment Request provides the most functionality and flexibility. Clients SHOULD use the Full Enrollment Request message when doing client enrollment. Servers MUST support the Full Enrollment Request message. The full enrollment request message consists of an enrollmentBody object wrapped in a signedData CMS object. The objects in the enrollmentBody are ordered as follows: 1. All Control Attributes, 2. All certification requests, 3. All CMS objects, 4. All other messages. All bodyPartIDs and certReqIds within a PKIData MUST be unique. The signedData object wrapping the enrollmentBody may be signed either by the private key material of the signature certification request, or by a pre-existing signature key and certificate. If the private key of the a signature certification request is being used, the issuerAndSerialNumber field of signerInfo MUST be encoded with the bodyPartID of the signature certificate request for the serial number and a NULL for the issuer name. (This is because no existing issuer and serial number are yet known and a standard method of representing this is needed.) If the request key is used for signing, there MUST be only one signerInfo object in the signedData object. When creating a renewal message the following should be taken into consideration: Myers, Liu, Fox, Weinstein Page 9 Internet Draft November 1998 1. The identification and identificationProof control statements are not required. The same information is provided by the use of an existing certificate from the CA when signing the enrollment message. 2. CAs and LRAs may impose additional restrictions on the signing certificate used. They may require that the most recently issued signing certificate for an entity be used. 3. A renewal message may occur either by creating a new set of keys, or by re-using an existing set of keys. Some CAs may prevent re-use of keys by policy. In this case the CA MUST return NOKEYREUSE as the failure code. 4.3 Simple Enrollment Response Servers SHOULD use the simple enrollment response message whenever possible. Clients MUST understand the simple enrollment response message. The simple enrollment response message consists of a signedData object with no signerInfo objects on it. The certificates requested are returned in the certificate bag of the signedData object. Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all certificates to form complete chains to the root. The server MAY additionally return CRLs in the CRL bag. Servers MAY include the root certificates. Clients MUST NOT implicitly trust a self-signed certificate merely due to its presence in the certificate bag. In the event clients receive a new root certificate from the server, clients SHOULD provide a mechanism to enable the user to explicitly trust the received root certificate. 4.4 Full PKI Response Servers MUST return full PKI response messages if a) a full PKI request message failed or b) additional services other than returning certificates are required. Servers MAY return full PKI responses with failure information for simple PKI requests. Following section 4.3 above, servers returning only certificates and a success status to the client SHOULD use the simple PKI response message. Clients MUST understand the full PKI response message. The full enrollment response message consists of a signedData object wrapped around a responseBody object. In a responseBody object all Control Attributes MUST precede all cms objects. The certificates granted in an enrollment response are returned in the certificates field of the immediately encapsulating signedData object. Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all certificates to form complete chains to the root. The server MAY additionally return CRLs in the CRL bag. Servers MAY include the root certificates. Clients MUST NOT implicitly trust a self-signed certificate merely due to its presence in the certificate bag. In the event clients receive a new root certificate from the server, clients Myers, Liu, Fox, Weinstein Page 10 Internet Draft November 1998 SHOULD provide a mechanism to enable the user to explicitly trust the received root certificate. 4.5 Application of Encryption to a PKI Message There are occasions where a PKI request or response message must be encrypted in order to prevent any information about the enrollment. This section describes the means used to encrypt a PKI message. This section is not applicable to a simple enrollment message. Shrouding is obtained by wrapping the PKI message (a signedData object) in a CMS EnvelopedData object. The nested content type in the EnvelopedData is id-signedData. Note that this is different from S/MIME where there is a MIME layer placed between the encrypted and signed data objects. It is recommended that if an enveloped data layer is applied to a PKI message, a second signing layer be placed outside of the enveloped data layer. The following figure shows how this nesting would be done: Normal Option 1 Option 2 ------ -------- -------- SignedData EnvelopedData SignedData PKIData SignedData EnvelopedData PKIData SignedData PKIData Options 1 and 2 provide the benefit of preventing leakage of sensitive data by encrypting the information. LRAs may remove the enveloped data wrapping, and replace or forward without further processing. PKI Messages MAY be encrypted or transmitted in the clear. Servers MUST provided support for all three versions. Alternatively, an authenticated, secure channel could exist between the parties requiring encryption. Clients and servers MAYuse such channels instead of the shrouding technique described above to provide secure, private communication of PKI request and response messages. 5. Control Attributes Control attributes are carried as part of both PKI requests and responses. Each control attribute is encoded as a unique Object Identifier followed by that data for the control attribute. The encoding of the data is based on the control attribute object identifier. Processing systems would first detect the OID and process the corresponding attribute value prior to processing the message body. The following table lists the names, OID and syntactic structure for each of the control attributes documented in this draft. Control Attribute OID Syntax Myers, Liu, Fox, Weinstein Page 11 Internet Draft November 1998 ----------------- ---------- -------------- cMCStatusInfo pkix-cmc 1 CMCStatusInfo identification pkix-cmc 2 UTF8String identityProof pkix-cmc 3 OCTET STRING dataReturn pkix-cmc 4 OCTET STRING transactionId pkix-cmc 5 INTEGER senderNonce pkix-cmc 6 OCTET STRING recipientNonce pkix-cmc 7 OCTET STRING addExtensions pkix-cmc 8 AddExtensions encryptedPOP pkix-cmc 9 EncryptedPOP decryptedPOP pkix-cmc 10 DecryptedPOP lraPOPWitness pkix-cmc 11 LraPOPWitness keyArchival pkix-cmc 12 KeyArchival keyRecoveryReq pkix-cmc 13 KeyRecoveryReq keyRecoveryRsp pkix-cmc 14 KeyRecoveryRsp getCert pkix-cmc 15 GetCert getCRL pkix-cmc 16 GetCRL revokeRequest pkix-cmc 17 RevokeRequest regInfo pkix-cmc 18 OCTET STRING responseInfo pkix-cmc 19 OCTET STRING privateKey pkix-cmc 20 PrivateKeyInfo QueryPending pkix-cmc 21 INTEGER NOTE: It is expected that the number assignments will change in a later draft to group items together according to usage and protocols. 5.1 CMC Status Info Control Attribute The CMC status info control is used in full PKI Response messages to return information on a client request. This statement uses the following ASN.1 definition: CMCStatusInfo ::= SEQUENCE { cMCStatus CMCStatus, bodyList SEQUENCE SIZE (1..MAX) OF INTEGER, statusString UTF8String OPTIONAL, otherInfo CHOICE { failInfo CMCFailInfo, pendInfo PendInfo } OPTIONAL } PendInfo ::= SEQUENCE { pendToken INTEGER, pendTime GENERALIZEDTIME } cMCStatus is described in section 5.2 bodyList contains the list of body parts to which this status information applies. statusString contains a string with additional description information. This string is human readable. failInfo is described in section 5.3. It provides a detailed error on what the failure was. This choice is present only if cMCStatus is failed. Myers, Liu, Fox, Weinstein Page 12 Internet Draft November 1998 pendToken is the token to be used in the queryPending control attribute. pendTime contains the suggested time the server wants to be queried about the status of the request. If the cMCStatus field is success, the CMC Status Info Control MAY be omitted unless the cMCStatus is the only item in the response message. If no status exists for a certificate request or other item requiring processing, then the value of success is to be assumed. 5.2 CMCStatus values CMCStatus is a field in the CMCStatusInfo structure. This field contains a code representing the success or failure of a specific operation. CMCStatus has the ASN.1 structure of: CMCStatus ::= INTEGER { success (0), -- you got exactly what you asked for failed (2), -- you don't get it, more information elsewhere in the message pending (3), -- the request body part has not yet been processed, -- requester is responsible to poll back on this -- pending may only be return for certificate request operations. noSupport (4), -- the requested operation is not supported } 5.3 CMCFailInfo CMCFailInfo conveys information relevant to the interpretation of a failure condition. The CMCFailInfo has the following ASN.1 structure: CMCFailInfo ::= INTEGER { badAlg (0) -- Unrecognized or unsupported algorithm badMessageCheck (1) -- integrity check failed badRequest (2) -- transaction not permitted or supported badTime (3) -- Message time field was not sufficiently close to the system time badCertId (4) -- No certificate could be identified matching the provided criteria unsuportedExt (5) -- A requested X.509 extension is not supported by the recipient CA. mustArchiveKeys (6) - -- Private key material must be supplied Myers, Liu, Fox, Weinstein Page 13 Internet Draft November 1998 badIdentity (7) -- Identification Attribute failed to verify popRequired (8) -- Server requires a POP proof before issuing certificate popFailed (9) -- Server failed to get an acceptable POP for the request noKeyReuse (10) -- Server policy does not allow key re-use internalCAError (11) tryLater (12) } Additional failure reasons MAY be defined for closed environments with a need. 5.4 Identification and Identity-Proof Control Attributes Some CAs and LRAs require that a proof of identity be included in a certification request. Many different ways of doing this exist with different degrees of security and reliability. Most people are familiar with the request of a bank to provide your mother's maiden name as a form of identity proof. CMC provides one method of proving the client's identity based on a shared secret between the certificate requestor and the verifying authority. If clients support full request messages, clients MUST implement this method of identity proof. Servers SHOULD provide this method or have a bilateral method of similar strength available. The CMC method starts with an out-of-band transfer of a token (the shared secret). The distribution of this token is beyond the scope of this document. The client then uses this token for an identity proof as follows: 1. The reqSequence fields of the PKIData object is the value to be validated. 2. A SHA1 hash of the token is computed. 3. An HMAC-SHA1 value is then computed over the stream produced in Step 1, as described in [HMAC], using the hash of the token from Step 2 as the shared secret value. 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the value of the identity-proof attribute. When the server verifies the identity-proof attribute, it computes the HMAC-SHA1 value in the same way and compares it to the identity-proof attribute contained in the enrollment request. If a server fails the verification of an identity-proof attribute and the server returns a response message, the failInfo attribute MUST be present in the response and MUST have a value of BADIDENTITY. Optionally, servers may require the inclusion of the unprotected identification attribution with an identity-proof attribute. The identification attribute is intended to contain either a text string or Myers, Liu, Fox, Weinstein Page 14 Internet Draft November 1998 a numeric quantity, such as a random number, which assists the server in locating the shared secret needed to validate the contents of the identity-proof attribute. Numeric values MUST be converted to text string representations prior to encoding as UTF8-STRINGs in this attribute. If the identity field is included in the message, the derivation of the shared secret in step 2 is altered so that the hash of the concatenation of the token and the identity value are hashed rather than just the token. To facilitate one pass processing of a PKIData object, the identity attribute SHOULD proceed the identity-proof attribute. 5.5 Data Return Control Attribute The data return control attribute allows clients to send arbitrary data (usually some type of internal state information) to the server and to have the data returned as part of the enrollment response message. Data placed in a data return statement is considered to be opaque to the server. The same control is used for both requests and responses. If the data return statement appears in an enrollment message, the server MUST return it as part of the enrollment response message. In the event that the information in the data return statement needs to be confidential, it is expected that the client would apply some type of encryption to the contained data. An example of using this statement is for a client to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key. 5.6 Add Extensions Control Attribute The Add Extensions control attribute is used by LRAs in order to specify additional extensions that are to be placed on certificates. This attribute uses the following ASN.1 definition: AddExtensions ::= SEQUENCE { pkiDataReference INTEGER certReferences SEQUENCE OF INTEGER, extensions SEQUENCE OF Extension } The certReferences field is a list of references to one or more of the payloads contained within a PKIData. Each element of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest or the certReqId of the CertRequest within a CertReqMsg. By definition, the listed extensions are to be applied to every element referenced in the certReferences sequence. Servers are not required to be able to process every v3 X.509 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all LRA-requested extensions into a certificate. Servers are permitted to modify LRA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. If a Myers, Liu, Fox, Weinstein Page 15 Internet Draft November 1998 certification request is denied due to the inability to handle a requested extension and a response is returned, the server MUST return a failInfo attribute with the value of UNSUPPORTEDEXT. If multiple Add Extensions statements exist in an enrollment message, the exact behavior is left up to the certificate issuer policy. However it is recommended that the following policy be used on an extension by extension basis: 1. If the conflict is within a single EnrollmentBody object, the certificate request would be rejected with and error of BADREQUEST. 2. If the conflict is between different EnrollmentBody objects, the outermost version of the extension would be used. 5.7 Transaction Management Control Attributes Transaction management attributes are an optional portion of CMC. A server does not need to implement this section to be compliant with CMC. Transactions MAY be identified and tracked using a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a message that completes the transaction. Servers correspondingly include received transaction identifiers in the response. The transactionId attribute identifies a given transaction. It is used between client and server to manage the state of an operation. It MAY be included in service request messages. If included, responses MUST included the transmitted value. A server MUST use only transactionIds in the outermost PKIdata object. TransactionIds on inner PKIdata objects are for intermediate entities. Replay protection MAY be supported through the use of sender and recipient nonces. If used, clients generate a nonce value and include it in the request as a sender nonce. Servers return this value as recipient nonce along their own value for sender nonce. A server MUST use only nonces in the outermost PKIdata object. Nonces on inner PKIdata objects are for intermediate entities. The senderNonce and recipientNonce attribute can be used to provide application-level replay prevention. They MAY be included in service request messages. Originating messages include only a value for senderNonce. If included, responses MUST include the transmitted value of the previously received senderNonce as recipientNonce and include a value for senderNonce. If nonces are used, in the first message of a transaction, no recipientNonce is transmitted; a senderNonce is instantiated by the message originator and retained for later reference. The recipient of a sender nonce reflects this value back to the originator as a recipientNonce and includes it's own senderNonce. Upon receipt by the transaction originator of this message, the originator compares the value of recipientNonce to its retained value. If the values match, the message can be accepted for further security processing. The received Myers, Liu, Fox, Weinstein Page 16 Internet Draft November 1998 value for senderNonce is also retained for inclusion in the next message associated with the same transaction. If a transaction originator includes a value for the senderNonce attribute, responses MUST include this value as a value for recipient- Nonce AND include a value for the SenderNonce attribute. If a transaction originator includes a value for the transaction-id attribute in a service request, responses MUST include this value as a value for transaction-id attribute. 5.8 Proof-of-possession (POP) for encryption-only keys Everything described in this section is optional to implement. Servers MAY require this POP be used only if another POP method is unavailable. Servers MAY reject all requests contained within a PKIData if any required POP is missing for any element within the PKIData. Many servers require proof that an entity requesting a certificate on a public key actually possesses the corresponding private component of the key pair. For keys that may be used as signature keys, signing the certification request with the private key may serve as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP. By necessity, POP for encryption-only keys cannot be done in one round- trip, since there are four distinct phases: 1. Client tells the server about the public component of a new encryption key pair. 2. Server sends the client a POP challenge, encrypted with the presented public encryption key, which the client must decrypt. 3. Client decrypts the POP challenge and sends it back to the server. 4. Server validates the decrypted POP challenge and continues processing the certificate request. CMC defines two different attributes. The first deals with the encrypted challenge sent from the server to the user in step 2. The second deals with the decrypted challenge sent from the client to the server in step 3. The encryptedPOP attribute is used to send the encrypted challenge from the server to the client. As such, it is encoded as a tagged attribute within the controlSequence of a ResponseBody. (Note that we assume that the message sent in Step 1 above is an enrollment request and that the response in step 2 is a Full Enrollment Response including a failureInfo specifying that a POP is explicitly required, and providing the POP challenge in the encryptedPOP attribute.) EncryptedPOP ::= SEQUENCE { bodyPartID INTEGER, cms contentInfo, thePOPAlgID AlgorithmIdentifier, witnessAlgID AlgorithmIdentifier, Myers, Liu, Fox, Weinstein Page 17 Internet Draft November 1998 witness OCTET STRING } DecryptedPOP ::= SEQUENCE { bodyPartID INTEGER, thePOPAlgID AlgorithmIdentifier, thePOP OCTET STRING } The encrypted POP algorithm works as follows: 1. The server generates a random value y and associates it with the request. 2. The server returns the encrypted pop with the following fields set: a. bodyPartID refers to the certificate request in the original request message, b. cms is an EnvelopedData object, the content type being id-data and the content begin the value y. If the certificate request contains a subject key identifier (SKI) extension, then the recipient identifier SHOULD be the SKI. If the issuerAndSerialNumber form is used, the IsserName MUST be encoded as NULL and the SerialNumber as the bodyPartId of the certificate request, c. thePOPAlgID contains the algorithm to be used in computing the return POP value, d. witnessAlgID contains the hash algorithm used on y to create the field witness, e. witness contains the hashed value of y. 3. The client decrypts the cms field to obtain the value y. The client computes H(y) using the witnessAlgID and compares to the value of witness. If the values do not compare or the decryption is not successful, the client MUST abort the enrollment process. 4. The client creates the decryptedPOP as part of a new PKIData message. The fields in the decryptedPOP are: a. bodyPartID contains the certificate request in the new enrollment message, b. thePOPAlgID is copied from the encryptedPOP, c. thePOP contains the possession proof. This value is computed by thePOPAlgID using the value y and request referenced in (4a). 5. The server then re-computes the value of thePOP from its cached value of y and the request and compares to the value of thePOP. If the values do not match, the server MUST NOT issue the certificate. The server MAY re-issue a new challenge or MAY fail the request altogether. When defining the algorithms for thePOPAlgID and witnessAlgID care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. Clients MUST implement SHA-1 for witnessAlgID. Clients MUST implement HMAC-SHA1 for thePOPAlgID. The value of y is used as the secret value in the HMAC algorithm. If y is greater than 64 bytes, only the first 64 bytes of y are used as the secret. Myers, Liu, Fox, Weinstein Page 18 Internet Draft November 1998 One potential problem with the algorithm above is the amount of state that a CA needs to keep in order to verify the returned POP value. This describes one of many possible ways of addressing the problem by reducing the amount of state kept on the CA to a single (or small set) of values. 1. Server generates random seed x, constant across all requests. (The value of x would normally be altered on a regular basis and kept for a short time afterwards.) 2. For request on public encryption key PK, server computes y = F(x,PK). F can be, for example, HMAC-SHA1(x,PK). All that's important for statelessness is that y be consistently computable with only known state constant x and function F, other inputs coming from the cert request structure. y should not be predictable based on knowledge of PK, thus the use of a OWF like HMAC-SHA1. 5.9 LRA POP Witnesses Control Attribute If an out-of-band POP is required for a certificate enrollment, an LRA can be the entity that does the out-of-band POP rather than the CA. In this case the LRA needs a way to inform the CA it has done the POP. This control attribute has been created to address this issue. The ASN.1 structure for the LRA POP witness is as follows: LraPopWitness ::= SEQUENCE { pkiDataBodyid INTEGER, bodyIds SEQUENCE of INTEGER } The attribute contains a list of certificate requests for which the LRA has performed an out-of-band authentication. The method of authentication could be archival of private key material, challenge- response or other means. If a certificate server does not allow for an LRA to do the POP verification, it returns an error of POPFAILURE. The CA MUST NOT start a challenge-response to re-verify the POP itself. 5.10 Key Archival and Recovery Everything described in this section is optional to implement. Servers MAY require key archival of encryption keys as a condition of issuing a certificate for that encryption key pair. Servers MAY reject all requests contained within a PKIData if any required key archival message is missing for any element within the PKIData. There are four objects involved in key archival and recovery scenarios: 1. The Key Archival control attribute, 2. The Key Recovery Request control attribute, 3. The Key Recovery Response control attribute, 4. A ContentInfo containing private key material. Myers, Liu, Fox, Weinstein Page 19 Internet Draft November 1998 It is assumed that a key recovery operation will only return previously- archive material. (That is, if an archival and recovery operation happen simultaneously, the newly archived key material is not returned as part of the recovery response.) The Key Recover Response control can also be used to implment off-client generation of encryption keys. A control statement containing the required fields for key generation is generated on the client as part of the enrollment request message. This is then sent up to the server and the server responds with a Key Recovery Response containing the newly generated key. The details of the request control statement not covered in this document and would be done on a bilateral basis. 5.10.1 Key Archival Control Attribute The key archival control attribute has the following ASN.1 syntax: KeyArchival ::= SEQUENCE { reqBodyPartID INTEGER, cmsBodyPartID INTEGER, selectionCriteria OCTET STRING OPTIONAL } The reqBodyPartID is a reference to the payload within the enclosing PKIData that contains the certification request for the public key component of the encryption key pair. If multiple certification requests for the same public key are included in the PKIData, reqBodyPartID may point to any one of them. The cmsBodyPartID is a reference to the payload within the enclosing PKIData that contains the private key to be archived. The private key MUST be the private component corresponding to the public key referenced by reqBodyPartID. The selectionCriteria is optional information to be associated with the archived key material to facilitate key recovery of subsections of the archive database. 5.10.2 Key Recovery Request Control Attribute The key recovery request control attribute has the following ASN.1 syntax: KeyRecoveryReq ::= SEQUENCE { shroudIdentification ShroudIdentification, bulkEncryptionAlgID AlgorithmIdentifier, selectionCriterial OCTET STRING OPTIONAL } ShroudIdentification ::= CHOICE { subjectPublicKeyInfo [0] SubjectPublicKeyInfo, encryptionToken [1] AlgorithmIdentifier } Myers, Liu, Fox, Weinstein Page 20 Internet Draft November 1998 The shroudIdentification structure defines the encryption method and key material that MUST be used in the recovery reply to encrypt the recovered private key material. Two methods of identification are currently defined. In the first, the public key component of an encryption key pair is explicitly included in the request. The second method derives a key from a known secret shared between client and server, such as an out-of-band token. This method is defined as an AlgorithmIdentifier as it must identify (a) the source of the key material, (b) any public/salt information, and (c) the method of deriving an encryption key using the request data, source key material and salt. Clients and servers MUST support the subject public key method. Clients and servers support of other methods is based on a bilateral agreement. The bulkEncryptionAlgID identifies the bulk encryption algorithm that MUST be used by the server to encrypt the key material. The selectionCriteria is optional information to be associated with the archived key material to facilitate key recovery of subsections of the archive database. If selectionCriteria is absent, all archived keys associated with the enrolling identity MUST be returned. Notice that the recovery request does not include an entity identifier. Determination of the identity comes from other locations: The name in a certificate request, the name in an identity proof, the name in the shrouding certificate or the name in the signing certificate on the containing SignedInfo structure. Servers need to establish a policy to be used by that server for identifying the entity doing the request operation. 5.10.3 Key Recovery Response Control Attribute The key recovery response control attribute has the following ASN.1 syntax: KeyRecoveryRsp ::= SEQUENCE { bodyPartID INTEGER, selectionCriteria OCTET STRING OPTIONAL } The bodyPartID identifies a TaggedContentInfo contained within the enclosing PKIData. The ContentInfo contains the requested private key material. The selectionCriteria is the optional information that was used to retrieve a subset of the keys archived in the archive database. 5.10.4 Private Key Info Attribute Myers, Liu, Fox, Weinstein Page 21 Internet Draft November 1998 The private key info attribute is imported from [PKCS8]. The encrypted private key info object is not imported as the only difference between it and an EncryptedData object is the inclusion of a version number in the ASN.1 structure. Private key information is tagged by the private key info attribute. This attribute has the ASN.1 structure: PrivateKeyInfo ::= SEQUENCE { version INTEGER, privateKeyAlgorithm AlgorithmIdentifier, privateKey OCTET STRING, attributes [0] IMPLICIT Attributes OPTIONAL } Attributes ::= SET OF Attribute version MUST be the value 0 privateKeyAlgorithm contains the identifier for the private key object privateKey is an octet string whose contents is the private key and whose format is defined by the value of privateKeyAlgorithm. attributes is a set of attributes. These are extended information that is part of the private key information. We are defining the structures here to be used for two algorithms. 5.10.4.1 D-H Private Keys When creating a PrivateKeyInfo for a D-H key, the following rules apply: 1. The privateKeyAlgorithm MUST be set to id-dh-private-number. The parameter for id-dh-private-number is DomainParameters (imported from [PKIXCERT]). 2. The ASN structure for privateKey MUST be DH-PrivateKey ::= INTEGER 3. attributes MUST be omitted. 5.10.4.2 RSA Private Keys When creating a PrivateKeyInfo for an RSA key, the following rules apply: 1. The privateKeyAlgorithm MUST be set to rsaEncryption. 2. The ASN structure for privateKey MUST be RSAPrivateKey (defined in [PKCS1]) 3. Attributes MUST be omitted. 5.10.5 ContentInfo Objects for Private Key Material ContentInfo object that contain private key material MUST be one of EnvelopedData, EncryptedData or Data. Private key material placed in a Myers, Liu, Fox, Weinstein Page 22 Internet Draft November 1998 Data ContentInfo MUST be encrypted through some other mechanism; it is beyond the scope of this document to specify that mechanism. The inner content of the EnvelopedData or EncryptedData is a ResponseBody. The private keys are then encoded as private key info control attributes. 5.10.6 Control Flow Control flow for Key Archival is assumed to proceed as follows: 1. Client retrieves an encryption certificate for the archiving server, so that key material to be archived may be encrypted to it. 2. Client generates an encryption key pair. 3. Client submits an enrollment request for the key pair. As part of the PKIData, the client includes: a. A certificate request (PKCS10 or CRMF) for the key pair, which include the public key component and a message identifier (either bodyPartID or certReqId), b. A Key Archival control attribute, which includes two message identifier references: i. The identifier of the certification request in (3a), and ii. The identifier of the ContentInfo in (3c). c. A ContentInfo containing inside it the private key material corresponding to the public key contained in the request in (3a) and encrypted using the public key from the certificate obtained in (1). 4. Server receives the request, archives the key material, and issues certificates as appropriate. Server responds with an enrollment response containing the issued certificates. It is assumed that whatever mechanisms are used to identify the entity requesting certification also serve to identify the archiving party. Control flow for Key Recovery is assumed to proceed as follows: 1. Client sends a Full Enrollment Request message containing the Key Recovery Request control attribute to the server. (The PKIData need contain only the Key Recovery Request attribute.) 2. Server performs policy-based operations to determine whether the recovery request is valid. 3. Assuming the request is indeed valid, the server sends back to the client a Full Enrollment Response containing: a. One or more Key Recovery Response control attributes. b. One or more Private Key attributes containing private key material as defined in section 5.10.4 above. 4. Client processes the response and extracts private key material from the ContentInfo(s). The above control flow for key recovery assumes that the client possesses at least a previously-certified signature key, which is used to sign the Full Enrollment Request message. In the event of a catastrophic failure on the client resulting in loss of all client keys, generation and certification of a new signature key may occur simultaneously to a request for recovery of private encryption keys. Myers, Liu, Fox, Weinstein Page 23 Internet Draft November 1998 Control flow for recovering from catastrophic failure may proceed as follows: 1. Client generates a new signature key pair and creates a certification request for the public component of the new signature key. 2. Client creates a Full Enrollment Request message containing: a. The certificate request from Step 1, b. A Key Recovery Request control attribute. The Full Enrollment Request message is signed using the private signature key generated as part of Step 1. Following Section 4.2, the signerInfo field of the signed message will contain a NULL issuer name an a serial number corresponding to the bodyPartID of the certificate request within the PKIData. Notice that as it is not possible for the client to prove identity within the PKI (because all certified key pairs have been lost), another form of proof-of- identity is required (such as use of the identification and identificationProof control attributes). 3. Client sends the Full Enrollment Request to the server. 4. Server performs policy-based operations on the request message to determine: a. Whether the certification request on the new signature key should be granted, and b. Whether the recovery request is valid. 5. Assuming that both requests are valid, the server sends back to the client a Full Enrollment Response containing: a. A certificate for the signature key, corresponding to the certification request generated by the client. b. One or more Key Recovery Response control attributes. c. One or more Private Key attributes containing private key material as defined in section 3.4.8.4. 6. Client processes the response and extracts private key material and certificates. 5.11 Get Certificate Control Attribute The get certificate control attribute is used to retrieve previously issued certificates from a repository of certificates. A certificate server, an LRA or an independent service may provide this repository. The clients expected to use this facility are those operating in a resource-constrained environment. (An example of a resource-constrained client would be a low-end IP router that does not retain it's certificate in non-volatile memory.) CAs do not need to implement this control attribute to be compliant with CMC. The get certificate control attribute has the following ASN.1 structure: GetCert ::= SEQUENCE { issuerName GeneralName, serialNumber INTEGER } The service responding to the request will place the requested certificate in the certificates field of a SignedData object. If the Myers, Liu, Fox, Weinstein Page 24 Internet Draft November 1998 get certificate attribute is the only control in a full enrollment message, the response would be a simple enrollment response. 5.12 Get CRL Control Attribute The get CRL control attribute is used to retrieve CRLs from a repository of CRLs. A certificate server, an LRA or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable. CAs do not need to implement this control attribute to be compliant with this specification. The get CRL control attribute has the following ASN.1 structure: GetCRL ::= SEQUENCE { issuerName Name, cRLName GeneralName OPTIONAL, time GeneralizedTime OPTIONAL, reasons ReasonFlags OPTIONAL } The fields in a GetCRL have the following meanings: issuerName is the value of the Issuer DN in the subject certificate. cRLName may be the value of CRLDistributionPoints in the subject certificate or equivalent value in the event the certificate does not contain such a value. time is used by the client 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. reasons is used to specify from among CRLs partitioned by revocation reason. Implementors should bear in mind that while a specific revocation request has a single CRLReason code--and consequently entries in the CRL would have a single CRLReason code value--a single CRL can aggregate information for one or more reasonFlags. A service responding to the request will place the requested CRL in the crls field of a SignedData object. If the get CRL attribute is the only control in a full enrollment message, the response would be a simple enrollment response. 5.13 Revocation Request Control Attribute The revocation request control attribute is used to request that a certificate be revoked. The revocation request control attribute has the following ASN.1 syntax: Myers, Liu, Fox, Weinstein Page 25 Internet Draft November 1998 RevRequest ::= SEQUENCE { issuerName Name, serialNumber INTEGER, reason CRLReason, sharedSecret OCTET STRING OPTIONAL, comment UTF8string 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 Authority's digital signature on the request can provide this proof for certificates within the scope of the LRA's revocation authority. The means by which an LRA is delegated this authority is a matter of operational policy. 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. The RevRequest provides for the optional transmission from the end-entity to the CA of a shared secret that 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. Clients MUST provide the capability to produce a digitally signed revocation request control attribute. Clients SHOULD provide the capability produce an unsigned revocation request containing the end- entity's shared secret. If a client provides shared secret based self- revocation, the client MUST be capable of producing a revocation request containing the shared secret. The structure of an unsigned, shared secret based revocation request is a matter of local implementation. The shared secret does not need to be shrouded when sent in a revocation request. The shared secret has a one time use, that of causing the certificate to be revoked, and public knowledge of the shared secret after the certificate has been revoked is not a problem. Clients need to inform users that the same shared secret SHOULD NOT be used for multiple certificates. A full response message MUST be returned for a revocation request. 5.14 Registration and Response Information Control Attributes The registration information control attribute is for clients and LRAs to pass additional information as part a PKI request. The registration information control attribute uses the ASN.1 structure: RegInfo ::= OCTET STRING The content of this data is based on bilateral agreement between the client and server. If a server (or LRA) needs to return information back to a requestor in response to registration info, then that data is returned as a response information control attribute. The content of the OCTET STRING for a response information is based on bilateral agreement between the client and server. Myers, Liu, Fox, Weinstein Page 26 Internet Draft November 1998 5.15 Query Pending Control Attribute In some environments, process requirements for manual intervention or other identity checking can cause a delay in returning the certificate related to a certificate request. The query pending attribute allows for a client to query a server about the state of a pending certificate request. The server returns a token as part of the CMCStatusInfo attribute (in the otherInfo field). The client puts the token into the query pending attribute to identify the correct request to the server. The ASN.1 structure used by the query pending control attribute is: QueryPending ::= INTEGER If a server returns a pending state (the transaction is still pending), the otherInfo MAY be omitted. If it is not omitted then the same value MUST be returned (the token MUST NOT change during the request). 6. Local Registration Agents This specification permits the use of Local Registration Agents (LRAs). An LRA sits between the client and the certification authority. From the client the LRA appears to be the certification authority and from the server the LRA appears to be a client. LRAs receive the enrollment messages, perform local processing and then forward onto certificate authorities. Some of the types of local processing that an LRA can perform include: - batching multiple enrollment messages together, - challenge/response POP proofs, - addition of private or standardized certificate extensions to all requests, - archival of private key material, - routing of requests to different CAs. When an LRA receives an enrollment message, it may either add its own layer of wrapping to produce a nested message or strip off the SignedData objects and produce a new non-nested message. LRAs SHOULD use nested messages rather than non-nested messages when possible. LRAs SHOULD NOT remove a signedData object wrapping layer if it was added by the original requesting entity. LRAs MUST NOT alter a certificate request body (PKCS #10 or CRMF) as any alteration invalidates the signature on the body and thus the POP for the private key. 6.1 Nested Messages The expected procedure for an LRA to add information to an end entities certificate request message is to take the request and place it into a new PKIData object. The request is placed in the cmsSequence if it is a full pki message and the reqSequence field for a simple enrollment message. Control attributes, such as the add extension attribute, are then added to the controlSequence field of the PKIData object. An LRA Myers, Liu, Fox, Weinstein Page 27 Internet Draft November 1998 can combine multiple messages into a single new PKIData object by placing more than one item in the sequence. An example of how this would look is illustrated by the following figure: SignedData (by LRA) PKIData controlSequence LRA added control statements reqSequence Zero or more Simple CertificationRequests from clients cmsSequence Zero or more Full PKI messages from clients SignedData (by client) PKIData 6.2 Non-Nested Messages LRAs occasionally need to strip off the SignedData portion of a PKIData message. In this case it is necessary for the LRA to correctly merge the control statements in the submitted full PKI message with the changes to be made by this LRA. 6.3 Multiple LRA Operation In some instances there may be more than one LRA in the validation path, in this case the second LRA in the sequence has two options for adding new control statements. The LRA may either add a new layer of wrapping (resulting in three levels of nested signedData objects) or it may strip the previous LRA's signature and create a new signedData object. In this case the LRA is responsible for merging together any control statements that the previous LRA may have added. 7. Transport Wrapping Depending on the transport mechanism that is being used to deliver the enrollment request and responses different types of wrapping is required. We document for use three different wrapping items here. Mime wrapping is for transports that are natively mime based such as HTTP and E-mail. A binary file transport is defined since floppy disk transport is still very common. File transport can be done either bare (section 7.2) or MIME wrapped (section 7.1). 7.1 MIME Wrapping MIME wrapping is defined for those environments that are MIME native. These include E-Mail based protocols as well as HTTP. The basic mime wrapping in this section is taken from [SMIMEV2] and [SMIMEV3]. Simple enrollment requests are encoded using the application/pkcs10 content type. A file name MUST be included either in Myers, Liu, Fox, Weinstein Page 28 Internet Draft November 1998 a content type or content disposition statement. The extension for the file MUST be ".p10". Simple enrollment response messages MUST be encoded as content-type application/pkcs7-mime. An smime-type parameter MUST be on the content- type statement with a value of "certs-only." A file name with the ".p7c" extension MUST be specified as part of the content-type or content- disposition. Full enrollment request messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-enroll". A file name with the ".p7m" extension MUST be specified as part of the content-type or content-disposition statement. Full enrollment response messages MUST be encoded as content-type application/pkcs7-mime. The smime-type parameter MUST be included with a value of "CMC-response." A file name with the ".p7m" extensions MUST be specified as part of the content-type or content-disposition. MIME TYPE File Extension SMIME-TYPE application/pkcs10 .p10 N/A (simple PKI request) application/pkcs7-mime .p7m CMC-request (full PKI request) application/pkcs7-mime .p7c certs-only (simple PKI response) applicication/pkcs7-mime .p7m CMC-response (full PKI response) 7.2 File-Based Transport Enrollment messages and responses may also be transferred between clients and servers using file system-based mechanisms, such as when enrollment is performed for an off-line client. When files are used to transport binary, BER-encoded Full Enrollment Request and Repsonse messages, the following file type extensions SHOULD be used: Message Type File Extension Full PKI Request .crq Full PKI Response .crp 7.3 Socket-Based Transport When enrollment messages and responses are sent over sockets, no wrapping is required. Messages SHOULD be sent in their binary, BER- encoded form. Myers, Liu, Fox, Weinstein Page 29 Internet Draft November 1998 8. Interoperability 8.1 Mandatory and Optional Algorithms CMC clients and servers MUST be capable of producing and processing message signatures using the Digital Signature Algorithm [DSA]. DSA signatures MUST be indicated by the DSA AlgorithmIdentifier value specified in section 7.2.2 of PKIXCERT. PKI clients and servers SHOULD also be capable of producing and processing RSA signatures as specified in section 7.2.1 of PKIXCERT. CMC clients and servers MUST be capable of protecting and accessing message encryption keys using the Diffie-Hellman (D-H) key exchange algorithm. D-H/3DES protection MUST be indicated by the D-H AlgorithmIdentifier value specified in CMS. PKI clients and servers SHOULD also be capable of producing and processing RSA key transport. When used for PKI messages, RSA key transport MUST be indicated as specified in section 7.2.1 of PKIXCERT. 9. Security Considerations Initiation of a secure communications channel between an end-entity and a CA necessarily requires an out-of-band trust initiation mechanism. For example, a secure channel may be constructed between the end-entity and the CA via IPSEC or TLS. Many such schemes exist and the choice of any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture. Mechanisms for thwarting replay attacks may be required in particular implementations of this protocol depending on the operational environment. In cases where the CA maintains significant state information, replay attacks may be detectable without the inclusion of the optional nonce mechanisms. Implementers of this protocol need to carefully consider environmental conditions before choosing whether or not to implement the senderNonce and recipientNonce attributes described in section 5.7. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these attributes. Under no circumstances should a signing key be archived. Doing so allows the archiving entity to potentially use the key for forging signatures. Due care must be taken prior to archiving keys. Once a key is given to an archiving entity, the archiving entity could use the keys in a way not conducive to the archiving entity. Users should be made especially aware that proper verification is made of the certificate used to encrypt the private key material. Clients and servers need to do some checks on cryptographic parameters prior to issuing certificates to make sure that weak parameters are not used. Myers, Liu, Fox, Weinstein Page 30 Internet Draft November 1998 Small Group Attack 10. Open Issues There appears to be a need to add one or more control statements to acknowledge the fact that key archival has been completed. (In fact, there may be a need for a general mechanism for an LRA to communicate certain process-related information to the next upstream LRA/CA.) 11. Acknowledgments The authors would like to thank Jim Schaad and Brian LaMacchia for their work in developing and writing up many of the concepts presented in this document. The authors would also like to thank Alex Deacon for his contributions. 12. References [CMS] R. Housley, "Cryptographic Message Syntax", draft-ietf-smime-cms-06.txt, June 1998 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Internet X.509 Certificate Request Message Format", draft-ietf-pkix-crmf-01.txt, May 1998 [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" [DH-SIG] H. Prafullchandra, J. Schaad, "Diffie-Hellman Signing Algorithm", draft-schaad-dhsign-00.txt, November 1998 [PKCS7] B. Kaliski, "PKCS #7: Cryptographic Message Syntax v1.5", RFC 2315, October 1997 [PKCS10] B. Kaliski, "PKCS #10: Certification Request Syntax v1.5", RFC 2314, October 1997 [PKIXCERT] R. Housley, W. Ford, W. Polk, D. Solo "Internet Public Key Infrastructure X.509 Certificate and CRL Profile", draft-ietf-pkix-ipki-part1-11.txt, September 1998 [RFC 2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119 [SMIMEV2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998 [SMIMEV3] B. Ramsdell, "S/MIME Version 3 Message Specification", draft-ietf-smime-msg-05.txt, August 1998 13. Author's Addresses Michael Myers VeriSign Inc. 1390 Shorebird Way Myers, Liu, Fox, Weinstein Page 31 Internet Draft November 1998 Mountain View, CA, 94019 (650) 429-3402 mmyers@verisign.com Xiaoyi Liu Cisco Systems 170 West Tasman Drive San Jose, CA 95134 (480) 526-7430 xliu@cisco.com Barbara Fox Microsoft Corporation One Microsoft Way Redmond, WA 98052 (425) 936-9542 bfox@microsoft.com Jeff Weinstein Netscape Communications Corporation 501 Middlefield Road Mountain View, CA 94043 jsw@netscape.com Appendix A ASN.1 Module EnrollmentMessageSyntax { iso(1) identified-organization(3) dod(4) internet(1) security(5) mechansims(5) pkix(7) id-mod(0) TBD } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All -- -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes. IMPORTS -- Information Directory Framework (X.501) Name FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) informationFramework(1) 3 } -- Directory Authentication Framework (X.509) AlgorithmIdentifier, AttributeCertificate, Certificate, CertificateList, CertificateSerialNumber FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 } -- PKIX Part 1 - Implicit Myers, Liu, Fox, Weinstein Page 32 Internet Draft November 1998 GeneralName, CRLReason, ReasonFlags FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} -- PKIX Part 1 - Explicit SubjectPublicKeyInfo, Extension FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} -- Cryptographic Message Syntax ContentInfo, Attribute FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1} -- CRMF CertReqMsg FROM CRMF { }; id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-pkix-cmc OBJECT IDENTIFIER ::= {id-pkix } id-dh-private-number OBJECT IDENTIFIER ::= {} id-identification OBJECT IDENTIFIER ::= {id-pkix-cmc 2} id-identityProof OBJECT IDENTIFIER ::= {id-pkix-cmc 3} id-dataReturn OBJECT IDENTIFIER ::= {id-pkix-cmc 4} id-transactionId OBJECT IDENTIFIER ::= {id-pkix-cmc 5} id-senderNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 6} id-recipientNonce OBJECT IDENTIFIER ::= {id-pkix-cmc 7} id-regInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 18} id-responseInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 19} id-queryPending OBJECT IDENTIFIER ::= {id-pkix-cmc 21} -- This is the content type used for a request message in the protocol id-ct-PKIData OBJECT IDENTIFIER ::= { id-pkix } PKIData ::= SEQUENCE { controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg } TaggedAttribute ::= SEQUENCE { bodyPartID INTEGER, attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue Myers, Liu, Fox, Weinstein Page 33 Internet Draft November 1998 } AttributeValue ::= ANY TaggedRequest ::= CHOICE { tcr [0] TaggedCertificationRequest, crm [1] CertReqMsg } TaggedCertificationRequest ::= SEQUENCE { bodyPartID INTEGER, certificationRequest CertificationRequest } 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 } TaggedContentInfo ::= SEQUENCE { bodyPartID INTEGER, contentInfo ContentInfo } OtherMsg ::= SEQUENCE { bodyPartID INTEGER, otherMsgType OBJECT IDENTIFIER, otherMsgValue ANY DEFINED BY otherMsgType } -- This defines the response message in the protocol id-ct-enrollResponse OBJECT IDENTIFIER ::= {id-pkix } ResponseBody ::= SEQUENCE { controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg } -- Used to return status state in a response id-cMCStatusInfo OBJECT IDENTIFIER ::= {id-pkix-cmc 1} CMCStatusInfo ::= SEQUENCE { cMCStatus CMCStatus, bodyList SEQUENCE SIZE (1..MAX) OF INTEGER, statusString UTF8String OPTIONAL, otherInfo CHOICE { Myers, Liu, Fox, Weinstein Page 34 Internet Draft November 1998 failInfo CMCFailInfo, pendInfo PendInfo } OPTIONAL } PendInfo ::= SEQUENCE { pendToken INTEGER, pendTime GENERALIZEDTIME } CMCStatus ::= INTEGER { success (0), -- you got exactly what you asked for failed (2), -- you don't get it, more information elsewhere in the message pending (3), -- the request body part has not yet been processed, -- requester is responsible to poll back on this noSupport (4) -- the requested operation is not supported } CMCFailInfo ::= INTEGER { badAlg (0), -- Unrecognized or unsupported algorithm badMessageCheck (1), -- integrity check failed badRequest (2), -- transaction not permitted or supported badTime (3), -- Message time field was not sufficiently close to the system time badCertId (4), -- No certificate could be identified matching the provided criteria unsuportedExt (5), -- A requested X.509 extension is not supported by the recipient CA. mustArchiveKeys (6), -- Private key material must be supplied badIdentity (7), -- Identification Attribute failed to verify popRequired (8), -- Server requires a POP proof before issuing certificate popFailed (9), -- Server failed to get an acceptable POP for the request noKeyReuse (10) -- Server policy does not allow key re-use internalCAError (11) tryLater (12) } -- Used for LRAs to add extensions to certificate requests id-addExtensions OBJECT IDENTIFIER ::= {id-pkix-cmc 8} Myers, Liu, Fox, Weinstein Page 35 Internet Draft November 1998 AddExtensions ::= SEQUENCE { pkiDataReference INTEGER, certReferences SEQUENCE OF INTEGER, extensions SEQUENCE OF Extension } id-encryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 9} id-decryptedPOP OBJECT IDENTIFIER ::= {id-pkix-cmc 10} EncryptedPOP ::= SEQUENCE { bodyPartID INTEGER, cms ContentInfo, thePOPAlgID AlgorithmIdentifier, witnessAlgID AlgorithmIdentifier, witness OCTET STRING } DecryptedPOP ::= SEQUENCE { bodyPartID INTEGER, thePOPAlgID AlgorithmIdentifier, thePOP OCTET STRING } id-lraPOPWitness OBJECT IDENTIFIER ::= {id-pkix-cmc 11} LraPopWitness ::= SEQUENCE { pkiDataBodyid INTEGER, bodyIds SEQUENCE OF INTEGER } id-keyArchival OBJECT IDENTIFIER ::= {id-pkix-cmc 12} id-keyRecoveryReq OBJECT IDENTIFIER ::= {id-pkix-cmc 13} id-keyRecoveryRsp OBJECT IDENTIFIER ::= {id-pkix-cmc 14} KeyArchival ::= SEQUENCE { reqBodyPartID INTEGER, cmsBodyPartID INTEGER, selectionCriteria OCTET STRING OPTIONAL } KeyRecoveryReq ::= SEQUENCE { shroudIdentification ShroudIdentification, bulkEncryptionAlgID AlgorithmIdentifier, selectionCriterial OCTET STRING OPTIONAL } ShroudIdentification ::= CHOICE { subjectPublicKeyInfo [0] SubjectPublicKeyInfo, encryptionToken [1] AlgorithmIdentifier } KeyRecoveryRsp ::= SEQUENCE { bodyPartID INTEGER, selectionCriteria OCTET STRING OPTIONAL Myers, Liu, Fox, Weinstein Page 36 Internet Draft November 1998 } id-privateKey OBJECT IDENTIFIER ::= {id-pkix-cmc 20} PrivateKeyInfo ::= SEQUENCE { version INTEGER, privateKeyAlgorithm AlgorithmIdentifier, privateKey OCTET STRING, attributes [0] IMPLICIT Attributes OPTIONAL } Attributes ::= SET OF Attribute DH-PrivateKey ::= INTEGER -- id-getCert OBJECT IDENTIFIER ::= {id-pkix-cmc 15} GetCert ::= SEQUENCE { issuerName GeneralName, serialNumber INTEGER } id-getCRL OBJECT IDENTIFIER ::= {id-pkix-cmc 16} GetCRL ::= SEQUENCE { issuerName Name, cRLName GeneralName OPTIONAL, time GeneralizedTime OPTIONAL, reasons ReasonFlags OPTIONAL } id-revokeRequest OBJECT IDENTIFIER ::= {id-pkix-cmc 17} RevRequest ::= SEQUENCE { issuerName Name, serialNumber INTEGER, reason CRLReason, passphrase OCTET STRING OPTIONAL, comment UTF8String OPTIONAL } -- The following is used to request V3 extensions be added to a certificate id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 14} ExtensionReq ::= SEQUENCE OF Extension END Myers, Liu, Fox, Weinstein Page 37