Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMSNational Security Agencymjjenki@nsa.govNational Security Agencyllziegl@tycho.ncsc.mil
Security
Network Working GroupNSACNSANSScertificateenrollmentThis document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government.
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.
The profile is made publicly available here for use by developers and operators of these and any other system deployments.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see 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) 2020 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.
Table of Contents
. Introduction
. Terminology
. The Commercial National Security Algorithm Suite
. Requirements and Assumptions
. Client Requirements: Generating PKI Requests
. Tagged Certification Request
. Certificate Request Message
. RA Requirements
. RA Processing of Requests
. RA-Generated PKI Requests
. RA-Generated PKI Responses
. CA Requirements
. CA Processing of PKI Requests
. CA-Generated PKI Responses
. Client Requirements: Processing PKI Responses
. Shared-Secrets
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. Scenarios
. Initial Enrollment
. Rekey
Authors' Addresses
IntroductionThis document specifies a profile of the Certificate Management over CMS (CMC) protocol to comply with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite . The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems . It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
This document does not define any new cryptographic algorithm suites; instead, it defines a CNSA-compliant profile of CMC. CMC is defined in , , and and is updated by . This document profiles CMC to manage X.509 public key certificates in compliance with the CNSA Suite Certificate and Certificate Revocation List (CRL) profile . This document specifically focuses on defining CMC interactions for both the initial enrollment and rekey of CNSA Suite public key certificates between a client and a Certification Authority (CA). One or more Registration Authorities (RAs) may act as intermediaries between the client and the CA. This profile may be further tailored by specific communities to meet their needs. Specific communities will also define certificate policies that implementations need to comply with.
TerminologyThe 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.
The terminology in applies to this profile.The term "certificate request" is used to refer to a single PKCS #10
or Certificate Request Message Format (CRMF) structure. All PKI Requests are Full PKI Requests, and all PKI Responses are Full PKI Responses; the respective set of terms should be interpreted synonymously in this document.The Commercial National Security Algorithm SuiteThe National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems. To this end, it publishes guidance both to assist with the US Government transition to new algorithms and to provide vendors -- and the Internet community in general -- with information concerning their proper use and configuration within the scope of US Government National Security Systems.Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically relevant quantum
computer. The NSA has established the Commercial National Security
Algorithm (CNSA) Suite to provide vendors and IT users near-term
flexibility in meeting their cybersecurity interoperability
requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems.Requirements and AssumptionsElliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve
Diffie-Hellman (ECDH) key pairs are on the P-384 curve. FIPS 186-4 , Appendix B.4 provides useful guidance for elliptic curve key pair generation that SHOULD be followed by systems that conform to this document.RSA key pairs (public, private) are identified by the modulus size expressed in bits; RSA-3072 and RSA-4096 are computed using moduli of 3072 bits and 4096 bits, respectively.RSA signature key pairs used in CNSA Suite-compliant implementations are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy 216 < e < 2256 and be odd per .
It is recognized that, while the vast majority of RSA signatures are currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite-compliant X.509 certificates will be issued in accordance with , and while those certificates must be signed and validated using RSASSA-PKCS1-v1_5, the subject's private key can be used to generate signatures of either signing scheme. Where use of RSASSA-PSS is indicated in this document, the following parameters apply:
The hash algorithm MUST be id-sha384 as defined in ;
The mask generation function MUST use the algorithm identifier mfg1SHA384Identifier as defined in ;
The salt length MUST be 48 octets; and
The trailerField MUST have value 1.
These parameters will not appear in a certificate and MUST be securely
communicated with the signature, as required by . Application developers are obliged to ensure that the chosen signature scheme is appropriate for the application and will be interoperable within the intended operating scope of the application.This document assumes that the required trust anchors have been securely provisioned to the client and, when applicable, to any RAs.All requirements in , , , and apply, except where overridden by this profile.This profile was developed with the scenarios described in in mind. However, use of this profile is not limited to just those scenarios.The term "client" in this profile typically refers to an end-entity. However, it may instead refer to a third party acting on the end-entity's behalf. The client may or may not be the entity that actually generates the key pair, but it does perform the CMC protocol interactions with the RA and/or CA. For example, the client may be a token management system that communicates with a cryptographic token through an out-of-band secure protocol.This profile uses the term "rekey" in the same manner as CMC does (defined in ). The profile makes no specific statements about the ability to do "renewal" operations; however, the statements applicable to "rekey" should be applied to "renewal" as well.This profile may be used to manage RA and/or CA certificates. In that case, the RA and/or CA whose certificate is being managed is considered to be the end-entity.This profile does not discuss key establishment certification requests from cryptographic modules that cannot generate a one-time signature with a key establishment key for proof-of-possession purposes. In that case, a separate profile would be needed to define the use of another proof-of-possession technique.Client Requirements: Generating PKI RequestsThis section specifies the conventions employed when a client requests a certificate from a Public Key Infrastructure (PKI).
The Full PKI Request MUST be used; it MUST be encapsulated in a SignedData; and the SignedData MUST be constructed in accordance with . The PKIData content type defined in is used with the following additional requirements:
controlSequence SHOULD be present.
TransactionId and SenderNonce SHOULD be included. Other CMC controls MAY be included.
If the request is being authenticated using a shared-secret, then Identity Proof Version 2 control MUST be included with the following constraints:
hashAlgId MUST be id-sha384 for all certification requests (algorithm OIDs are defined in ).
macAlgId MUST be HMAC-SHA384 (the Hashed
Message Authentication Code (HMAC) algorithm is defined in ).
If the subject name included in the certification request is NULL
or otherwise does not uniquely identify the end-entity, then the
POP Link Random control MUST be included, and the
POP Link Witness Version 2 control MUST be included
in the inner PKCS #10 or
Certificate Request Message Format (CRMF) request as described in Sections and .
reqSequence MUST be present. It MUST include at least one tcr (see ) or crm (see ) TaggedRequest. Support for the orm choice is OPTIONAL.
The private signing key used to generate the encapsulating SignedData MUST correspond to the public key of an existing signature certificate unless an appropriate signature certificate does not yet exist, such as during initial enrollment.The encapsulating SignedData MUST be generated using SHA-384 and either ECDSA on P-384 or RSA using either RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.If an appropriate signature certificate does not yet exist and if a Full PKI Request includes one or more certification requests and is authenticated using a shared-secret (because no appropriate certificate exists yet to authenticate the request), the Full PKI Request MUST be signed using the private key corresponding to the public key of one of the requested certificates. When necessary (i.e., because there is no existing signature certificate and there is no signature certification request included), a Full PKI Request MAY be signed using a key pair intended for use in a key establishment certificate. However, servers are not required to allow this behavior.Tagged Certification RequestThe reqSequence tcr choice conveys PKCS #10 syntax. The CertificateRequest MUST
comply with , with the following additional requirements:
certificationRequestInfo:
subjectPublicKeyInfo MUST be set as defined in .
Attributes:
The ExtensionReq attribute MUST be included with its contents as follows:
The keyUsage extension MUST be included, and it MUST be set as defined in .
For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the subject field of the certificate being used to generate the signature is NULL.
Other extension requests MAY be included as desired.
The ChangeSubjectName attribute, as defined in , MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's subject field or SubjectAltName extension does not match the desired subject name or SubjectAltName extension of this certification request.
The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the subject name in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha384 for certification requests, as defined in ; macAlgorithm MUST be HMAC-SHA384, as defined in .
signatureAlgorithm MUST be ecdsa-with-sha384 for P-384 certification requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests.
signature MUST be generated using the private key corresponding to the public key in the CertificationRequestInfo for both signature and key establishment certification requests. The signature provides proof-of-possession of the private key to the CA.
Certificate Request MessageThe reqSequence crm choice conveys Certificate Request Message
Format (CRMF)
syntax. The CertReqMsg MUST comply with , with the following additional requirements:
popo MUST be included using the signature (POPOSigningKey)
proof-of-possession choice and be set as defined in for both signature and key establishment certification requests. The POPOSigningKey poposkInput field MUST be omitted. The POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha384 for P-384 certification requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests. The signature MUST be generated using the private key corresponding to the public key in the CertTemplate.
The CertTemplate MUST comply with , with the following additional requirements:
If version is included, it MUST be set to 2 as defined in
.
publicKey MUST be set as defined in .
Extensions:
The keyUsage extension MUST be included, and it MUST be set as defined in .
For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the subject name of the certificate being used to generate the signature is NULL.
Other extension requests MAY be included as desired.
Controls:
The ChangeSubjectName attribute, as defined in , MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's subject name or SubjectAltName extension does not match the desired subject name or SubjectAltName extension of this certification request.
The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the subject name in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha384 for certification requests; macAlgorithm MUST be HMAC-SHA384 when keyGenAlgorithm is id-sha384.
RA RequirementsThis section addresses the optional case where one or more RAs act as
intermediaries between clients and a CA as described in . In this section, the term "client" refers to the entity from which the RA received the PKI Request. This section is only applicable to RAs.RA Processing of RequestsRAs conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the RA MUST reject those requests. The RA SHOULD return a CMCFailInfo with the value of badAlg .When processing end-entity-generated SignedData objects, RAs MUST NOT perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension processing .Other RA processing is performed as described in .RA-Generated PKI RequestsRAs mediate the certificate request process by collecting client requests in batches. The RA MUST encapsulate client-generated PKI Requests in a new RA-signed PKI Request, it MUST create a Full PKI Request encapsulated in a SignedData, and the SignedData MUST be constructed in accordance with . The PKIData content type complies with with the following additional requirements:
controlSequence MUST be present. It
MUST include the following CMC controls: Transaction
ID, Sender Nonce, and Batch Requests. Other appropriate CMC controls
MAY be included.
cmsSequence MUST be present. It contains the original, unmodified request(s) received from the client.
SignedData (applied by the RA)
PKIData
controlSequence (Transaction ID, Sender Nonce,
Batch Requests)
cmsSequence
SignedData (applied by client)
PKIData
controlSequence (Transaction ID, Sender Nonce)
reqSequence
TaggedRequest
{TaggedRequest}
{SignedData (second client request)
PKIData...}
Authorization to sign RA-generated Full PKI Requests
SHOULD be indicated in the RA certificate by inclusion
of the id-kp-cmcRA Extended Key Usage (EKU) from . The RA certificate MAY also include
the CCC certificate extension , or it MAY indicate authorization
through inclusion of the CCC certificate extension alone. The RA
certificate may also be authorized through the local configuration.If the RA is authorized via the CCC extension, then the CCC extension MUST include the object identifier for the PKIData content type. CCC SHOULD be included if constraints are to be placed on the content types generated.The outer SignedData MUST be generated using SHA-384 and either ECDSA on P-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.
If the Full PKI Response is a successful response to a PKI Request that only contained a Get Certificate or Get CRL control, then the algorithm used in the response MUST match the algorithm used in the request.
RA-Generated PKI ResponsesIn order for an RA certificate using the CCC certificate extension to be authorized to generate responses, the object identifier for the PKIResponse content type must be present in the CCC certificate extension.CA RequirementsThis section specifies the requirements for CAs that receive PKI Requests and generate PKI Responses.CA Processing of PKI RequestsCAs conforming to this document MUST ensure that
only the permitted signature, hash, and MAC algorithms described
throughout this profile are used in requests; if they are not, the CA
MUST reject those requests. The CA
SHOULD return a CMCStatusInfoV2 control with a CMCStatus of failed and a CMCFailInfo with the value of badAlg .For requests involving an RA (i.e., batched requests), the CA
MUST verify the RA's authorization. The following
certificate fields MUST NOT be modifiable using the
Modify Certification Request control: publicKey and the keyUsage
extension. The request MUST be rejected if an attempt
to modify those certification request fields is present. The CA
SHOULD return a CMCStatusInfoV2 control with a CMCStatus of failed and a CMCFailInfo with a value of badRequest.When processing end-entity-generated SignedData objects, CAs MUST NOT perform CCC certificate extension processing .If a client-generated PKI Request includes the ChangeSubjectName
attribute as described in or
above, the CA MUST ensure that name change is
authorized. The mechanism for ensuring that the name change is
authorized is out of scope. A CA that performs this check and finds
that the name change is not authorized MUST reject the
PKI Request. The CA SHOULD return an Extended CMC
Status Info control (CMCStatusInfoV2) with a CMCStatus of failed.Other processing of PKIRequests is performed as described in .CA-Generated PKI ResponsesCAs send PKI Responses to both client-generated requests and RA-generated requests. If a Full PKI Response is returned in direct response to a client-generated request, it MUST be encapsulated in a SignedData, and the SignedData MUST be constructed in accordance with .If the PKI Response is in response to an RA-generated PKI Request, then the above PKI Response is encapsulated in another CA-generated PKI Response. That PKI Response MUST be encapsulated in a SignedData, and the SignedData MUST be constructed in accordance with . The above PKI Response is placed in the encapsulating PKI Response cmsSequence field. The other fields are as above with the addition of the batch response control in controlSequence. The following illustrates a successful CA response to an RA-encapsulated PKI Request, both of which include Transaction IDs and Nonces:
SignedData (applied by the CA)
PKIResponse
controlSequence (Transaction ID, Sender Nonce, Recipient
Nonce, Batch Response)
cmsSequence
SignedData (applied by CA and includes returned
certificates)
PKIResponse
controlSequence (Transaction ID, Sender Nonce,
Recipient Nonce)
The same private key used to sign certificates MUST NOT be used to sign Full PKI Response messages. Instead, a separate certificate indicating authorization to sign CMC responses MUST be used.Authorization to sign Full PKI Responses SHOULD be indicated in the CA certificate by inclusion of the id-kp-cmcCA EKU from . The CA certificate MAY also include the CCC certificate extension , or it MAY indicate authorization through inclusion of the CCC certificate extension alone. The CA certificate may also be authorized through local configuration.In order for a CA certificate using the CCC certificate extension to be authorized to generate responses, the object identifier for the PKIResponse content type must be present in the CCC certificate extension. CCC SHOULD be included if constraints are to be placed on the content types generated.Signatures applied to individual certificates are as required in .The signature on the SignedData of a successful response to a
client-generated request, or each individual inner SignedData on the
successful response to an RA-generated request, MUST be
generated using SHA-384 and either ECDSA on P-384 or RSA using
RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key. An
unsuccessful response MUST be signed using the same key
type and algorithm that signed the request.The outer SignedData on the Full PKI Response to any RA-generated
PKI Request MUST be signed with the same key type and algorithm that signed the request.The SignedData on a successful Full PKI Response to a PKI Request
that only contained a Get Certificate or Get CRL control
MUST be signed with the same key type and algorithm that signed the request.Client Requirements: Processing PKI ResponsesClients conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in responses; if they are not, the client MUST reject those responses.Clients MUST authenticate all Full PKI Responses. This includes verifying that the PKI Response is signed by an authorized CA or RA whose certificate validates back to a trust anchor. The authorized CA certificate MUST include the id-kp-cmcCA EKU and/or a CCC extension that includes the object identifier for the PKIResponse content type. Otherwise, the CA is determined to be authorized to sign responses through an implementation-specific mechanism. The PKI Response can be signed by an RA if it is an error message, if it is a response to a Get Certificate or Get CRL request, or if the PKI Response contains an inner PKI Response signed by a CA. In the last case, each layer of PKI Response MUST still contain an authorized, valid signature signed by an entity with a valid certificate that verifies back to an acceptable trust anchor. The authorized RA certificate MUST include the id-kp-cmcRA EKU and/or include a CCC extension that includes the object identifier for the PKIResponse content type. Otherwise, the RA is determined to be authorized to sign responses through local configuration.When a newly issued certificate is included in the PKI Response, the client MUST verify that the newly issued certificate's public key matches the public key that the client requested. The client MUST also ensure that the certificate's signature is valid and that the signature validates back to an acceptable trust anchor.Clients MUST reject PKI Responses that do not pass
these tests. Local policy will determine whether the client returns a
Full PKI Response with an Extended CMC Status Info control
(CMCStatusInfoV2) with the CMCStatus set to failed to a user console, error log, or the server.If the Full PKI Response contains an Extended CMC Status Info control with a CMCStatus set to failed, then local policy will determine whether the client resends a duplicate certification request back to the server or an error state is returned to a console or error log.Shared-SecretsWhen the Identity Proof V2 and POP Link Witness V2 controls are used, the shared-secret MUST be randomly generated and securely distributed. The shared-secret MUST provide at least 192 bits of strength.Security ConsiderationsProtocol security considerations are found in , , , , , , , and . When CCC is used to authorize RA and CA certificates, then the security considerations in also apply. Algorithm security considerations are found in .Compliant with NIST Special Publication 800-57 , this profile defines proof-of-possession of a key establishment private key by performing a digital signature. Except for one-time proof-of-possession, a single key pair MUST NOT be used for both signature and key establishment.This specification requires implementations to generate key pairs and other random values. The use of inadequate pseudorandom number generators (PRNGs) can result in little or no security. The generation of quality random numbers is difficult. NIST Special Publication 800-90A , FIPS 186-3 , and offer random number generation guidance.When RAs are used, the list of authorized RAs MUST be
securely distributed out of band to CAs.Presence of the POP Link Witness Version 2 and POP Link Random attributes protects against substitution attacks.The certificate policy for a particular environment will specify whether expired certificates can be used to sign certification requests.IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesUse of Public Standards for Secure Information SharingCommittee on National Security SystemsDigital Signature Standard (DSS)National Institute of Standards and TechnologyKey words for use in RFCs to Indicate Requirement LevelsIn 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.PKCS #10: Certification Request Syntax Specification Version 1.7This 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.Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]Randomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.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]Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]Certificate Management over CMS (CMC)This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]Certificate Management over CMS (CMC): Transport ProtocolsThis document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]Certificate Management Messages over CMS (CMC): Compliance RequirementsThis 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]Using SHA2 Algorithms with Cryptographic Message SyntaxThis 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]Cryptographic Message Syntax (CMS) Content Constraints ExtensionThis document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. [STANDARDS-TRACK]Certificate Management over CMS (CMC) UpdatesThis 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]PKCS #1: RSA Cryptography Specifications Version 2.2This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.This document also obsoletes RFC 3447.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) ProfileThis document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail ExtensionsThe United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.Informative ReferencesRecommendation for Key Management, Part 1: GeneralNational Institute of Standards and TechnologyGuideline for Identifying an Information System as a National Security SystemNational Institute of Standards and TechnologyRecommendation for Random Number Generation Using Deterministic Random Bit GeneratorsNational Institute of Standards and TechnologyScenariosThis section illustrates several potential certificate enrollment and rekey scenarios supported by this profile. This section does not intend to place any limits or restrictions on the use of CMC.Initial EnrollmentThis section describes three scenarios for authenticating initial enrollment requests:
Previously Certified Signature Key-PairIn this scenario, the end-entity has a private signing key and a corresponding public key certificate obtained from a cryptographic module manufacturer recognized by the CA. The end-entity signs a Full PKI Request with the private key that corresponds to the subject public key of the previously installed signature certificate. The CA will verify the authorization of the previously installed certificate and issue an appropriate new certificate to the end-entity.Shared-Secret Distributed Securely Out of BandIn this scenario, the CA distributes a shared-secret out of band
to the end-entity that the end-entity uses to authenticate its
certification request. The end-entity signs the Full PKI Request
with the private key for which the certification is being
requested. The end-entity includes the Identity Proof Version 2
control to authenticate the request using the shared-secret. The CA
uses either the Identification control or the subject name in the
end-entity's enclosed PKCS #10 or CRMF
certification request message to identify the request. The
end-entity performs either the POP Link Witness Version 2 mechanism
as described in or the shared-secret/subject distinguished
name linking mechanism as described in . The subject name in the
enclosed PKCS #10 or CRMF certification
request does not necessarily match the issued certificate, as it may
be used just to help identify the request (and the corresponding shared-secret) to the CA.RA AuthenticationIn this scenario, the end-entity does not automatically
authenticate its enrollment request to the CA, either because the
end-entity has nothing to authenticate the request with or because
the organizational policy requires an RA's involvement. The end-entity
creates a Full PKI Request and sends it to an RA. The RA verifies
the authenticity of the request. If the request is approved, the RA encapsulates and
signs the request as described in ,
forwarding the new request on to the CA. The subject name in the PKCS
#10 or CRMF certification request is not required to match the issued certificate; it may be used just to help identify the request to the RA and/or CA.RekeyThere are two scenarios to support the rekey of certificates that
are already enrolled. One addresses the rekey of signature
certificates, and the other addresses the rekey of key establishment
certificates. Typically, organizational policy will require certificates to be currently valid to be rekeyed, and it may require initial enrollment to be repeated when rekey is not possible. However, some organizational policies might allow a grace period during which an expired certificate could be used to rekey.Rekey of Signature CertificatesWhen a signature certificate is rekeyed, the PKCS #10 or CRMF certification request message enclosed in the Full PKI Request will include the same subject name as the current signature certificate. The Full PKI Request will be signed by the current private key corresponding to the current signature certificate.Rekey of Key Establishment CertificatesWhen a key establishment certificate is rekeyed, the Full PKI Request will generally be signed by the current private key corresponding to the current signature certificate. If there is no current signature certificate, one of the initial enrollment options in may be used.
Authors' AddressesNational Security Agencymjjenki@nsa.govNational Security Agencyllziegl@tycho.ncsc.mil