Certificate Management over CMS (CMC): Compliance Requirements AKAYLA, Inc.
joe@akayla.com
sn3rd
sean@sn3rd.com
SEC lamps Public Key Infrastructure Cryptographic Message Syntax Certificate Management Compliance This document provides a set of compliance statements about the Certificate Management over CMS (CMC) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents (RFCs 10002 and 10003). This document provides the information needed to make a compliant version of CMC. This document obsoletes RFCs 5274 and 6402.
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 .
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 () 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.
Table of Contents
  • .  Introduction
  • .  Terminology
  • .  Requirements Terminology
  • .  Changes Since RFCs 5274 and 6402
  • .  Requirements for All Entities
    • .  Cryptographic Algorithm Requirements
    • .  Controls
    • .  CRMF Feature Requirements
  • .  Requirements for Clients
  • .  Requirements for Servers
  • .  Requirements for EEs
  • .  Requirements for RAs
  • . Requirements for CAs
  • . Security Considerations
  • . IANA Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Contributors
  • Authors' Addresses
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 and 6402 .
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.
Registration Authority (RA) or Local RA (LRA):
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.
Certification Authority (CA):
Refers to the entity that issues certificates.
Client:
Refers to an entity that creates a Public Key Infrastructure (PKI) Request. In this document, both RAs and EEs can be clients.
Server:
Refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers.
PKCS #10:
Refers to the Public Key Cryptography Standard #10 , which defines a certification request syntax.
CRMF:
Refers to the Certificate Request Message Format . CMC uses this certification request syntax defined in this document as part of the protocol.
CMS:
Refers to the Cryptographic Message Syntax . This document provides for basic cryptographic services including encryption and signing with and without key management.
PKI Request/Response:
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.
Proof-of-Identity:
Refers to the client proving they are who they say that they are to the server.
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 EE. See .
Transport wrapper:
Refers to the outermost CMS wrapping layer.
Entity:
Refers to EE, RA (or LRA), or CA.
HMAC:
Refers to the Hashed Message Authentication Code. CMC uses the ASN.1 module defined in .
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 when, and only when, they appear in all capitals, as shown here.
Changes Since RFCs 5274 and 6402 Merged 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 . 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.
Requirements for All Entities All and 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 . Other transport mechanisms MAY be implemented.
Cryptographic Algorithm Requirements All entities MUST verify RSA-SHA256 signatures in SignedData; (see ). Entities MAY verify other signature algorithms. All entities MUST generate RSA-SHA256 signatures for SignedData; (see ). Other signature algorithms MAY be used for generation. All entities MUST support Advanced Encryption Standard (AES) as the content encryption algorithm for EnvelopedData; (see ). Other content encryption algorithms MAY be implemented. All entities MUST support AES-GCM (Galois/Counter Mode) as the authenticated content encryption algorithm for AuthEnvelopedData; (see ). They MUST also support a 12-octet nonce size and a 12-octet Integrity Check Value (ICV) length. Other content encryption algorithms MAY be implemented. All entities MUST support RSA as a key transport algorithm for EnvelopedData and AuthEnvelopedData; see . Other key transport algorithms MAY be implemented. If an entity supports key agreement for EnvelopedData or AuthEnvelopedData, it MUST support Diffie-Hellman (DH); (see ). If an entity supports PasswordRecipientInfo for EnvelopedData, AuthenticatedData, or AuthEnvelopedData, it MUST support Password-Based Key Derivation Function 2 (PBKDF2) for key derivation algorithms. It MUST support AES key wrap (see ) as the key encryption algorithm. If AuthenticatedData is supported, PasswordRecipientInfo MUST be supported. Algorithm requirements for the Identity Proof Version 2 control () are as follows:
  • SHA-256 MUST be implemented for hashAlgId.
  • HMAC-SHA256 MUST be implemented for macAlgId.
Algorithm requirements for the Pop Link Witness Version 2 control () are as follows:
  • SHA-256 MUST be implemented for keyGenAlgorithm.
  • PBKDF2 MAY be implemented for keyGenAlgorithm.
  • HMAC-SHA256 MUST be implemented for macAlgorithm.
Algorithm requirements for the Encrypted POP and Decrypted POP controls () are as follows:
  • SHA-256 MUST be implemented for witnessAlgID.
  • HMAC-SHA256 MUST be implemented for thePOPAlgID.
Algorithm requirements for Publish Trust Anchors control () are as follows:
  • SHA-256 MUST be implemented for hashAlgorithm.
