Certificate Management Messages over CMS (CMC): Compliance Requirements
The checklist of what a certificate-enrollment client, registration authority or CA must support to count as compliant CMC.
Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, DOI 10.17487/RFC5274, June 2008, <https://www.rfc-editor.org/info/rfc5274>.
@misc{rfc5274,
series = {Request for Comments},
number = 5274,
howpublished = {RFC 5274},
publisher = {RFC Editor},
doi = {10.17487/RFC5274},
url = {https://www.rfc-editor.org/info/rfc5274},
author = {J. Schaad and M. Myers},
title = {{Certificate Management Messages over CMS (CMC): Compliance Requirements}},
pagetotal = 13,
year = 2008,
month = jun,
} RFC text
Contents
Network Working Group J. Schaad
Request for Comments: 5274 Soaring Hawk Consulting
Category: Standards Track M. Myers
TraceRoute Security, Inc.
June 2008
Certificate Management Messages over CMS (CMC): Compliance Requirements
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.
Abstract
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.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
4. Requirements for All Entities . . . . . . . . . . . . . . . . 3
4.1. Cryptographic Algorithm Requirements . . . . . . . . . . . 4
4.2. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. CRMF Feature Requirements . . . . . . . . . . . . . . . . 8
4.4. Requirements for Clients . . . . . . . . . . . . . . . . . 8
5. Requirements for Servers . . . . . . . . . . . . . . . . . . . 8
6. Requirements for EEs . . . . . . . . . . . . . . . . . . . . . 8
7. Requirements for RAs . . . . . . . . . . . . . . . . . . . . . 8
8. Requirements for CAs . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Overview
The CMC (Certificate Management over CMS) 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 agents, 2) all servers, 3) all clients, 4)
all End-Entities, 5) all Registration Entities, 6) all Certificate
Authorities.
2. 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 End-Entity and the Certification
Authority. 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 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
[PKCS10], which defines a certification request syntax.
CRMF refers to the Certificate Request Message Format RFC [CRMF].
CMC uses this certification request syntax defined in this
document as part of the protocol.
CMS refers to the Cryptographic Message Syntax RFC [CMS]. 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 end-entity.
Transport wrapper refers to the outermost CMS wrapping layer.
3. Requirements Terminology
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 [MUST].
4. 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.
4.1. Cryptographic Algorithm Requirements
All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in
SignedData (see [CMS-ALG]). Entities MAY verify other signature
algorithms. It is strongly suggested that RSA-PSS with SHA-1 be
verified (see [CMS-RSA-PSS]). It is strongly suggested that SHA-256
using RSA and RSA-PSS be verified (see [RSA-256]).
All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for
SignedData (see [CMS-ALG]). Other signatures algorithms MAY be used
for generation.
All entities MUST support Advanced Encryption Standard (AES) as the
content encryption algorithm for EnvelopedData (see [CMS-AES]).
Other content encryption algorithms MAY be implemented.
All entities MUST support RSA as a key transport algorithm for
EnvelopedData (see [CMS-ALG]). All entities SHOULD support RSA-OAEP
(see [CMS-RSA-OAEP]) as a key transport algorithm. Other key
transport algorithms MAY be implemented.
If an entity supports key agreement for EnvelopedData, it MUST
support Diffie-Hellman (see [CMS-DH]).
If an entity supports PasswordRecipientInfo for EnvelopedData or
AuthenticatedData, it MUST support PBKDF2 [PBKDF2] for key derivation
algorithms. It MUST support AES key wrap (see [AES-WRAP] as the key
encryption algorithm.
If AuthenticatedData is supported, PasswordRecipientInfo MUST be
supported.
Algorithm requirements for the Identity Proof Version 2 control
(Section 6.2.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for
hashAlgId. SHA-256 SHOULD be implemented for hashAlgId. HMAC-SHA1
MUST be implemented for macAlgId. HMAC-SHA256 SHOULD be implemented
for macAlgId.
Algorithm requirements for the Pop Link Witness Version 2 control
(Section 6.3.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for
keyGenAlgorithm. SHA-256 SHOULD be implemented for keyGenAlgorithm.
PBKDF2 [PBKDF2] MAY be implemented for keyGenAlgorithm. HMAC-SHA1
MUST be implemented for macAlgorithm. HMAC-SHA256 SHOULD be
implemented for macAlgorithm.
Algorithm requirements for the Encrypted POP and Decrypted POP
controls (Section 6.7 of [CMC-STRUCT]) are: SHA-1 MUST be implemented
for witnessAlgID. SHA-256 SHOULD be implemented for witnessAlgID.
HMAC-SHA1 MUST be implemented for thePOPAlgID. HMAC-SHA256 SHOULD be
implemented for thePOPAlgID.
Algorithm requirements for Publish Trust Anchors control (Section
6.15 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for
hashAlgorithm. SHA-256 SHOULD be implemented for hashAlgorithm.
If an EE generates DH keys for certification, it MUST support section
4 of [DH-POP]. EEs MAY support Section 3 of [DH-POP]. CAs and RAs
that do POP verification MUST support Section 4 of [DH-POP] and
SHOULD support Section 3 of [DH-POP].
EEs that need to use a signature algorithm for keys that cannot
produce a signature MUST support Appendix C of [CMC-STRUCT] 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.
4.2. Controls
The following table lists the name and level of support required for
each control.
+----------------------------+----------+----------+----------+
| 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) |
| | | | |
| Authenticate 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) |
+----------------------------+----------+----------+----------+
Table 1: CMC Control Attributes
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.
Strong consideration should be given to implementing the Authenticate
Data and Publish Trust Anchors controls as this gives a simple method
for distributing trust anchors into clients without user
intervention.
4.3. 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 controls identification
and identityProof will perform the same service and are more
specifically defined.
The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be
supported. An alternative method is under development to provide
this functionality.
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.
4.4. Requirements for Clients
There are no additional requirements.
5. Requirements for Servers
There are no additional requirements.
6. Requirements for EEs
If an entity implements Diffie-Hellman, it MUST implement either the
DH-POP Proof-of-Possession as defined in [DH-POP], Section 4, or the
challenge-response POP controls id-cmc-encryptedPOP and id-cmc-
decryptedPOP.
7. 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].
8. 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 [DH-POP], Section 4, and the challenge-response POP controls id-
cmc-encryptedPOP and id-cmc-decryptedPOP.
9. Security Considerations
This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to
this document. 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].
10. Acknowledgements
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.
11. References
11.1. Normative References
[CMC-STRUCT] Schaad, J. and M. Myers, "Certificate Management
over CMS (CMC)", RFC 5272, June 2008.
[CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management
over CMS (CMC): Transport Protocols", RFC 5273,
June 2008.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[CMS-AES] Schaad, J., "Use of the Advanced Encryption
Standard (AES) Encryption Algorithm in
Cryptographic Message Syntax (CMS)", RFC 3565,
July 2003.
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement
Method", RFC 2631, June 1999.
[CRMF] Schaad, J., "Internet X.509 Public Key
Infrastructure Certificate Request Message Format
(CRMF)", RFC 4211, September 2005.
[CMS-RSA-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport
Algorithm in the Cryptographic Message Syntax
(CMS)", RFC 3560, July 2003.
[CMS-RSA-PSS] Schaad, J., "Use of the RSASSA-PSS Signature
Algorithm in Cryptographic Message Syntax (CMS)",
RFC 4056, June 2005.
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman
Proof-of-Possession Algorithms", RFC 2875,
June 2000.
[MUST] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, BCP 14,
March 1997.
[RSA-256] Schaad, J., Kaliski, B., and R. Housley,
"Additional Algorithms and Identifiers for RSA
Cryptography for use in the Internet X.509 Public
Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055,
June 2005.
[PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
September 2000.
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption
Standard (AES) Key Wrap Algorithm", RFC 3394,
September 2002.
11.2. Informative References
[PKCS10] Nystrom, M. and B. Kaliski, "PKCS #10:
Certification Request Syntax Specification v1.7",
RFC 2986, November 2000.
[SMALL-SUB-GROUP] Zuccherato, R., "Methods for Avoiding the "Small-
Subgroup" Attacks on the Diffie-Hellman Key
Agreement Method for S/MIME", RFC 2785,
March 2000.
[HASH-ATTACKS] Hoffman, P. and B. Schneier, "Attacks on
Cryptographic Hashes in Internet Protocols",
RFC 4270, November 2005.
Authors' Addresses
Jim Schaad
Soaring Hawk Consulting
PO Box 675
Gold Bar, WA 98251
Phone: (425) 785-1031
EMail: jimsch@nwlink.com
Michael Myers
TraceRoute Security, Inc.
EMail: mmyers@fastq.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
ISO Plain Language
On this page
§1The CMC Chain of Client and Server
The CMC protocol, Certificate Management over CMS, is designed in terms of a client and server relationship. In the simplest case the client is the requestor of the certificate, that is the End Entity, and the server is the issuer of the certificate, that is the Certification Authority.
The introduction of a Registration Authority 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. All certificate requests for encryption keys would be directed through such an RA, and it would take appropriate action to do the key archival. Key recovery requests could be defined in the CMC methodology, allowing the key escrow agent to perform that operation while 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.
Normally the program holding the key asks the authority that signs certificates. A registration authority can sit in between, so the requester talks to the RA and the RA talks to the CA.
§2The Roles and the Vocabulary
The RFC defines the terms it uses. The End-Entity is the entity that owns a key pair and for whom a certificate is issued. The Registration Authority, or local RA, is an entity that acts as an intermediary between the End-Entity and the CA. Multiple RAs can exist between the End-Entity and the Certification Authority, and RAs may perform additional services such as key generation or key archival. The Certification Authority is the entity that issues certificates.
A Client is an entity that creates a PKI Request, and in this document both RAs and EEs can be clients. A Server is an entity that processes PKI Requests and creates PKI Responses, and both CAs and RAs can be servers. A PKI Request includes certification requests and revocation requests; a PKI Response includes certs-only messages and failure messages.
Two security terms matter for the requirements that follow. Proof-of-Identity refers to the client proving they are who they say they are to the server. Proof-of-Possession refers to a value that can be used to prove that the private key corresponding to a public key is in the possession of, and can be used by, the end-entity. The RFC also names PKCS #10, the certification request syntax, CRMF, the Certificate Request Message Format, CMS, the Cryptographic Message Syntax, and the transport wrapper, the outermost CMS wrapping layer.
Two different proofs are used. One shows who the requester is; the other shows the requester really holds the private key the certificate will be issued for.
- End-Entity (EE)Owns the key pair and is the one the certificate is issued for.
- Registration Authority (RA)Sits between the End-Entity and the CA, acting as server to the former and client to the latter.
- Certification Authority (CA)Issues the certificates and enforces proof of possession before it does.
§4Requirements for All Entities
Unless specifically stated otherwise, all of the compliance statements in the CMC structures and transport documents must be adhered to.
All entities must support Full PKI Requests, Simple PKI Responses and Full PKI Responses, while servers should support Simple PKI Requests. All entities must support the CRMF syntax for certification requests, and 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, and if extendedFailInfo 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, while other transport mechanisms may be implemented.
The baseline is the same for everyone: handle the full request and response formats, use the CRMF request syntax, and speak over HTTP.
§4.1Cryptographic Algorithm Requirements
The RFC then fixes the algorithms. All entities must verify DSA-SHA1 and RSA-SHA1 signatures in SignedData, and may verify other signature algorithms. It is strongly suggested that RSA-PSS with SHA-1 be verified, and strongly suggested that SHA-256 using RSA and RSA-PSS be verified. All entities must generate either DSA-SHA1 or RSA-SHA1 signatures for SignedData, while other signature algorithms may be used for generation.
All entities must support the Advanced Encryption Standard as the content encryption algorithm for EnvelopedData, and must support RSA as a key transport algorithm for EnvelopedData; they should support RSA-OAEP. If an entity supports key agreement for EnvelopedData, it must support Diffie-Hellman. If it supports PasswordRecipientInfo for EnvelopedData or AuthenticatedData, it must support PBKDF2 for key derivation algorithms and must support AES key wrap as the key encryption algorithm. If AuthenticatedData is supported, PasswordRecipientInfo must be supported.
Per-control requirements follow the same pattern. For the Identity Proof Version 2 control, SHA-1 must be implemented for the hash algorithm and SHA-256 should be implemented; HMAC-SHA1 must be implemented for the message authentication code algorithm and HMAC-SHA256 should be implemented. The Pop Link Witness Version 2 control has the same shape, plus PBKDF2 as an optional key generation algorithm. The Encrypted POP and Decrypted POP controls require SHA-1 for the witness algorithm and HMAC-SHA1 for the POP algorithm, with SHA-256 and HMAC-SHA256 recommended. The Publish Trust Anchors control requires SHA-1 for its hash algorithm, with SHA-256 recommended.
The algorithms are pinned so that one vendor's client can always read another's message. Older algorithms are mandatory for reading, newer ones are recommended for writing.
§4.2The Table of Required Controls
The controls are the tagged pieces of information carried inside a CMC message, and the RFC gives a table of the required level of support for each one, per role. Extended CMC Status Info and the Identity Proof Version 2, Identification, POP Link Random and POP Link Witness Version 2 controls are MUST for the End-Entity, the RA and the CA alike, as are Data Return, Transaction ID, Sender Nonce, Recipient Nonce, Query Pending and Confirm Certificate Acceptance.
The requirements differ where the roles differ. The Modify Cert Request control does not apply to an End-Entity and is MUST for an RA; the RA POP Witness control does not apply to an End-Entity and is SHOULD for an RA; Revocation Request is SHOULD for an End-Entity and an RA but MUST for a CA. Get Certificate, Get CRL and Publication Information are optional for all three roles. The notes to the table qualify several entries: CAs should implement a control if designed to work with RAs, and must implement it if designed to work with RAs; implementation of Publish Trust Anchors and Authenticate Data is optional, but strongly suggested, because they give a simple way to distribute trust anchors into clients without user intervention; and the Encrypted and Decrypted POP controls are needed by an End-Entity only if it supports key agreement algorithms or needs to operate where the hardware keys cannot provide proof of possession.
Further requirements narrow the CRMF features that may be used. The id-regCtrl-regToken and id-regCtrl-authToken tokens must not be used, since the CMC controls identification and identityProof perform the same service and are more specifically defined. The id-regCtrl-pkiArchiveOptions token should not be supported, because an alternative method is under development. The behaviour of id-regCtrl-oldCertID is not presently used; it is replaced by issuing the new certificate and using the id-cmc-publishCert control to remove the old certificate from publication. The id-regCtrl-protocolEncrKey token is not used.
Each control is a labelled chunk of information in the message. The table says which ones each role has to send or understand, and it differs for the three roles in a few places.
| Control | End-Entity | Registration Authority | CA |
|---|---|---|---|
| Identity Proof Version 2 | MUST | MUST | MUST |
| Identification | MUST | MUST | MUST |
| POP Link Random | MUST | MUST | MUST |
| Revocation Request THIS RFC | SHOULD | SHOULD | MUST |
| Query Pending | MUST | MUST | MUST |
| Get Certificate | optional | optional | optional |
§9Security Considerations
The RFC uses the CMC structures and transport documents as building blocks, and includes their security sections by reference. It then adds its own point: knowledge of how an entity is expected to operate is vital in determining which sections of requirements are applicable to that entity, and care needs to be taken in determining which sections apply and fully implementing the necessary code.
The final paragraph is a warning about the algorithm list itself. 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 may from time to time issue documents dealing with the current state of the art, and the RFC names two examples, on small subgroups and on hash attacks.
Getting the rules right for your own role is part of the security, and the algorithm list itself ages: check it against the current guidance.