Technical Summary
This document series obsoletes RFC 2797, "Certificate Management
Protocol over CMS" (CMC). The update to CMC addresses two needs within
the Internet PKI community:
1. The need for an interface to public key certification
products and services based on CMS and PKCS #10; and
2. The need in S/MIME for a certificate enrollment protocol
for DSA-signed certificates with Diffie-Hellman public keys.
The updated CMC protocol preserves full backwards compatibility with
RFC 2797. No features defined in RFC 2797 have been changed, only new
features have been added.
The compliance document updates and expands the compliance
requirements specified in RFC 2797. The compliance requirements
specified in this document have expanded scope and increased detail to
ensure interoperability of future implementations.
The transport protocol document updates the transport mechanisms
defined in RFC 2797. The technical content is essentially unchanged
from RFC 2797, but was separated from the message formats for process
reasons. The transport mechanisms described in this document are
HTTP, file, mail, and TCP.
Working Group Summary
These documents are a product of the PKIX Working Group, which has
extensively reviewed this technical content. All PKIX WG Last Call
issues have been resolved. Discussion during PKIX WG Last Call
demonstrated working group consensus. This document has strong
PKIX WG support.
Protocol Quality
These documents reflect implementation experience, and address
important details not previously included in RFC 2797. Based on the
implementation experience, this specification is complete, and it is
sufficient to achieve expected levels of interoperability.
This document series was reviewed by Russ Housley and Tim Polk
for the IESG.
RFC Editor Note
In Section 5 of draft-ietf-pkix-cmc-trans, please make the
following substitution:
OLD:
The connection is closed by the client after recieving a final
response. If a second round of messages is needed, the client can
either re-use the same connection or use a new one.
NEW:
The client closes a connection after receiving a response, or it
issues another request to the server using the same connection.
Reusing one connection for multiple successive requests, instead of
opening multiple connections that are only used for a single
request, is RECOMMENDED for performance and resource conservation
reasons. A server MAY close a connection after it has been idle for
some period of time; this timeout would typically be several
minutes long.