Certificate Management Messages over CMS
RFC 2797
Document | Type |
RFC - Proposed Standard
(April 2000; Errata)
Obsoleted by RFC 5272
Was draft-ietf-pkix-cmc (pkix WG)
|
|
---|---|---|---|
Authors | Xiaoyi Liu , Jim Schaad , Michael Myers , Jeff Weinstein | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2797 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 newShow full document text