If an EE generates DH keys for certification, it MUST support . EEs MAY support . CAs and RAs that do POP verification MUST support and SHOULD support . EEs that need to use a signature algorithm for keys that cannot produce a signature MUST support and MUST support the Encrypted/Decrypted POP controls. CAs and RAs that do POP verification MUST support this signature algorithm and MUST support the Encrypted/Decrypted POP controls. For backward compatibility with the previous version of CMC, servers MAY offer the algorithms specified therein, but SHOULD use the CMC requests to identify which certificates should be transitioned to more secure algorithms, if possible.
Controls The following table lists the name and level of support required for each control. CMC Control Attributes
Control EE RA CA
Extended CMC Status Info MUST MUST MUST
CMC Status Info SHOULD SHOULD SHOULD
Identity Proof Version 2 MUST MUST MUST
Identity Proof SHOULD SHOULD SHOULD
Identification MUST MUST MUST
POP Link Random MUST MUST MUST
POP Link Witness Version 2 MUST MUST MUST
POP Link Witness SHOULD MUST MUST
Data Return MUST MUST MUST
Modify Cert Request N/A MUST (2)
Add Extensions N/A MAY (1)
Transaction ID MUST MUST MUST
Sender Nonce MUST MUST MUST
Recipient Nonce MUST MUST MUST
Encrypted POP (4) (5) SHOULD
Decrypted POP (4) (5) SHOULD
RA POP Witness N/A SHOULD (1)
Get Certificate OPTIONAL OPTIONAL OPTIONAL
Get CRL OPTIONAL OPTIONAL OPTIONAL
Revocation Request SHOULD SHOULD MUST
Registration Info SHOULD SHOULD SHOULD
Response Information SHOULD SHOULD SHOULD
Query Pending MUST MUST MUST
Confirm Cert. Acceptance MUST MUST MUST
Publish Trust Anchors (3) (3) (3)
Authenticated Data (3) (3) (3)
Batch Request N/A MUST (2)
Batch Responses N/A MUST (2)
Publication Information OPTIONAL OPTIONAL OPTIONAL
Control Processed N/A MUST (2)
RA Identity Proof Witness N/A MUST (2)
Response Body (6) (6) N/A
Notes:
  1. CAs SHOULD implement this control if designed to work with RAs.
  2. CAs MUST implement this control if designed to work with RAs.
  3. Implementation is OPTIONAL for these controls. We strongly suggest that they be implemented in order to populate client trust anchors.
  4. EEs only need to implement this if (a) they support key agreement algorithms or (b) they need to operate in environments where the hardware keys cannot provide POP.
  5. RAs SHOULD implement this if they implement RA POP Witness.
  6. EEs SHOULD implement this if designed to work with RAs and MUST implement if intended to be used in environments where RAs are used for identity validation or key generation. RAs SHOULD implement and validate responses for consistency.
Strong consideration should be given to implementing the Authenticated Data and Publish Trust Anchors controls as this gives a simple method for distributing trust anchors to clients without user intervention.
CRMF Feature Requirements The following additional restrictions are placed on CRMF features:
  • The registration control tokens id-regCtrl-regToken and id-regCtrl-authToken MUST NOT be used. No specific CMC feature is used to replace these items, but generally the CMC control's identification and identityProof will perform the same service and are more specifically defined.
  • The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be supported. See and for alternative methods.
  • The behavior of id-regCtrl-oldCertID is not presently used. It is replaced by issuing the new certificate and using the id-cmc-publishCert to remove the old certificate from publication. This operation would not normally be accompanied by an immediate revocation of the old certificate; however, that can be accomplished by the id-cmc-revokeRequest control.
  • The id-regCtrl-protocolEncrKey is not used.
Requirements for Clients There are no additional requirements.
Requirements for Servers There are no additional requirements.
Requirements for EEs If an EE implements Diffie-Hellman, it MUST implement either the DH POP Proof-of-Possession as defined in or the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
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 .
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 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 and the challenge-response POP controls id-cmc-encryptedPOP and id-cmc-decryptedPOP.
Security Considerations This document uses and 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 and .
IANA Considerations This document has no IANA actions.
References Normative References Advanced Encryption Standard (AES) Key Wrap Algorithm The purpose of this document is to make the AES Key Wrap algorithm conveniently available to the Internet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES Key Wrap posted by NIST. Certificate Management over CMS (CMC) AKAYLA, Inc. sn3rd Certificate Management over CMS (CMC): Transport Protocols AKAYLA, Inc. sn3rd Cryptographic Message Syntax (CMS) This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK] Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK] Using SHA2 Algorithms with Cryptographic Message Syntax This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK] Diffie-Hellman Key Agreement Method This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK] Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] Diffie-Hellman Proof-of-Possession Algorithms This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm. This document obsoletes RFC 2875. Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax This document specifies additions and amendments to RFCs 7292 and 8018. It also obsoletes the RFC 9579. It defines a way to use the Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Certificate Management Messages over CMS (CMC): Compliance Requirements This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. [STANDARDS-TRACK] Certificate Management over CMS (CMC) Updates This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274. The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK] Attacks on Cryptographic Hashes in Internet Protocols Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. This memo provides information for the Internet community. PKCS #10: Certification Request Syntax Specification Version 1.7 This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community.
Acknowledgements Obviously, the authors would like to thank and for their work on . Thank you to , , and 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 and in helping to author the original versions of this document. The authors would like to thank for his work in developing and writing up many of the concepts presented in this document. The authors would also like to thank and for their contributions.
Contributors August Cellars
TraceRoute Security, Inc.
Authors' Addresses AKAYLA, Inc.
joe@akayla.com
sn3rd
sean@sn3rd.com