RFC 10004: Certificate Management over CMS (CMC): Compliance Requirements

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10004.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.¶

1. Introduction

The Certificate Management over CMS (CMC) protocol is designed in terms of a client/server relationship. In the simplest case, the client is the requestor of the certificate (i.e., the End-Entity (EE)) and the server is the issuer of the certificate (i.e., the Certification Authority (CA)). The introduction of a Registration Authority (RA) into the set of agents complicates the picture only slightly. The RA becomes the server with respect to the certificate requestor, and it becomes the client with respect to the certificate issuer. Any number of RAs can be inserted into the picture in this manner.¶

The RAs may serve specialized purposes that are not currently covered by this document. One such purpose would be a Key Escrow agent. As such, all certificate requests for encryption keys would be directed through this RA, and it would take appropriate action to do the key archival. Key recovery requests could be defined in the CMC methodology allowing for the Key Escrow agent to perform that operation acting as the final server in the chain of agents.¶

If there are multiple RAs in the system, it is considered normal that not all RAs will see all certificate requests. The routing between the RAs may be dependent on the content of the certificate requests involved.¶

This document is divided into six sections, each section specifying the requirements that are specific to a class of agents in the CMC model. These are 1) all entities, 2) all servers, 3) all clients, 4) all EEs, 5) all RAs, and 6) all CAs.¶

This document obsoletes RFCs 5274 [CMC-COMPv1] and 6402 [CMC-Updates].¶

2. Terminology

There are several different terms, abbreviations, and acronyms used in this document that we define here for convenience and consistency of usage:¶

Refers to the entity that owns a key pair and for whom a certificate is issued.¶

Refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the EE and the CA. RAs may perform additional services such as key generation or key archival. This document uses the term RA for both RA and LRA.¶

Refers to the entity that issues certificates.¶

Refers to an entity that creates a Public Key Infrastructure (PKI) Request. In this document, both RAs and EEs can be clients.¶

Refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers.¶

Refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax.¶

Refers to the Certificate Request Message Format [CRMF]. CMC uses this certification request syntax defined in this document as part of the protocol.¶

Refers to the Cryptographic Message Syntax [CMS]. This document provides for basic cryptographic services including encryption and signing with and without key management.¶

Refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include certs-only messages, failure messages, etc.¶

Refers to the client proving they are who they say that they are to the server.¶

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 EE. See Section 2.1 of [CMC-STRUCT].¶

Refers to the outermost CMS wrapping layer.¶

Refers to EE, RA (or LRA), or CA.¶

Refers to the Hashed Message Authentication Code. CMC uses the ASN.1 module defined in [HMAC-ALGS].¶

3. Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4. Changes Since RFCs 5274 and 6402

Merged [CMC-Updates] text.¶

Updated the Introduction, changed "all agents" to "all entities" in the overview to maintain consistency throughout the document, and renumbered the section headers.¶

Added RA Identity Proof Witness and Response Body controls to Table 1.¶

Updated the Cryptographic Algorithm Requirements:¶

• Replaced SHA-1 with SHA-256¶

• Replaced HMAC-SHA-1 with HMAC-SHA-256¶

• Added algorithms for AuthEnvelopedData¶

Added a paragraph to maintain backward algorithm compatibility.¶

5. Requirements for All Entities

All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be adhered to unless specifically stated otherwise in this document.¶

All entities MUST support Full PKI Requests, Simple PKI Responses, and Full PKI Responses. Servers SHOULD support Simple PKI Requests.¶

All entities MUST support the use of the CRMF syntax for certification requests. Support for the PKCS #10 syntax for certification requests SHOULD be implemented by servers.¶

The extendedFailInfo field SHOULD NOT be populated in the CMCStatusInfoV2 object; the failInfo field SHOULD be used to relay this information. If the extendedFailInfo field is used, it is suggested that an additional CMCStatusInfoV2 item exist for the same body part with a failInfo field.¶

All entities MUST implement the HTTP transport mechanism as defined in [CMC-TRANS]. Other transport mechanisms MAY be implemented.¶

6. Requirements for Clients

There are no additional requirements.¶

7. Requirements for Servers

There are no additional requirements.¶

8. Requirements for EEs

If an EE implements Diffie-Hellman, it MUST implement either the DH POP Proof-of-Possession as defined in Section 4 of [DH-POP] or the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.¶

9. Requirements for RAs

RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control.¶

All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as covered in Section 3.2.3 of [CMC-STRUCT].¶

10. Requirements for CAs

Providing for CAs to work in an environment with RAs is strongly suggested. Implementation of such support is strongly suggested as this permits the delegation of substantial administrative interaction onto an RA rather than at the CA.¶

CAs MUST perform at least minimal checks on all public keys before issuing a certificate. At a minimum, a check for syntax would occur with the POP operation. Additionally, CAs SHOULD perform simple checks for known bad keys such as small subgroups for DSA-SHA1 and DH keys [SMALL-SUB-GROUP] or known bad exponents for RSA keys.¶

CAs MUST enforce POP checking before issuing any certificate. CAs MAY delegate the POP operation to an RA for those cases where:¶

1. a challenge/response message pair must be used,¶
2. an RA performs escrow of a key and checks for POP in that manner, or¶
3. an unusual algorithm is used and that validation is done at the RA.¶

CAs SHOULD implement both the DH-POP Proof-of-Possession as defined in Section 4 of [DH-POP] and the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.¶

11. Security Considerations

This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks. The security sections of those two documents are included by reference.¶

Knowledge of how an entity is expected to operate is vital in determining which sections of requirements are applicable to that entity. Care needs to be taken in determining which sections apply and fully implementing the necessary code.¶

Cryptographic algorithms have and will be broken or weakened. Implementers and users need to check that the cryptographic algorithms listed in this document make sense from a security level. The IETF from time to time may issue documents dealing with the current state of the art. Two examples of such documents are [SMALL-SUB-GROUP] and [HASH-ATTACKS].¶

12. IANA Considerations

This document has no IANA actions.¶

13. References

Acknowledgements

Obviously, the authors would like to thank Jim Schaad and Michael Myers for their work on [CMC-COMPv1].¶

Thank you to Mike Bishop, Mohamed Boucadair, and Erik Kline for reviewing the document and providing comments.¶

The Acknowledgments section from RFC 5274 follows:¶

The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document.¶

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.¶

Contributors

Authors' Addresses