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: | | * | | * | | *| | * | | * | | * | | * | | | | | | 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