Certificate Management Messages over CMS (CMC): Compliance Requirements
updated by
- rfc-6402 — Certificate Management over CMS (CMC) Updates
Extracted elements (27)
Providing for CAs to work in an environment with RAs is strongly suggested, as this permits the delegation of substantial administrative interaction onto an RA rather than at the CA.
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.
The id-regCtrl-oldCertID CRMF token is replaced in CMC by issuing the new certificate and using id-cmc-publishCert to remove the old certificate from publication, optionally accompanied by id-cmc-revokeRequest for immediate revocation.
All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be adhered to unless specifically stated otherwise in this document, making RFC 5274 a compliance overlay on those foundational specifications.
All entities MUST implement the HTTP transport mechanism as defined in [CMC-TRANS]. Other transport mechanisms MAY be implemented.
All entities MUST support AES as the content encryption algorithm for EnvelopedData. All entities MUST support RSA as a key transport algorithm for EnvelopedData, and SHOULD support RSA-OAEP.
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.
All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in SignedData. All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for SignedData.
All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as covered in Section 3.2.3 of [CMC-STRUCT].
CAs MUST enforce POP checking before issuing any certificate. CAs MAY delegate the POP operation to an RA for challenge/response pairs, key escrow scenarios, or unusual algorithms.
CAs MUST perform at least minimal checks on all public keys before issuing a certificate, including a syntax check via the POP operation. CAs SHOULD perform simple checks for known bad keys such as small subgroups for DSA-SHA1/DH keys or known bad exponents for RSA keys.
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.
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 these as well.
For the Encrypted POP and Decrypted POP controls, SHA-1 MUST be implemented for witnessAlgID and HMAC-SHA1 MUST be implemented for thePOPAlgID. SHA-256 SHOULD be implemented for both.
For the Identity Proof Version 2 control, SHA-1 MUST be implemented for hashAlgId and HMAC-SHA1 MUST be implemented for macAlgId. SHA-256 SHOULD be implemented for both.
For the Pop Link Witness Version 2 control, SHA-1 MUST be implemented for keyGenAlgorithm and HMAC-SHA1 MUST be implemented for macAlgorithm. SHA-256 SHOULD be implemented for both.
If an EE 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.
If an entity supports key agreement for EnvelopedData, it MUST support Diffie-Hellman. If an entity supports PasswordRecipientInfo, it MUST support PBKDF2 for key derivation and MUST support AES key wrap as the key encryption algorithm.
If AuthenticatedData is supported, PasswordRecipientInfo MUST be supported.
RAs SHOULD be able to do delegated POP. RAs implementing this feature MUST implement the id-cmc-lraPOPWitness control.
The CRMF control token id-regCtrl-pkiArchiveOptions SHOULD NOT be supported; an alternative method is under development.
The CRMF registration control tokens id-regCtrl-regToken and id-regCtrl-authToken MUST NOT be used in CMC; the CMC controls identification and identityProof perform the same service.
The extendedFailInfo field SHOULD NOT be populated in the CMCStatusInfoV2 object; the failInfo field SHOULD be used to relay this information.
Table 1 defines the CMC control attributes and required support levels (MUST/SHOULD/MAY/N/A) for each of EE, RA, and CA roles. Key MUST controls for all three roles include: Extended CMC Status Info, Identity Proof V2, Identification, POP Link Random, POP Link Witness V2, Data Return, Transaction ID, Sender Nonce, Recipient Nonce, Query Pending, and Confirm Cert Acceptance.
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, and should refer to IETF documents on the current state of the art such as those on small-subgroup attacks and hash attacks.
Knowledge of how an entity is expected to operate is vital in determining which sections of requirements are applicable; care must be taken to determine which sections apply and fully implement the necessary code. The security considerations of [CMC-STRUCT] and [CMC-TRANS] are incorporated by reference.