< draft-jenkins-cnsa-cmc-profile-04.txt   draft-jenkins-cnsa-cmc-profile-05.txt >
Network Working Group M. Jenkins Network Working Group M. Jenkins
Internet-Draft L. Zieglar Internet-Draft L. Zieglar
Intended status: Informational NSA Intended status: Informational NSA
Expires: November 14, 2019 May 13, 2019 Expires: November 30, 2019 May 29, 2019
Commercial National Security Algorithm (CNSA) Suite Profile of Commercial National Security Algorithm (CNSA) Suite Profile of
Certificate Management over CMS Certificate Management over CMS
draft-jenkins-cnsa-cmc-profile-04 draft-jenkins-cnsa-cmc-profile-05
Abstract Abstract
This document specifies a profile of the Certificate Management over This document specifies a profile of the Certificate Management over
CMS (CMC) protocol for managing X.509 public key certificates in CMS (CMC) protocol for managing X.509 public key certificates in
applications that use the Commercial National Security Algorithm applications that use the Commercial National Security Algorithm
(CNSA) Suite published by the United States Government. (CNSA) Suite published by the United States Government.
The profile applies to the capabilities, configuration, and operation The profile applies to the capabilities, configuration, and operation
of all components of US National Security Systems that manage X.509 of all components of US National Security Systems that manage X.509
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 14, 2019. This Internet-Draft will expire on November 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Commercial National Security Algorithm Suite . . . . . . 3 2. The Commercial National Security Algorithm Suite . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements and Assumptions . . . . . . . . . . . . . . . . 4 4. Requirements and Assumptions . . . . . . . . . . . . . . . . 4
5. Client Requirements: Generating PKI Requests . . . . . . . . 5 5. Client Requirements: Generating PKI Requests . . . . . . . . 5
5.1. Tagged Certification Request . . . . . . . . . . . . . . 6 5.1. Tagged Certification Request . . . . . . . . . . . . . . 7
5.2. Certificate Request Message . . . . . . . . . . . . . . . 8 5.2. Certificate Request Message . . . . . . . . . . . . . . . 8
6. RA Requirements . . . . . . . . . . . . . . . . . . . . . . . 9 6. RA Requirements . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. RA Processing of Requests . . . . . . . . . . . . . . . . 9 6.1. RA Processing of Requests . . . . . . . . . . . . . . . . 9
6.2. RA-Generated PKI Requests . . . . . . . . . . . . . . . . 9 6.2. RA-Generated PKI Requests . . . . . . . . . . . . . . . . 9
6.3. RA-Generated Errors . . . . . . . . . . . . . . . . . . . 10 6.3. RA-Generated PKI Responses . . . . . . . . . . . . . . . 10
7. CA Requirements . . . . . . . . . . . . . . . . . . . . . . . 10 7. CA Requirements . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. CA Processing of PKI Requests . . . . . . . . . . . . . . 11 7.1. CA Processing of PKI Requests . . . . . . . . . . . . . . 11
7.2. CA-Generated PKI Responses . . . . . . . . . . . . . . . 11 7.2. CA-Generated PKI Responses . . . . . . . . . . . . . . . 11
8. Client Requirements: Processing PKI Responses . . . . . . . . 13 8. Client Requirements: Processing PKI Responses . . . . . . . . 13
9. Shared-Secrets . . . . . . . . . . . . . . . . . . . . . . . 13 9. Shared-Secrets . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Scenarios . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Scenarios . . . . . . . . . . . . . . . . . . . . . 17
A.1. Initial Enrollment . . . . . . . . . . . . . . . . . . . 17 A.1. Initial Enrollment . . . . . . . . . . . . . . . . . . . 17
A.2. Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Rekey . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document specifies a profile of the Certificate Management over This document specifies a profile of the Certificate Management over
CMS (CMC) protocol to comply with the United States National Security CMS (CMC) protocol to comply with the United States National Security
skipping to change at page 3, line 27 skipping to change at page 3, line 27
Certificate Policies that implementations need to comply with. Certificate Policies that implementations need to comply with.
2. The Commercial National Security Algorithm Suite 2. The Commercial National Security Algorithm Suite
The National Security Agency (NSA) profiles commercial cryptographic The National Security Agency (NSA) profiles commercial cryptographic
algorithms and protocols as part of its mission to support secure, algorithms and protocols as part of its mission to support secure,
interoperable communications for US Government National Security interoperable communications for US Government National Security
Systems. To this end, it publishes guidance both to assist with the Systems. To this end, it publishes guidance both to assist with the
US Government transition to new algorithms, and to provide vendors - US Government transition to new algorithms, and to provide vendors -
and the Internet community in general - with information concerning and the Internet community in general - with information concerning
their proper use and configuration. their proper use and configuration within the scope of US Government
National Security Systems.
Recently, cryptographic transition plans have become overshadowed by Recently, cryptographic transition plans have become overshadowed by
the prospect of the development of a cryptographically-relevant the prospect of the development of a cryptographically-relevant
quantum computer. NSA has established the Commercial National quantum computer. NSA has established the Commercial National
Security Algorithm (CNSA) Suite to provide vendors and IT users near- Security Algorithm (CNSA) Suite to provide vendors and IT users near-
term flexibility in meeting their cybersecurity interoperability term flexibility in meeting their cybersecurity interoperability
requirements. The purpose behind this flexibility is to avoid requirements. The purpose behind this flexibility is to avoid
vendors and customers making two major transitions in a relatively vendors and customers making two major transitions in a relatively
short timeframe, as we anticipate a need to shift to quantum- short timeframe, as we anticipate a need to shift to quantum-
resistant cryptography in the near future. resistant cryptography in the near future.
skipping to change at page 4, line 33 skipping to change at page 4, line 35
RSA signature key pairs used in CNSA Suite compliant implementations RSA signature key pairs used in CNSA Suite compliant implementations
are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy are either RSA-3072 or RSA-4096. The RSA exponent e MUST satisfy
2^16<e<2^256 and be odd per [FIPS186]. 2^16<e<2^256 and be odd per [FIPS186].
It is recognized that, while the vast majority of RSA signatures are It is recognized that, while the vast majority of RSA signatures are
currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred currently made using the RSASSA-PKCS1-v1_5 algorithm, the preferred
RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite RSA signature scheme for new applications is RSASSA-PSS. CNSA Suite
compliant X.509 certificates will be issued in accordance with compliant X.509 certificates will be issued in accordance with
[ID.cnsa-cert-profile], and while those certificates must be signed [ID.cnsa-cert-profile], and while those certificates must be signed
and validated using RSASSA-PKCS1-v1_5, the subject's key pair can be and validated using RSASSA-PKCS1-v1_5, the subject's private key can
used to generate and validate signatures appropriate for either be used to generate signatures of either signing scheme. Where use
signing scheme. Where use of RSASSA-PSS is indicated in this of RSASSA-PSS is indicated in this document, the following parameters
document, the following parameters apply: apply:
o the hash algorithm MUST be id-sha384 as defined in [RFC8017]; o the hash algorithm MUST be id-sha384 as defined in [RFC8017];
o the mask generation function MUST use the algorithm identifier o the mask generation function MUST use the algorithm identifier
mfg1SHA384Identifier as defined in [RFC4055]; mfg1SHA384Identifier as defined in [RFC4055];
o the salt length MUST be 48 octets; and o the salt length MUST be 48 octets; and
o the trailerField MUST have value 1. o the trailerField MUST have value 1.
These parameters will not appear in a certificate and MUST be These parameters will not appear in a certificate and MUST be
securely communicated with the signature as specified in [RFC4056]. securely communicated with the signature as required by Section 2.2
Application developers are obliged to ensure that the chosen of [RFC4056]. Application developers are obliged to ensure that the
signature scheme is appropriate for the application and will be chosen signature scheme is appropriate for the application and will
interoperable within the intended operating scope of the application. be interoperable within the intended operating scope of the
application.
This document assumes that the required trust anchors have been This document assumes that the required trust anchors have been
securely provisioned to the client and, when applicable, to any RAs. securely provisioned to the client and, when applicable, to any RAs.
All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402] All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402]
apply, except where overridden by this profile. apply, except where overridden by this profile.
This profile was developed with the scenarios described in Appendix A This profile was developed with the scenarios described in Appendix A
in mind. However, use of this profile is not limited to just those in mind. However, use of this profile is not limited to just those
scenarios. scenarios.
skipping to change at page 5, line 32 skipping to change at page 5, line 35
This profile uses the term "rekey" in the same manner as does CMC This profile uses the term "rekey" in the same manner as does CMC
(defined in Section 2 of [RFC5272]). The profile makes no specific (defined in Section 2 of [RFC5272]). The profile makes no specific
statements about the ability to do "renewal" operations; however, the statements about the ability to do "renewal" operations; however, the
statements applicable to rekey should be applied to renewal as well. statements applicable to rekey should be applied to renewal as well.
This profile may be used to manage RA and/or CA certificates. In 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 that case, the RA and/or CA whose certificate is being managed is
considered to be the end-entity. considered to be the end-entity.
This profile does not support key establishment certification This profile does not discuss key establishment certification
requests from cryptographic modules that cannot generate a one-time requests from cryptographic modules that cannot generate a one-time
signature with a key establishment key for proof-of-possession signature with a key establishment key for proof-of-possession
purposes. In that case, a separate profile would be needed to define purposes. In that case, a separate profile would be needed to define
the use of another proof-of-possession technique. the use of another proof-of-possession technique.
5. Client Requirements: Generating PKI Requests 5. Client Requirements: Generating PKI Requests
This section specifies the conventions employed when a client This section specifies the conventions employed when a client
requests a certificate from a Public Key Infrastructure (PKI). requests a certificate from a Public Key Infrastructure (PKI).
skipping to change at page 6, line 20 skipping to change at page 6, line 23
(algorithm OIDs are defined in [RFC5754]); (algorithm OIDs are defined in [RFC5754]);
+ macAlgId MUST be HMAC-SHA384 (the HMAC algorithm is defined + macAlgId MUST be HMAC-SHA384 (the HMAC algorithm is defined
in [RFC4231]). in [RFC4231]).
* If the subject included in the certification request is NULL or * If the subject included in the certification request is NULL or
otherwise does not uniquely identify the end-entity, then the otherwise does not uniquely identify the end-entity, then the
POP Link Random control MUST be included, and the POP Link POP Link Random control MUST be included, and the POP Link
Witness Version 2 control MUST be included in the inner PKCS Witness Version 2 control MUST be included in the inner PKCS
#10 [RFC2986] or Certificate Request Message Format (CRMF) #10 [RFC2986] or Certificate Request Message Format (CRMF)
[RFC4211] request as described in Sections 4.1 and 4.2. [RFC4211] request as described in Section 5.1 and Section 5.2.
o reqSequence MUST be present. It MUST include at least one tcr o reqSequence MUST be present. It MUST include at least one tcr
(see Section 4.1) or crm (see Section 4.2) TaggedRequest. Support (see Section 5.1) or crm (see Section 5.2) TaggedRequest. Support
for the orm choice is OPTIONAL. for the orm choice is OPTIONAL.
The private signing key used to generate the encapsulating SignedData The private signing key used to generate the encapsulating SignedData
MUST correspond to the public key of an existing signature MUST correspond to the public key of an existing signature
certificate unless an appropriate signature certificate does not yet certificate unless an appropriate signature certificate does not yet
exist, such as during initial enrollment. exist, such as during initial enrollment.
The encapsulating SignedData MUST be generated using SHA-384 and The encapsulating SignedData MUST be generated using SHA-384 and
either ECDSA on P-384, or RSA using either RSASSA-PKCS1-v1_5 or either ECDSA on P-384, or RSA using either RSASSA-PKCS1-v1_5 or
RSASSA-PSS with an RSA-3072 or RSA-4096 key. RSASSA-PSS with an RSA-3072 or RSA-4096 key.
skipping to change at page 8, line 24 skipping to change at page 8, line 30
The POPOSigningKey poposkInput field MUST be omitted. The The POPOSigningKey poposkInput field MUST be omitted. The
POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha384 for POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha384 for
P-384 certification requests, and sha384WithRSAEncryption or id- P-384 certification requests, and sha384WithRSAEncryption or id-
RSASSA-PSS for RSA-3072 and RSA-4096 certification requests. The RSASSA-PSS for RSA-3072 and RSA-4096 certification requests. The
signature MUST be generated using the private key corresponding to signature MUST be generated using the private key corresponding to
the public key in the CertTemplate. the public key in the CertTemplate.
The CertTemplate MUST comply with [RFC5272], Section 3.2.1.2.2, with The CertTemplate MUST comply with [RFC5272], Section 3.2.1.2.2, with
the following additional requirements: the following additional requirements:
o version MAY be included and, if included, it MUST be set to 2 as o If version is included, it MUST be set to 2 as defined in
defined in Section 4.3 of [ID.cnsa-cert-profile]; Section 4.3 of [ID.cnsa-cert-profile];
o publicKey MUST be set as defined in Section 4.4 of o publicKey MUST be set as defined in Section 4.4 of
[ID.cnsa-cert-profile]; [ID.cnsa-cert-profile];
o extensions: o extensions:
* The Key Usage extension MUST be included, and it MUST be set as * The Key Usage extension MUST be included, and it MUST be set as
defined in [ID.cnsa-cert-profile]. defined in [ID.cnsa-cert-profile].
* For rekey requests, the SubjectAltName extension MUST be * For rekey requests, the SubjectAltName extension MUST be
skipping to change at page 10, line 40 skipping to change at page 10, line 47
The outer SignedData MUST be generated using SHA-384 and either ECDSA 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 on P-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an
RSA-3072 or RSA-4096 key. RSA-3072 or RSA-4096 key.
If the Full PKI Response is a successful response to a PKI Request 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 that only contained a Get Certificate or Get CRL control, then the
algorithm used in the response and MUST match the algorithm used in algorithm used in the response and MUST match the algorithm used in
the request. the request.
6.3. RA-Generated Errors 6.3. RA-Generated PKI Responses
RA certificates authorized with the CCC certificate extension In order for an RA certificate using the CCC certificate extension to
[RFC6010] MUST include the object identifier for the PKIResponse be authorized to generate responses, the object identifier for the
content type to authorize them to generate responses. PKIResponse content type must be present in the CCC certificate
extension.
7. CA Requirements 7. CA Requirements
This section specifies the requirements for CAs that receive PKI This section specifies the requirements for CAs that receive PKI
Requests and that generate PKI Responses. Requests and that generate PKI Responses.
7.1. CA Processing of PKI Requests 7.1. CA Processing of PKI Requests
CAs conforming to this document MUST ensure that only the permitted CAs conforming to this document MUST ensure that only the permitted
signature, hash, and MAC algorithms described throughout this profile signature, hash, and MAC algorithms described throughout this profile
skipping to change at page 12, line 29 skipping to change at page 12, line 34
sign Full PKI Response messages. Instead, a separate certificate sign Full PKI Response messages. Instead, a separate certificate
indicating authorization to sign CMC responses MUST be used. indicating authorization to sign CMC responses MUST be used.
Authorization to sign Full PKI Responses SHOULD be indicated in the Authorization to sign Full PKI Responses SHOULD be indicated in the
CA certificate by inclusion of the id-kp-cmcCA EKU from [RFC6402]. CA certificate by inclusion of the id-kp-cmcCA EKU from [RFC6402].
The CA certificate MAY also include the CCC certificate extension The CA certificate MAY also include the CCC certificate extension
[RFC6010], or it MAY indicate authorization through inclusion of the [RFC6010], or it MAY indicate authorization through inclusion of the
CCC certificate extension alone. The CA certificate may also be CCC certificate extension alone. The CA certificate may also be
authorized through local configuration. authorized through local configuration.
If the CA is authorized via the CCC extension, then the CCC extension In order for an CA certificate using the CCC certificate extension to
MUST include the object identifier for the PKIResponse content type. be authorized to generate responses, the object identifier for the
CCC SHOULD be included if constraints are to be placed on the content PKIResponse content type must be present in the CCC certificate
types generated. 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 Signatures applied to individual certificates are as required in
[ID.cnsa-cert-profile]. [ID.cnsa-cert-profile].
The signature on the SignedData of a successful response to a Client- The signature on the SignedData of a successful response to a Client-
generated request, or each individual inner SignedData on the generated request, or each individual inner SignedData on the
successful response to a RA-generated request, MUST be generated successful response to a RA-generated request, MUST be generated
using SHA-384 and either ECDSA on P-384 or RSA using RSASSA- 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 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 unsuccessful response MUST be signed using the same key-type and
 End of changes. 17 change blocks. 
31 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/