PKIX Working Group J. Schaad Internet Draft Soaring Hawk Consulting M. Myers February 2002 TraceRoute Security Expires: August 2002 X. Liu Cisco J. Weinstein Certificate Management Messages over CMS draft-ietf-pkix-2797-bis-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments or suggestions for improvement may be made on the "ietf- pkix" mailing list, or directly to the author. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 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 both signedData and 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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 1. Protocol Requirements - 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 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 authorities 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 can be based on either the PKCS10 or CRMF 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 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 Authorities (LRAs) to participate in the protocol by taking client enrollment messages, wrapping them in a 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, certificate revocation requests and certificate/CRL retrieval. 2.1 Terminology There are several different terms, abbreviations and acronyms used in this document that we define here for convenience and consistency of usage: "End-Entity" (EE) refers to the entity that owns a key pair and for whom a certificate is issued. "LRA" or "RA" refers to a (Local) Registration Authority. A registration authority acts as an intermediary between an End-Entity and a Certification Authority. Multiple RAs can exist between the End-Entity and the Certification Authority. "CA" refers to a Certification Authority. A Certification 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 RAs and End-Entities can be clients. "Server" refers to the entities that process PKI requests and create PKI responses. CAs and RAs can be servers in this document. "PKCS#10" refers the Public Key Cryptography Standard #10. This is one of a set of standards defined by RSA Laboratories in the 1980s. PKCS#10 defines a Certificate Request Message syntax. "CRMF" refers to the Certificate Request Message Format RFC [CRMF]. We are using certificate request message format defined in this document as part of our management protocol. "CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management. "POP" is an acronym for "Proof of Possession". POP refers to a value that can be used to prove that the private key corresponding to a public key is in the possession and can be used by an end- entity. "Transport wrapper" refers to the outermost CMS wrapping layer. 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 | | | | 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 | | Certificate requests | | as part of the response | | are CRMF or PKCS#10 | | are included in the | | objects. Attributes are | | "certificates" portion | | (OID, ANY defined by | | of the signedData. | | OID) pairs. | | Relevant CA certs and | | | | CRLs can be included as | +-------+-----------------+ | well. | | signed (keypair | | | | used may be pre-| +---------+---------------+ | existing or | | signed by the | | identified in | | CA or an LRA | | 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. 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-cct-PKIData ::= {id-pkix id-cct(12) 2 } 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. As control sequences are defined by OIDs, other parties can define additional control attributes. Unrecognized OIDs MUST result in no part of the request being successfully processed. -- reqSequence consists of a sequence of requests. The requests can be a CertificateRequest (PKCS10 request), a CertReqMsg or an externally defined request (orm). Details on the first two request types are found in sections 3.3.1 and 3.3.2 respectively. If an externally defined request message is present, but the server does not understand the request (or will not process it), a CMCStatus of noSupport MUST be returned for the request item and no requests processed. -- cmsSequence consists of a sequence of [CMS] message objects. This protocol uses EnvelopedData, SignedData, EncryptedData and AuthenticatedData. See section 3.6 for more details. -- otherMsgSequence allows for other arbitrary data 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. See section 3.7 for more details. Processing of this object by a recipient is as follows: 1. All control attributes should be examined and processed in an appropriate manner. The appropriate processing may be either to do complete processing at this time, ignore the control attribute or to place the control attribute on a to-do list for later processing. 2. An implicit control attribute is then processed for each item in the reqSequence. Again this may be either immediate processing or addition to a to-do list for later processing. No processing is required for cmsSequence or otherMsgSequence members of the element. If items are present and are not referenced by a control sequence, they are to be ignored. 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-cct-PKIResponse ::= {id-pkix id-cct(12) 3 } 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.5. Other parties can define additional control attributes. -- cmsSequence consists of a sequence of [CMS] message objects. This protocol only uses EnvelopedData, SignedData, EncryptedData and AuthenticatedData. See section 3.6 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. See section 3.7 for more details. Processing of this object by a recipient is as follows: 1. All control attributes should be examined and processed in an appropriate manner. The appropriate processing may be either to do complete processing at this time, ignore the control attribute or to place the control attribute on a to-do list for later processing. 2. Additional processing of non-element items includes the saving of certificates and CRLs present in wrapping layers. This type of processing is based on the consumer of the element and should not be relied on by generators. No processing is required for cmsSequence or otherMsgSequence members of the element. If items are present and are not referenced by a control sequence, they are to be ignored. 3.3 Certification Requests (PKCS10/CRMF) Certification Requests are based on either PKCS10 or CRMF messages. Section 3.3.1 specifies mandatory and optional requirements for clients and servers dealing with PKCS10 request messages. Section 3.3.2 specifies mandatory and optional requirements for clients and servers dealing with CRMF request messages. All certificate requests directly encoded into a single PKIData object SHOULD be for the same identity. RAs that batch processing are expected to place the signed PKIData sequences received into the cmsSequence of the PKIData object it generates. 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 MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other V3 X.509 extensions 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 changing key usage from key exchange to signing.) If a certification request is denied due to the inability to handle a 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 memo 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. - When both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override the CRMF control. - The regInfo field MUST NOT be used on a CRMF message. Equivalent functionality is provided in the regInfo control attribute (section 5.12). - 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 be 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 MUST be able to process all extensions defined, but not prohibited in [PXIXCERT]. Servers are not required to be able to process other V3 X.509 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-POP] provides two ways to produce the necessary signature value. This document also defines a signature algorithm that does not provide a POP value, but can be used to produce the necessary signature value. 3.3.3.1 No-Signature Signature Mechanism Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purposes. The following object identifier and signature value are used to identify this signature type: id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} NoSignatureValue ::= OCTET STRING The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the hash of the certification request. It is important to realize that there is no security associated with this signature type. If this signature type is on a certification request and the Certification Authority policy requires proof-of-possession of the private key, the POP mechanism defined in section 5.7 MUST be used. 3.3.3.2 Diffie-Hellman POP Discrete Logarithm Signature CMC compliant implementations MUST support section 4 of [DH-POP]. 3.3.3.3 Diffie-Hellman MAC signature CMC compliant implementations MAY support section 3 of [DH-POP]. 3.4 Body Part Identifiers Each element of a PKIData or PKIResponse message has an associated body part identifier. The Body Part Identifier is a 4-octet integer encoded in the certReqIds field for CertReqMsg objects (in a TaggedRequest) or in the bodyPartId field of the other objects. The Body Part Identifier MUST be unique within a single PKIData or PKIResponse object. Body Part Identifiers can be duplicated in different layers (for example a CMC message embedded within another). The Body Part Id of zero is reserved to designate the current PKIData object. This value is used in control attributes such as the Add Extensions Control in the pkiDataReference field to refer to a request in the current PKIData object. Some control attribute, such as the CMC Status Info attribute, will also use Body Part Identifiers to refer to elements in the previous message. This allows an error to be explicit about the attribute or request to which the error applies. 3.5 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 MUST fail the processing of an entire PKIData message if any included control attribute is not recognized. The response MUST be the error badRequest and bodyList MUST contain the bodyPartID of the invalid or unrecognized control attribute(s). The syntax of a control attribute is TaggedAttribute ::= SEQUENCE { bodyPartID BodyPartId, attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } -- bodyPartId is a unique integer that is used to reference this control attribute. The id of 0 is reserved for use as the reference to the current PKIData object. -- attrType is the OID defining the associated data in attrValues -- attrValues contains the set of data values used in processing the control attribute. The set of control attributes that are defined by this memo are found in section 5. 3.6 Content Info objects The cmsSequence field of the PKIRequest and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is TaggedContentInfo ::= SEQUENCE { bodyPartID BodyPartId, contentInfo ContentInfo } -- bodyPartId is a unique integer that is used to reference this content info object. The id of 0 is reserved for use as the reference to the current PKIData object. -- contentInfo contains a ContentInfo object (defined in [CMS]). The three contents used in this location are SignedData, EnvelopedData and Data. EnvelopedData provides for shrouding of data. Data allows for general transport of unstructured data. The SignedData object from [CMS] is also used in this specification to provide for authentication as well as serving as the general transport wrapper of requests and responses. 3.6.1 Signed Data The signedData object is used in two different locations when constructing enrollment messages. The signedData object is used as a wrapper for a PKIData as part of the enrollment request message. The signedData object is also used as the outer part of an enrollment response message. As part of processing a message the signature(s) MUST be verified. If the signature does not verify, and the body contains anything other than a status response, a new message containing a status response MUST be returned using a CMCFailInfo with a value of badMessageCheck and a bodyPart of 0. 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 in the signedData object. 3.6.2 Enveloped Data EnvelopedData is the primary method of providing confidentiality for sensitive information in this protocol. The protocol currently uses EnvelopedData to provide encryption of an entire request (see section 4.5). The envelopedData object would also be used to wrap private key material for key archival. If the decryption on an envelopedData failes, the response is a CMCFailInfo with a value of badMessageCheck and a bodyPart of 0. Servers MUST implement envelopedData according to [CMS]. There is an ambiguity (about encrypting content types other than id-data) in the PKCS7 specification that has lead to non-interoperability. 3.6.3 Authenticated Data AuthenticatedData is used for providing origination authentication in those circumstances where a shared-secret exists, but a PKI trust anchor has not yet been established. This is currently only used for the publishAutenticatedData control (section 5.2.16). This control is uses the PKIData body so that new controls with additional policy type information could be included as well. 3.7 Other Message Bodies The other message body portion of the message allows for arbitrary data objects to be carried as part of a message. This is intended to contain data that is not already wrapped in a CMS contentInfo object. The data is ignored unless a control attribute references the data by bodyPartId. OtherMsg ::= SEQUENCE { bodyPartID BodyPartID, otherMsgType OBJECT IDENTIFIER, otherMsgValue ANY DEFINED BY otherMsgType } -- bodyPartID contains the unique id of this object -- otherMsgType contains the OID defining both the usage of this body part and the syntax of the value associated with this body part -- otherMsgValue contains the data associated with the message body part. 3.8 Unsigned Attributes There is sometimes a need to include data in an enrollment message designed to be removed during processing. An example of this is the inclusion of an encrypted private key, where a key archive agent removes the encrypted private key before sending it on to the CA. One side effect of this desire is the fact that every RA which encapsulates this information needs to move the data so that it is not covered by the RA signature. (A client request, encapsulated by an RA cannot have the unsigned attribute removed by the key archive agent without breaking the RA's signature.) This attribute addresses that problem. This attribute is used to contain the information that is not directly signed by a user. When an RA finds a message that has this attribute in the unsigned or unauthenticated attribute fields of the CMS objects it is aggregating, they are removed from the embedded CMS objects and propagated up to the RA CMS object. id-cmc-UnsignedData OBJECT IDENTIFIER ::= {} CMCUnsignedData ::= SEQUENCE { bodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID, identifier OBJECT IDENTIFIER, content ANY DEFINED BY identifier } There MUST be at most one CMCUnsignedData attribute in the UnsignedAttribute sequence of a SignerInfo structure. If the attribute appears in one SignerInfo in a sequence, it MUST appear the same in all SignerInfo items and MUST have the same value. 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 for a private key that is capable of generating a signature, the PKCS10 MUST be signed with that private key. If this form of the enrollment request is used for a D-H key, then the D-H POP mechanism described in [DH-POP] MUST be used. Servers MUST support the Simple Enrollment Request message. If the Simple Enrollment Request message is used, servers MUST return the Simple Enrollment Response message (see Section 4.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. The Simple Enrollment Request message MUST NOT be used if a proof- of-identity needs to be included. Many advanced services specified in this memo are 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 enrolling. Servers MUST support the Full Enrollment Request message. An enrollment response (full or simple as appropriate) MUST be returned to all Full Enrollment Requests. The Full Enrollment Request message consists of a PKIData object wrapped in a signedData CMS object. The objects in the PKIData are ordered as follows: 1. All Control Attributes, 2. All certification requests, 3. All CMS objects, 4. All other messages. Each object in the PKIData sequence is identified by a Body Part Identifier. If duplicate ids are found, the server MUST return the error badRequest with a bodyPartID of 0. The signedData object wrapping the PKIData may be signed either by the private key material of the signature certification request, or by a previously certified signature key. If the private key of a signature certification request is being used, then: a) the certification request containing the corresponding public key MUST include a Subject Key Identifier extension, b) the subjectKeyIdentifier form of signerInfo MUST be used, and c) the value of the subjectKeyIdentifier form of signerInfo MUST be the Subject Key Identifier specified in the corresponding certification request. (The subjectKeyIdentifier form of signerInfo is used here because no certificates have yet been issued for the signing key.) If the request key is used for signing, there MUST be only one signerInfo object in the signedData object. When creating a message to renew a certificate, the following should be taken into consideration: 1. The identification and identityProof 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 be able to process 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 intermediate certificates needed to form complete chains to one or more self-signed certificates, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to explicitly trust the 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 be able to process a full PKI response message. The full enrollment response message consists of a signedData object encapsulating 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 intermediate certificates needed to form complete chains one ore more self-signed certificates, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely due to its presence in the certificate bag. In the event clients receive a new self-signed certificate from the server, clients SHOULD provide a mechanism to enable the user to explicitly trust the 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 from being accessible to unauthorized entities. This section describes the means used to encrypt a PKI message. This section is not applicable to a simple enrollment message. Confidentiality is provided 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 can remove the enveloped data wrapping, and replace or forward without further processing. Section 6 contains more information about LRA 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 MAY use such channels instead of the 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 memo. Control Attribute OID Syntax ----------------- ---------- -------------- cMCStatusInfo id-cmc 1 CMCStatusInfo identification id-cmc 2 UTF8String identityProof id-cmc 3 OCTET STRING dataReturn id-cmc 4 OCTET STRING transactionId id-cmc 5 INTEGER senderNonce id-cmc 6 OCTET STRING recipientNonce id-cmc 7 OCTET STRING addExtensions id-cmc 8 AddExtensions encryptedPOP id-cmc 9 EncryptedPOP decryptedPOP id-cmc 10 DecryptedPOP lraPOPWitness id-cmc 11 LraPOPWitness getCert id-cmc 15 GetCert getCRL id-cmc 16 GetCRL revokeRequest id-cmc 17 RevokeRequest regInfo id-cmc 18 OCTET STRING responseInfo id-cmc 19 OCTET STRING QueryPending id-cmc 21 OCTET STRING idPOPLinkRandom id-cmc 22 OCTET STRING idPOPLinkWitness id-cmc 23 OCTET STRING idConfirmCertAcceptance id-cmc 24 CMCCertId cmcStatusInfoExt id-cmc XX CMCStatusInfoExt publishTrustRoot id-cmc XX CertificateSequence publishAuthenticatedData id-cmc XX AuthPublish batchRequests id-cmc XX BodyPartList batchResponses id-cmc XX BodyPartList 5.1 CMC Status Info Control Attributes The CMC status info control is used in full PKI Response messages to return information about the processing of a client request. Two controls are described in this section. The first is the preferred control, the second is included for backwards compatibility with RFC 2797. Servers MAY emit multiple CMC status info controls referring to a single body part. Clients MUST be able to deal with multiple CMC status info controls in a response message. Servers MUST use the CMCStatusInfoExt control, but MAY additionally use the CMCStatusInfo attribute. Clients MUST be able to process the CMCStatusInfoExt control. 5.1.1 Extended CMC Status Info Control Attribute This control uses the following ASN.1 definition: CMCStatusInfoExt ::= SEQUENCE { CMCStatus CMCStatus, BodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference, StatusString UTF8String OPTIONAL, OtherInfo CHOICE { FailInfo CMCFailInfo, PendInfo PendInfo, ExtendedFailInfo SEQUENCE { FailInfoOID OBJECT IDENTIFIER, FailInfoValue AttributeValue } } } BodyPartReference ::= CHOICE { BodyPartID BodyPartID, BodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID } PendInfo ::= SEQUENCE { pendToken OCTET STRING, pendTime GeneralizedTime } -- cMCStatus is described in section 5.1.3 -- bodyList contains the list of references to body parts in the request message to which this status information applies. If an error is being returned for a simple enrollment message, body list will contain a single integer of value '1'. -- statusString contains a string with additional description information. This string is human readable. -- failInfo is described in section 5.1.4. It provides a detailed error on what the failure was. This choice is present only if cMCStatus is failed. -- extendedFailInfo is provided for other users of the enrollment protocol to provided their own error codes. This choice is present only if cMCStatus is failed. Caution should be used in defining new values as they may not be correctly recognized by all clients and servers. The failInfo value of internalCA error may be assumed if the extended error is not recognized. -- 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 it is 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.1.2 CMC Status Info Control Attribute The CMC status info control is used in full PKI Response messages to return information on a client request. Servers MAY emit multiple CMC status info controls referring to a single body part. Clients MUST be able to deal with multiple CMC status info controls in a response message. This statement uses the following ASN.1 definition: CMCStatusInfo ::= SEQUENCE { cMCStatus CMCStatus, bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, statusString UTF8String OPTIONAL, otherInfo CHOICE { failInfo CMCFailInfo, pendInfo PendInfo } OPTIONAL } -- cMCStatus is described in section 5.1.3 -- bodyList contains the list of body parts in the request message to which this status information applies. If an error is being returned for a simple enrollment message, body list will contain a single integer of value '1'. -- statusString contains a string with additional description information. This string is human readable. -- failInfo is described in section 5.1.4. It provides a detailed error on what the failure was. This choice is present only if cMCStatus is failed. If the cMCStatus field is success, the CMC Status Info Control MAY be omitted unless it is 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.1.3 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), -- request was granted -- reserved (1), -- not used, defined where the original structure was defined failed (2), -- you don't get what you want, 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 confirmRequired (5) -- conformation using the idConfirmCertAcceptance control is required -- before use of certificate } 5.1.4 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 badIdentity (7) -- Identification Attribute failed to verify popRequired (8) -- Server requires a POP proof before issuing certificate popFailed (9) -- POP processing failed 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.2 Identification and IdentityProof 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 MUST provide this method and MAY also 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 shared-secret should be generated in a random manner. 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 field of the PKIData object (encoded exactly as it appears in the request message including the sequence type and length) 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 value 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 identityProof attribute. When the server verifies the identityProof attribute, it computes the HMAC-SHA1 value in the same way and compares it to the identityProof attribute contained in the enrollment request. If a server fails the verification of an identityProof attribute and the server returns a response message, the failInfo attribute MUST be present in the response and MUST have a value of badIdentity. Reuse of the shared-secret on enrollment retries makes it easier for the client and to prevent getting out of sync. However, reuse of the shared-secret can potentially open the door for some types of attacks. Optionally, servers MAY require the inclusion of the unprotected identification attribute with an identification attribute. The identification attribute is intended to contain either a text string or a numeric quantity, such as a random number, which assists the server in locating the shared secret needed to validate the contents of the identityProof attribute. Numeric values MUST be converted to text string representations prior to encoding as UTF8-STRINGs in this attribute. If the identification control attribute 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. 5.2.1 Hardware Shared Secret Token Generation The shared secret between the end-entity and the identity verify is sometimes transferred using a hardware device that generates a series of tokens based on some shared secret value. The user can therefore prove their identity by transferring this token in plain text along with a name string. The above protocol can be used with a hardware shared-secret token generation device by the following modifications: 1. The identification attribute MUST be included and MUST contain the hardware-generated token. 2. The shared secret value used above is the same hardware-generated token. 3. All certification requests MUST have a subject name and the subject name MUST contain the fields required to identify the holder of the hardware token device. 5.3 Linking Identity and POP Information In a PKI Full Request message identity information about the creator/author of the message is carried in the signature of the CMS SignedData object containing all of the certificate requests. Proof- of-possession information for key pairs requesting certification, however, is carried separately for each PKCS#10 or CRMF message. (For keys capable of generating a digital signature, the POP is provided by the signature on the PKCS#10 or CRMF request. For encryption-only keys the controls described in Section 5.7 below are used.) In order to prevent substitution-style attacks we must guarantee that the same entity generated both the POP and proof-of- identity information. This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 5.3.1) and shared-secret/subject DN matching (Section 5.3.2). Clients and servers MUST support the witness value technique. Clients and servers MAY support shared-secret/subject DN matching or other bilateral techniques of similar strength. The idea behind both mechanisms is to force the client to sign some data into each certificate request that can be directly associated with the shared-secret; this will defeat attempts to include certificate requests from different entities in a single Full PKI Request message. 5.3.1 Witness values derived from the shared-secret The first technique for doing identity-POP linking works by forcing the client to include a piece of information cryptographically- derived from the shared-secret token as a signed extension within each certificate request (PKCS#10 or CRMF) message. This technique is useful if null subject DNs are used (because, for example, the server can generate the subject DN for the certificate based only on the shared secret). Processing begins when the client receives the shared-secret token out-of-band from the server. The client then computes the following values: 1. The client generates a random byte-string, R, which SHOULD be at least 512 bits in length. 2. A SHA1 hash of the token is computed. 3. An HMAC-SHA1 value is then computed over the random value produced in Step 1, as described in [HMAC], using the hash of the token from Step 2 as the shared secret. 4. The random value produced in Step 1 is encoded as the value of an idPOPLinkRandom control attribute. This control attribute MUST be included in the Full PKI Request message. 5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value of an idPOPLinkWitness extension to the certificate request. a. For CRMF, idPOPLinkWitness is included in the controls section of the CertRequest structure. b. For PKCS#10, idPOPLinkWitness is included in the attributes section of the CertificationRequest structure. Upon receipt, servers MUST verify that each certificate request contains a copy of the idPOPLinkWitness and that its value was derived in the specified manner from the shared secret and the