Certificate Management over CMS (CMC): Transport Protocols
updated by
- rfc-6402 — Certificate Management over CMS (CMC) Updates
Extracted elements (22)
HTTP over TLS is cited as the preferred mechanism for content protection from eavesdroppers in HTTP-based transport, rather than HTTP authentication mechanisms, which servers MUST NOT assume are available.
TCP connection reuse for multiple successive requests is recommended over opening multiple single-use connections, explicitly for performance and resource conservation reasons.
Clients MAY attempt to send HTTP requests using TLS 1.0 or later for content protection, although servers are not required to support TLS.
For mail-based transport, MIME wrapping between layers of CMS wrapping is optional, which differs from standard S/MIME message handling.
File type extensions SHOULD be used to identify CMC message types: .p10 for Simple PKI Request, .crq for Full PKI Request, .p7c for Simple PKI Response, and .crp for Full PKI Response.
For HTTP-based transport, clients MUST use the POST method to submit their requests.
For mail-based transport, simple enrollment requests MUST include a file name in a content-type or content-disposition statement, and the extension for the file MUST be '.p10'.
For TCP-based transport, only Private Ports 49152-65535 may be used without registration; ports in the range 1-49151 SHOULD NOT be used.
For TCP-based transport, reusing one connection for multiple successive requests instead of opening multiple connections is RECOMMENDED for performance and resource conservation.
Full enrollment request messages MUST be encoded as content type 'application/pkcs7-mime' with smime-type parameter 'CMC-Request' and a file name with the '.p7m' extension.
Full enrollment response messages MUST be encoded as content type 'application/pkcs7-mime' with smime-type parameter 'CMC-response' and a file name with the '.p7m' extension.
Servers MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication.
Servers MUST use the 200 response code for successful HTTP responses.
Simple enrollment response messages MUST be encoded as content type 'application/pkcs7-mime' with smime-type parameter 'certs-only' and a file name with the '.p7c' extension.
The Content-Type header in an HTTP PKI Response MUST have the appropriate value from Table 1.
When files are used to transport binary Full PKI Request or Full PKI Response messages, there MUST be only one instance of a request or response message in a single file.
Four CMC message types are defined for transport: Simple PKI Request (PKCS#10), Full PKI Request (CMS-wrapped), Simple PKI Response (certs-only), and Full PKI Response (CMS-wrapped). Each has assigned MIME types, file extensions, and smime-type parameters.
HTTP PKI Request body is the binary value of the encoding of the PKI Request, with the appropriate Content-Type header from Table 1.
HTTP PKI Response is composed of appropriate HTTP headers followed by the binary BER encoding of either a Simple or Full PKI Response.
TCP-based CMC transport sends messages in binary encoded form with no additional wrapping. The port to be used is configured out of band.
Establishing a secure channel between an end-entity and a CA or RA requires an out-of-band trust initiation mechanism (e.g., via IPsec or TLS). In cases where no prior out-of-band trust has been established, the Enveloped Data content type MUST be used to provide shrouding equivalent to what TLS would provide.
Mechanisms for thwarting replay attacks may be required depending on operational environment. Implementers must carefully consider whether to implement senderNonce and recipientNonce attributes (defined in CMC-STRUCT Section 6.6); state-constrained PKI clients are strongly encouraged to use these attributes.