diff options
Diffstat (limited to 'doc/rfc/rfc2797.txt')
| -rw-r--r-- | doc/rfc/rfc2797.txt | 2635 |
1 files changed, 2635 insertions, 0 deletions
diff --git a/doc/rfc/rfc2797.txt b/doc/rfc/rfc2797.txt new file mode 100644 index 0000000..22b8184 --- /dev/null +++ b/doc/rfc/rfc2797.txt @@ -0,0 +1,2635 @@ + + + + + + +Network Working Group M. Myers +Request for Comments: 2797 VeriSign +Category: Standards Track X. Liu + Cisco + J. Schaad + Microsoft + J. Weinstein + April 2000 + + + Certificate Management Messages over CMS + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +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]. + + + +Myers, et al. Standards Track [Page 1] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +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. + + + + +Myers, et al. Standards Track [Page 2] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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. + + + +Myers, et al. Standards Track [Page 3] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + "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 + + + + + + + + + + + + + + + +Myers, et al. Standards Track [Page 4] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + Full PKI Request Full PKI Response + ----------------------- ------------------------ + + +----------------+ +----------------+ + | CMS signedData | | CMS signedData | + | object | | object | + +----------------+--------+ +----------------+--------+ + | | | | + | PKIData object | | ResponseBody object | + | | | | + | Sequence of: | | Sequence of: | + | <enrollment attribute>* | | <enrollment attribute>* | + | <certification request>*| | <CMS object>* | + | <CMS objects>* | | <other message>* | + | <other message>* | | | + | | | 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. + + + + + + + +Myers, et al. Standards Track [Page 5] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +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 OBJECT IDENTIFIER ::= { id-cct 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 certificate requests. The + certificate requests can be either a CertificateRequest (PKCS10 + request) or a CertReqMsg. Details on each of these request types are + found in sections 3.3.1 and 3.3.2 respectively. + + -- cmsSequence consists of a sequence of [CMS] message objects. This + protocol only uses EnvelopedData, SignedData and EncryptedData. 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. + +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 OBJECT IDENTIFIER ::= { id-cct 3 } + + + + + + +Myers, et al. Standards Track [Page 6] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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 and EncryptedData. 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. + +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. + +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. + + + + + +Myers, et al. Standards Track [Page 7] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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 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. + - In general, when both CRMF and CMC controls exist with equivalent + functionality, the CMC control SHOULD be used. The CMC control + MUST override any 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. + + + + + +Myers, et al. Standards Track [Page 8] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + - 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 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. + + + + +Myers, et al. Standards Track [Page 9] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +3.3.3.2 Diffie-Hellman POP Signature + + CMC compliant implementations MUST support section 5 of [DH-POP]. + +3.3.3.3 Diffie-Hellman MAC signature + + CMC compliant implementations MAY support section 4 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. + + The syntax of a control attribute is + + TaggedAttribute ::= SEQUENCE { + bodyPartID BodyPartId, + attrType OBJECT IDENTIFIER, + attrValues SET OF AttributeValue + } + + + + + +Myers, et al. Standards Track [Page 10] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + -- 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. + + + + + + +Myers, et al. Standards Track [Page 11] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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. + + 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.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. + +4. PKI Messages + + This section discusses the details of putting together the different + enrollment request and response messages. + + + + + + + + +Myers, et al. Standards Track [Page 12] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +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. + + 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 element in a Full Enrollment Request 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 request, + b) the subjectKeyIdentifier form of signerInfo MUST be used, and + + + + +Myers, et al. Standards Track [Page 13] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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. + + + + + + + + +Myers, et al. Standards Track [Page 14] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +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: + + + + + + + +Myers, et al. Standards Track [Page 15] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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. + + + + + + + + + + + + + + + + + + + +Myers, et al. Standards Track [Page 16] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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 + +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. 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 + } + + PendInfo ::= SEQUENCE { + pendToken OCTET STRING, + pendTime GeneralizedTime + } + + + + + + + +Myers, et al. Standards Track [Page 17] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + -- cMCStatus is described in section 5.1.1 + + -- 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.2. It provides a detailed + error on what the failure was. This choice is present only if + cMCStatus is failed. + + -- 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.1 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) + + + + +Myers, et al. Standards Track [Page 18] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + -- conformation using the idConfirmCertAcceptance control is + required + -- before use of certificate + } + +5.1.2 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. + + + + + + + + + +Myers, et al. Standards Track [Page 19] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +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 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. + + 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 + + + + + +Myers, et al. Standards Track [Page 20] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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. + + + + + +Myers, et al. Standards Track [Page 21] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +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 random + string included in the idPOPLinkRandom control attribute. + +5.3.2 Shared-secret/subject DN matching + + The second technique for doing identity-POP linking is to link a + particular subject distinguished name (subject DN) to the shared- + secrets that are distributed out-of-band and to require that clients + using the shared-secret to prove identity include that exact subject + DN in every certificate request. It is expected that many client- + server connections using shared-secret based proof-of-identity will + use this mechanism. (It is common not to omit the subject DN + information from the certificate request messages.) + + When the shared secret is generated and transferred out-of-band to + initiate the registration process (Section 5.2), a particular subject + DN is also associated with the shared secret and communicated to the + client. (The subject DN generated MUST be unique per entity in + + + +Myers, et al. Standards Track [Page 22] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + accordance with CA policy; a null subject DN cannot be used. A + common practice could be to place the identification value as part of + the subject DN.) When the client generates the Full PKI Request + message, it MUST use these two pieces of information as follows: + + 1. The client MUST include the specific subject DN that it received + along with the shared secret as the subject name in every + certificate request (PKCS#10 and/or CRMF) in the Full PKI Request. + The subject names in the requests MUST NOT be null. + 2. The client MUST include the identityProof control attribute + (Section 5.2), derived from the shared secret, in the Full PKI + Request. + + The server receiving this message MUST (a) validate the identityProof + control attribute and then, (b) check that the subject DN included in + each certificate request matches that associated with the shared + secret. If either of these checks fails the certificate request MUST + be rejected. + +5.3.3 Renewal and Re-Key Messages + + In a renewal or re-key message, the subject DN in (a) the certificate + referenced by the CMS SignerInfo object, and (b) all certificate + requests within the request message MUST match according to the + standard name match rules described in [PKIXCERT]. + +5.4 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, but the details of this are + outside the scope of this specification. + + An example of using this feature 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. + + + + + +Myers, et al. Standards Track [Page 23] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +5.5 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 BodyPartID + certReferences SEQUENCE OF BodyPartID, + extensions SEQUENCE OF Extension + } + + -- pkiDataReference field contains the body part id of the + embedded request message. + + -- 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. If a request corresponding to bodyPartID cannot be + found, the error badRequest is returned referencing this control + attribute. + + -- extensions field contains the sequence of extensions to be + applied to the referenced certificate requests. + + Servers MUST be able to process all extensions defined in [PKIXCERT]. + 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 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. These + rules would be applied to individual extensions within an Add + Extensions control attribute (as opposed to an "all or nothing" + approach). + + + + + +Myers, et al. Standards Track [Page 24] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 1. If the conflict is within a single PKIData object, the certificate + request would be rejected with an error of badRequest. + + 2. If the conflict is between different PKIData objects, the + outermost version of the extension would be used (allowing an LRA + to override the extension requested by the end-entyt). + +5.6 Transaction Management Control Attributes + + Transactions are 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. + Clients MAY include a transactionID attribute in request messages. + If the original request contains a transactionID attribute, all + subsequent request and response messages MUST include the same + transactionID attribute. A server MUST use only transactionIds in + the outermost PKIdata object. TransactionIds on inner PKIdata objects + are for intermediate entities. + + Replay protection can be supported through the use of sender and + recipient nonces. 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 value for senderNonce is + also retained for inclusion in the next message associated with the + same transaction. + + The senderNonce and recipientNonce attribute can be used to provide + application-level replay prevention. Clients MAY include a + senderNonce in the initial request message. Originating messages + include only a value for senderNonce. If a message includes a + senderNonce, the response MUST include the transmitted value of the + previously received senderNonce as recipientNonce and include new + value for senderNonce. A server MUST use only nonces in the outermost + PKIdata object. Nonces on inner PKIdata objects are for intermediate + entities. + + + + + +Myers, et al. Standards Track [Page 25] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +5.7 Proof-of-possession (POP) for encryption-only keys + + Everything described in this section is optional to implement, for + both servers and clients. Servers MAY require this POP method be used + only if another POP method is unavailable. Servers SHOULD 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 + for a public key actually possesses the corresponding private + component of the key pair. For keys that can be used as signature + keys, signing the certification request with the private key serves + 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 { + + request TaggedRequest, + cms contentInfo, + thePOPAlgID AlgorithmIdentifier, + witnessAlgID AlgorithmIdentifier, + witness OCTET STRING + + + +Myers, et al. Standards Track [Page 26] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + } + + DecryptedPOP ::= SEQUENCE { + bodyPartID BodyPartID, + 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. request is the certificate request in the original request + message (it is included here so the client need not key a copy + of the request), + b. cms is an EnvelopedData object, the content type being id-data + and the content being 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. + The client aborts the process by sending a request message + containing a CMCStatusInfo control attribute with failInfo value + of popFailed. + 4. The client creates the decryptedPOP as part of a new PKIData + message. The fields in the decryptedPOP are: + a. bodyPartID refers to 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 + + + +Myers, et al. Standards Track [Page 27] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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 and the request referenced in (4a) is used as the + data. If y is greater than 64 bytes, only the first 64 bytes of y + are used as the secret. + + 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 certificate request R, server computes y = F(x,R). F can be, + for example, HMAC-SHA1(x,R). 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 R, thus the use of a OWF like HMAC-SHA1. + +5.8 LRA POP Witnesses Control Attribute + + In an enrollment scenario involving an LRAs the CA may allow (or + require) the LRA to perform the POP protocol with the entity + requesting certification. 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 BodyPartID, + bodyIds SEQUENCE of BodyPartID + } + + -- pkiDataBodyid field contains the body part id of the nested CMS + body object containing the client's full request message. + pkiDataBodyid is set to 0 if the request is in the current + PKIRequest body. + + + + + +Myers, et al. Standards Track [Page 28] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + -- bodyIds 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.9 Get Certificate Control Attribute + + Everything described in this section is optional to implement. + + The get certificate control attribute is used to retrieve previously + issued certificates from a repository of certificates. A Certificate + Authority, 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 its own certificate in non-volatile memory.) + + 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 + get certificate attribute is the only control in a Full PKI Request + message, the response would be a Simple Enrollment Response. + +5.10 Get CRL Control Attribute + + Everything described in this section is optional to implement. + + The get CRL control attribute is used to retrieve CRLs from a + repository of CRLs. A Certification Authority, 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. + + The get CRL control attribute has the following ASN.1 structure: + + + + + + + +Myers, et al. Standards Track [Page 29] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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 name of the CRL issuer. + + -- 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. Implementers 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.11 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: + + RevRequest ::= SEQUENCE { + issuerName Name, + serialNumber INTEGER, + reason CRLReason, + invalidityDate GeneralizedTime OPTIONAL, + sharedSecret OCTET STRING OPTIONAL, + comment UTF8string OPTIONAL } + + + + + +Myers, et al. Standards Track [Page 30] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + -- issuerName contains the issuerName of the certificate to be + revoked. + + -- serialNumber contains the serial number of the certificate to + be revoked + + -- reason contains the suggested CRLReason code for why the + certificate is being revoked. The CA can use this value at its + discretion in building the CRL. + + -- invalidityDate contains the suggested value for the Invalidity + Date CRL Extension. The CA can use this value at its discretion + in building the CRL. + + -- sharedSecret contains a secret value registered by the EE when + the certificate was obtained to allow for revocation of a + certificate in the event of key loss. + + -- comment contains a human readable comment. + + For a revocation request to become a reliable object in the event of + a dispute, a strong proof of originator authenticity is required. + However, in the instance when an end-entity has lost use of its + signature private key, it is impossible for the end-entity to produce + a digital signature (prior to the certification of a new signature + key pair). 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. + + (Note that in some situations a Registration Authority may be + delegated authority to revoke certificates on behalf of some + population within its scope control. In these situations the CA + would accept the LRA's digital signature on the request to revoke a + certificate, independent of whether the end entity still had access + to the private component of the key pair.) + + Clients MUST provide the capability to produce a digitally signed + revocation request control attribute. Clients SHOULD be capable of + producing 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. Servers MUST be capable of + accepting both forms of revocation requests. + + The structure of an unsigned, shared secret based revocation request + is a matter of local implementation. The shared secret does not need + to be encrypted when sent in a revocation request. The shared secret + + + +Myers, et al. Standards Track [Page 31] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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.12 Registration and Response Information Control Attributes + + The regInfo control attribute is for clients and LRAs to pass + additional information as part a PKI request. The regInfo 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 data submitted in a regInfo attribute, then that data + is returned as a responseInfo control attribute. The content of the + OCTET STRING for response information is based on bilateral agreement + between the client and server. + +5.13 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 server can also return a + suggested time for the client to query for the state of a pending + certificate request. + + The ASN.1 structure used by the query pending control attribute is: + + QueryPending ::= OCTET STRING + + 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). + + + + + + +Myers, et al. Standards Track [Page 32] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +5.14 Confirm Certificate Acceptance + + Some Certification Authorities require that clients give a positive + conformation that the certificates issued to it are acceptable. The + Confirm Certificate Acceptance control attribute is used for that + purpose. If the CMCStatusInfo on a certificate request is + confirmRequired, then the client MUST return a Confirm Certificate + + Acceptance prior to any usage of the certificate. Clients SHOULD + wait for the response from the server that the conformation has been + received. + + The confirm certificate acceptance structure is: + + CMCCertId ::= IssuerSerial + + -- CMCCertId contains the issuer and serial number of the + certificate being accepted. + + Servers MUST return a full enrollment response for a confirm + certificate acceptance control. + +6. Local Registration Authorities + + This specification permits the use of Local Registration Authorities + (LRAs). An LRA sits between the end-entity and the Certification + Authority. From the end-entity's perspective, 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 has three options: it + may forward the message without modification, it may add a new + wrapping layer to the message, or it may remove one or more existing + layers and add a new wrapping layer. + + When an LRA adds a new wrapping layer to a message it creates a new + PKIData object. The new layer contains any control attributes + required (for example if the LRA does the POP proof for an encryption + key or the addExtension control attribute to modify an enrollment + + + +Myers, et al. Standards Track [Page 33] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + request) and the client enrollment message. The client enrollment + message is placed in the cmsSequence if it is a Full Enrollment + message and in the reqSequence if it is a Simple Enrollment message. + If an LRA is batching multiple client messages together, then each + client enrollment message is placed into the appropriate location in + the LRA's PKIData object along with all relevant control attributes. + + (If multiple LRAs are in the path between the end-entity and the + Certification Authority, this will lead to multiple wrapping layers + on the message.) + + In processing an enrollment message, an LRA MUST NOT alter any + certificate request body (PKCS #10 or CRMF) as any alteration would + invalidate the signature on the request and thus the POP for the + private key. + + 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 + + Under some circumstances an LRA is required to remove wrapping + layers. The following sections look at the processing required if + encryption layers and signing layers need to be removed. + +6.1 Encryption Removal + + There are two cases that require an LRA to remove or change + encryption in an enrollment message. In the first case the + encryption was applied for the purposes of protecting the entire + enrollment request from unauthorized entities. If the CA does not + have a recipient info entry in the encryption layer, the LRA MUST + remove the encryption layer. The LRA MAY add a new encryption layer + with or without adding a new signing layer. + + The second change of encryption that may be required is to change the + encryption inside of a signing layer. In this case the LRA MUST + remove all signing layers containing the encryption. All control + statements MUST be merged according to local policy rules as each + + + +Myers, et al. Standards Track [Page 34] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + signing layer is removed and the resulting merged controls MUST be + placed in a new signing layer provided by the LRA. If the signing + layer provided by the end-entity needs to be removed to the LRA can + remove the layer. + +6.2 Signature Layer Removal + + Only two instances exist where an LRA should remove a signature layer + on a Full Enrollment message. If an encryption needs to be modified + within the message, or if a Certificate Authority will not accept + secondary delegation (i.e. multiple LRA signatures). In all other + situations LRAs SHOULD NOT remove a signing layer from a message. + + If an LRA removes a signing layer from a message, all control + statements MUST be merged according to local policy rules. The + resulting merged control statements MUST be placed in a new signing + layer provided by the LRA. + +7. Transport Wrapping + + Not all methods of transporting data allow for sending unlabeled raw + binary data, in may cases standard methods of encoding can be used to + greatly ease this issue. These methods normally consist of wrapping + some identification of the content around the binary data, possibly + applying an encoding to the data and labeling the data. We document + for use three different wrapping methods. + + -- MIME wrapping is for transports that are natively MIME based such + as HTTP and E-mail. + -- Binary file transport is defined since floppy disk transport is + still very common. File transport can be done either as MIME + wrapped (section 7.1) or bare (section 7.2). + -- Socket based transport uses the raw BER encoded object. + +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 a content type or content disposition statement. The extension + for the file MUST be ".p10". + + + + + + + +Myers, et al. Standards Track [Page 35] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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) + +application/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 Response + messages, the following file type extensions SHOULD be used: + + Message Type File Extension + + Full PKI Request .crq + + Full PKI Response .crp + + + + + + +Myers, et al. Standards Track [Page 36] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +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. + +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 (as + 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]. + +8.2 Minimum Conformance Requirements + + A minimally compliant CMC server: + + a) MUST accept a Full PKI Request message + i) MUST accept CRMF Request Bodies within a Full PKI Request + ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request + b) MUST accept a Simple Enrollment Request message + c) MUST be able to return a Full PKI Response. (A Full PKI Response + is always a valid response, but for interoperability with + downlevel clients a compliant server SHOULD use the Simple + Enrollment Response whenever possible.) + + A minimally-complaint CMC client: + + a) MAY use either the Simple Enrollment Message or the Full PKI + Request. + i) clients MUST use PKCS#10 with the Simple Enrollment Message + ii) clients MAY use either PKCS#10 or CRMF with the Full PKI + Request + b) MUST understand the Simple Enrollment Response. + c) MUST understand the Full PKI Response. + + + + +Myers, et al. Standards Track [Page 37] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +9. Security Considerations + + Initiation of a secure communications channel between an end-entity + and a CA or LRA (and, similarly, between an LRA and another LRA or + 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.6. 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. A description of the small subgroup attack + is provided in [X942]. CMC implementations ought to be aware of this + attack when doing parameter validations. + + + + + + + + + + + + +Myers, et al. Standards Track [Page 38] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +10. Acknowledgments + + The authors would like to thank Brian LaMacchia for his work in + developing and writing up many of the concepts presented in this + document. The authors would also like to thank Alex Deacon and Barb + Fox for their contributions. + +11. References + + [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, + June 1999. + + [CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet + X.509 Certificate Request Message Format", RFC 2511, March + 1999. + + [DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" + + [DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of- + Possession Algorithms", Work in Progress. + + [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC + 2313, March 1998. + + [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5", + RFC 2315, October 1997. + + [PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax + Standard, Version 1.2", November 1, 1993. + + [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax + v1.5", RFC 2314, October 1997. + + [PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet + X.509 Public Key Infrastructure Certificate and CRL + Profile", RFC 2459, January 1999. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. + Repka, "S/MIME Version 2 Message Specification", RFC 2311, + March 1998. + + + + +Myers, et al. Standards Track [Page 39] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + [SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification", + RFC 2633, June 1999. + + [X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC + 2631, June 1999. + +12. Authors' Addresses + + Michael Myers + VeriSign Inc. + 1350 Charleston Road + Mountain View, CA, 94043 + + Phone: (650) 429-3402 + EMail: mmyers@verisign.com + + + Xiaoyi Liu + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + + Phone: (480) 526-7430 + EMail: xliu@cisco.com + + + Jim Schaad + + EMail: jimsch@nwlink.com + + + Jeff Weinstein + + EMail: jsw@meer.net + + + + + + + + + + + + + + + + + +Myers, et al. Standards Track [Page 40] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +Appendix A ASN.1 Module + +EnrollmentMessageSyntax + { iso(1) identified-organization(3) dod(4) internet(1) + security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) } + + 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 + 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 { 1 3 6 1 5 5 7 0 5 }; + + id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + + + +Myers, et al. Standards Track [Page 41] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls + id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types + + -- The following controls have simple type content (usually OCTET +STRING) + + id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2} + id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3} + id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4} + id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5} + id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6} + id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7} + id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18} + id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19} + id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21} + id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22) + id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23) + + -- This is the content type used for a request message in the +protocol + + id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 } + + + 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 + } + + bodyIdMax INTEGER ::= 4294967295 + + BodyPartID ::= INTEGER(0..bodyIdMax) + + TaggedAttribute ::= SEQUENCE { + bodyPartID BodyPartId, + attrType OBJECT IDENTIFIER, + attrValues SET OF AttributeValue + } + + AttributeValue ::= ANY + + TaggedRequest ::= CHOICE { + tcr [0] TaggedCertificationRequest, + crm [1] CertReqMsg + + + +Myers, et al. Standards Track [Page 42] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + } + + TaggedCertificationRequest ::= SEQUENCE { + bodyPartID BodyPartID, + 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 BodyPartId, + contentInfo ContentInfo + } + + OtherMsg ::= SEQUENCE { + bodyPartID BodyPartID, + otherMsgType OBJECT IDENTIFIER, + otherMsgValue ANY DEFINED BY otherMsgType } + + -- This defines the response message in the protocol + id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 } + + 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-cmc-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1} + + CMCStatusInfo ::= SEQUENCE { + cMCStatus CMCStatus, + bodyList SEQUENCE SIZE (1..MAX) OF INTEGER, + statusString UTF8String OPTIONAL, + otherInfo CHOICE { + failInfo CMCFailInfo, + + + +Myers, et al. Standards Track [Page 43] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + 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) + + + +Myers, et al. Standards Track [Page 44] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + } + + -- Used for LRAs to add extensions to certificate requests + id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8} + + AddExtensions ::= SEQUENCE { + pkiDataReference BodyPartID, + certReferences SEQUENCE OF BodyPartID, + extensions SEQUENCE OF Extension + } + + + id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9} + id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10} + + EncryptedPOP ::= SEQUENCE { + request TaggedRequest, + cms ContentInfo, + thePOPAlgID AlgorithmIdentifier, + witnessAlgID AlgorithmIdentifier, + witness OCTET STRING + } + + DecryptedPOP ::= SEQUENCE { + bodyPartID BodyPartID, + thePOPAlgID AlgorithmIdentifier, + thePOP OCTET STRING + } + + id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11} + + LraPopWitness ::= SEQUENCE { + pkiDataBodyid BodyPartID, + bodyIds SEQUENCE OF BodyPartID + } + + + -- + id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15} + + GetCert ::= SEQUENCE { + issuerName GeneralName, + serialNumber INTEGER } + + + id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16} + + GetCRL ::= SEQUENCE { + + + +Myers, et al. Standards Track [Page 45] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + + issuerName Name, + cRLName GeneralName OPTIONAL, + time GeneralizedTime OPTIONAL, + reasons ReasonFlags OPTIONAL } + + id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17} + + RevRequest ::= SEQUENCE { + issuerName Name, + serialNumber INTEGER, + reason CRLReason, + invalidityDate GeneralizedTime OPTIONAL, + passphrase OCTET STRING OPTIONAL, + comment UTF8String OPTIONAL } + + id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24} + + CMCCertId ::= IssuerSerial + + -- 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 + + -- The following exists to allow Diffie-Hellman Certificate Requests +Messages to be + -- well-formed + + id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} + + NoSignatureValue ::= OCTET STRING + +END + + + + + + + + + + + + + + + +Myers, et al. Standards Track [Page 46] + +RFC 2797 Certificate Management Messages over CMS April 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Myers, et al. Standards Track [Page 47] + |