RFC 8603

Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile

📅 published May 2019, from ietf

RFC 8603 💖 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile

Okay bestie, let's dive into RFC 8603 🎀 Here's the title block: it's an Informational doc from the Independent Submission stream, written by M. Jenkins and L. Zieglar at the NSA, dated May 2019, with ISSN 2070-1721. It doesn't list anything it obsoletes or updates. Main character energy, no notes 🧚

Here's the table of contents, copied exactly:

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  The Commercial National Security Algorithm Suite  . . . . . .   4
3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  General Requirements and Assumptions  . . . . . . . . . . . .   4
  4.1.  Implementing the CNSA Suite . . . . . . . . . . . . . . .   5
  4.2.  CNSA Suite Object Identifiers . . . . . . . . . . . . . .   6
5.  CNSA Suite Base Certificate Required Values . . . . . . . . .   7
  5.1.  signatureAlgorithm  . . . . . . . . . . . . . . . . . . .   7
  5.2.  signatureValue  . . . . . . . . . . . . . . . . . . . . .   7
  5.3.  Version . . . . . . . . . . . . . . . . . . . . . . . . .   8
  5.4.  SubjectPublicKeyInfo  . . . . . . . . . . . . . . . . . .   8
6.  Certificate Extensions for Particular Types of Certificates .   9
  6.1.  CNSA Suite Self-Signed CA Certificates  . . . . . . . . .   9
  6.2.  CNSA Suite Non-Self-Signed CA Certificates  . . . . . . .   9
  6.3.  CNSA Suite End-Entity Signature and Key Establishment
        Certificates  . . . . . . . . . . . . . . . . . . . . . .  10
7.  CNSA Suite CRL Requirements . . . . . . . . . . . . . . . . .  10
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
  10.2.  Informative References . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Abstract ✨

This doc sets out a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) to be used with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile covers the capabilities, configuration, and operation of all components of US National Security Systems that use these X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It's also suitable for all other US Government systems that process high-value information. It's made public so developers and operators of these systems, and of any other deployments, can use it 🫶

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that.

Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc8603.

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please review these documents carefully, since they spell out your rights and restrictions with respect to this document 💅

1. Introduction 🌈

This doc sets out a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use by applications that support the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite [CNSA]. The profile covers the capabilities, configuration, and operation of all components of US National Security Systems that use these X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59 [SP80059]. It's also suitable for all other US Government systems that process high-value information. It's made public for use by developers and operators of these systems and any other system deployments.

This document doesn't define a new cryptographic algorithm suite. Instead, it defines a CNSA-compliant profile of "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] 🔥 It applies to all CNSA Suite solutions that use X.509 v3 Certificates or X.509 v2 CRLs. The reader is assumed to already know RFC 5280. All MUST-level requirements of RFC 5280 apply throughout this profile and usually aren't repeated here. Where a MUST-level requirement is repeated for emphasis, the text says the requirement is "in adherence with RFC 5280". This profile changes some SHOULD-level options in RFC 5280 up to MUST-level, and also changes some MAY-level options in RFC 5280 up to SHOULD-level or MUST-level. Any RFC 5280 option not listed in this profile keeps the requirement level it has in RFC 5280 💜

The reader is also assumed to be familiar with these documents:

  • [RFC5480] for the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography,
  • [RFC5758] for the algorithm identifiers for Elliptic Curve Digital Signature Algorithm (ECDSA),
  • [RFC3279] for the syntax and semantics for the Subject Public Key Information field in certificates that support RSA Cryptography, and
  • [RFC4055] for the algorithm identifiers for RSA Cryptography with the SHA-384 hash function.

2. The Commercial National Security Algorithm Suite 🍓

The 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. So it publishes guidance that helps with moving the US Government to new algorithms, and gives vendors and the wider Internet community info on how to use and configure them properly 🧚

Lately, crypto transition plans have been overshadowed by the possibility of a cryptographically relevant quantum computer 👀 The NSA set up the Commercial National Security Algorithm (CNSA) Suite to give vendors and IT users near-term flexibility in meeting their cybersecurity interoperability requirements. The point of that flexibility is to keep vendors and customers from making two major transitions in a fairly short window, since we expect a shift to quantum-resistant cryptography in the near future. It's giving planning ahead 🙈

The NSA is writing a set of RFCs, this one included, to give updated guidance on using certain common commercial algorithms in IETF protocols. These RFCs can be used alongside other RFCs and crypto guidance (for example, NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems 🌸

3. Conventions 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lowercase versions don't count, so read the capitals carefully, bestie 🫶

4. General Requirements and Assumptions 💅

The goal of this document is to define a base set of requirements for certificates and CRLs, so CNSA Suite solutions can interoperate. Specific communities, such as those tied to US National Security Systems, may define community profiles that restrict certificate and CRL contents further. They can do this by requiring extensions that are optional in this base profile, defining new optional or critical extension types, or restricting the values and/or presence of fields inside existing extensions. However, communications between distinct communities MUST conform with the requirements specified in this document when interoperability is desired. Applications may add requirements for additional non-critical extensions, but they MUST NOT assume that a remote peer will be able to process them ⭐

4.1. Implementing the CNSA Suite ✨

Every CNSA Suite certificate MUST use the X.509 v3 format and contain one of the following:

  • An ECDSA-capable signature verification key using curve P-384, or
  • An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment key using curve P-384, or
  • An RSA-capable signature verification key using RSA-3072 or RSA-4096, or
  • An RSA-capable key transport key using RSA-3072 or RSA-4096.

The signature applied to all CNSA Suite certificates and CRLs MUST be made with a signing key that is either generated on the curve P-384, or is an RSA-3072 or RSA-4096 key. The SHA-384 hashing algorithm MUST be used for all certificate and CRL signatures, no matter what type of key is used 🔥

The RSA exponent "e" MUST satisfy 2^16<e<2^256 and be odd per [FIPS186].

The requirements of this document don't aim to rule out RSASSA-PSS signatures. However, Certification Authorities (CAs) conforming with this document won't issue certificates that specify that algorithm for subject public keys. Protocols that use RSASSA-PSS should be configured to use certificates that specify rsaEncryption as the subject public key algorithm. Protocols that use these keys with RSASSA-PSS signatures must use the following parameters: the hash algorithm (used for both mask generation and signature generation) must be SHA-384, the mask generation function 1 from [RFC8017] must be used, and the salt length must be 48 octets 🦋

4.2. CNSA Suite Object Identifiers 🧚

4.2.1. CNSA Suite Object Identifiers for ECDSA 👑

The primary Object Identifier (OID) structure for the CNSA Suite goes like this, per [X962], [SEC2], [RFC5480], and [RFC5758] 💖

      ansi-X9-62 OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) us(840) 10045 }

      certicom-arc OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) certicom(132) }

      id-ecPublicKey OBJECT IDENTIFIER ::= {
         ansi-X9-62 keyType(2) 1 }

      secp384r1 OBJECT IDENTIFIER ::= {
         certicom-arc curve(0) 34 }

      id-ecSigType OBJECT IDENTIFIER ::= {
         ansi-X9-62 signatures(4) }

      ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
         id-ecSigType ecdsa-with-SHA2(3) 3 }

4.2.2. CNSA Suite Object Identifiers for RSA

okay so for RSA, the main OID structure is this one, per [RFC3279] 💅

pkcs-1 OBJECT IDENTIFIER ::= {
   iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

rsaEncryption OBJECT IDENTIFIER ::= {
   pkcs-1 1}

the rsaEncryption OID is meant to go in the algorithm field of an AlgorithmIdentifier value 🎀. the parameters field MUST have ASN.1 type NULL for this algorithm identifier, so keep that in mind bestie 🫶

then there's the OID for the PKCS #1 version 1.5 signature algorithm with SHA-384, which comes from [RFC4055] 🦋

sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  {
   pkcs-1 12 }

5. CNSA Suite Base Certificate Required Values ✨

okay this section is where the CNSA Suite tweaks the basic [RFC5280] rules for apps that make or use CNSA Suite certificates 💖 heads up though: RFC 5280 is kinda inconsistent about which extensions are critical and which aren't, and this profile changes some of those rules for the extensions that show up in CNSA Suite certs 🙈

5.1. signatureAlgorithm

5.1.1. ECDSA

for ECDSA, the algorithm identifier the CNSA Suite uses is described in [RFC5758] and [X962]:

   1.2.840.10045.4.3.3 for ecdsa-with-SHA384

the parameters MUST be absent as per [RFC5758] 🌸

5.1.2. RSA

for RSA, the algorithm identifier the CNSA Suite uses is described in [RFC4055]:

   1.2.840.113549.1.1.12 for sha384WithRSAEncryption.

per [RFC4055], the parameters MUST be NULL. implementations MUST accept the parameters being absent as well as present 🧚

5.2. signatureValue

5.2.1. ECDSA

ECDSA digital signature generation is described in [FIPS186] 🔥 an ECDSA signature value is made of two unsigned integers, called "r" and "s". "r" and "s" MUST be represented as ASN.1 INTEGERs. if the high-order bit of the unsigned integer is a 1, an octet with the value 0x00 MUST be prepended to the binary representation before it gets encoded as an ASN.1 INTEGER. unsigned integers for the P-384 curves can be a maximum of 48 bytes, so converting each "r" and "s" to an ASN.1 INTEGER will give you a maximum of 49 bytes for the P-384 curve 💅

the ECDSA signatureValue in an X.509 certificate is encoded as a BIT STRING value of a DER-encoded SEQUENCE of the two INTEGERS 🍓

5.2.2. RSA

the RSA signature generation process and how the result gets encoded is RSASSA-PKCS1-v1_5, described in detail in PKCS #1 version 2.2 [RFC8017] 🌈

5.3. Version

for this profile, Version MUST be v3, which means the value MUST be set to 2 ✨

5.4. SubjectPublicKeyInfo

5.4.1. Elliptic Curve Cryptography

for ECDSA signature verification keys and ECDH key agreement keys, the algorithm ID id-ecPublicKey MUST be used 👑

the parameters of the AlgorithmIdentifier in this field MUST use the namedCurve option. the specifiedCurve and implicitCurve options described in [RFC5480] MUST NOT be used. the namedCurve MUST be the OID for secp384r1 (curve P-384) [RFC5480] 💜

the elliptic curve public key, ECPoint, SHALL be the OCTET STRING representation of an elliptic curve point, following the conversion routine in Section 2.2 of [RFC5480] and Sections 2.3.1 and 2.3.2 of [SEC1] 🦋

CNSA Suite implementations MAY use either the uncompressed form or the compressed form of the elliptic curve point [RFC5480]. for interoperability purposes, all relying parties MUST be prepared to process the uncompressed form 🫶

the elliptic curve public key (an ECPoint that is an OCTET STRING) gets mapped to a subjectPublicKey (a BIT STRING) like this: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING [RFC5480] 🌸

5.4.2. RSA

for RSA signature verification keys and key transport keys, the algorithm ID, rsaEncryption, MUST be used 🎀

the parameters field MUST have ASN.1 type NULL for this algorithm identifier [RFC3279] 🧚

the RSA public key MUST be encoded using the ASN.1 type RSAPublicKey, per Section 2.3.1 of [RFC3279] 💖

6. Certificate Extensions for Particular Types of Certificates 🌈

different types of certificates in this profile have different required and recommended extensions, and they're all listed in this section 💅 any extensions from RFC 5280 that aren't explicitly listed in this profile stay at the requirement levels of RFC 5280, so nothing gets lost ✨

6.1. CNSA Suite Self-Signed CA Certificates

in adherence with [RFC5280], self-signed CA certificates in this profile MUST contain the subjectKeyIdentifier, keyUsage, and basicConstraints extensions 👑

the keyUsage extension MUST be marked as critical. the keyCertSign and cRLSign bits MUST be set. the digitalSignature and nonRepudiation bits MAY be set. all other bits MUST NOT be set 🔥

in adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. the cA boolean MUST be set to indicate that the subject is a CA, and the pathLenConstraint MUST NOT be present 🦋

6.2. CNSA Suite Non-Self-Signed CA Certificates

non-self-signed CA Certificates in this profile MUST contain the authorityKeyIdentifier, keyUsage, and basicConstraints extensions. if there's a policy to be asserted, then the certificatePolicies extension MUST be included 💜

the keyUsage extension MUST be marked as critical. the keyCertSign and CRLSign bits MUST be set. the digitalSignature and nonRepudiation bits MAY be set. all other bits MUST NOT be set 🌸

in adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. the cA boolean MUST be set to indicate that the subject is a CA, and the pathLenConstraint subfield is OPTIONAL 🍓

if a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies, and SHOULD NOT use the policyQualifiers option. if a policy is not asserted, the certificatePolicies extension MUST be omitted 🎀

relying party applications that conform to this profile MUST be prepared to process the policyMappings, policyConstraints, and inhibitAnyPolicy extensions, regardless of criticality. follow the guidance in [RFC5280] when they show up in non-self-signed CA certificates 🧚

6.3. CNSA Suite End-Entity Signature and Key Establishment Certificates

in adherence with [RFC5280], end-entity certificates in this profile MUST contain the authorityKeyIdentifier and keyUsage extensions. if there's a policy to be asserted, then the certificatePolicies extension MUST be included. end-entity certificates SHOULD contain the subjectKeyIdentifier extension 💖

the keyUsage extension MUST be marked as critical 🌈

for end-entity digital signature certificates, the keyUsage extension MUST be set for digitalSignature. the nonRepudiation bit MAY be set. all other bits in the keyUsage extension MUST NOT be set 💅

for end-entity key establishment certificates: in ECDH certificates, the keyUsage extension MUST be set for keyAgreement, and in RSA certificates, the keyUsage extension MUST be set for keyEncipherment. the encipherOnly or decipherOnly bit MAY be set. all other bits in the keyUsage extension MUST NOT be set ✨

if a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies, and SHOULD NOT use the policyQualifiers option. if a policy is not asserted, the certificatePolicies extension MUST be omitted 👑

7. CNSA Suite CRL Requirements 🔥

this CNSA Suite CRL profile is a profile of [RFC5280] 🦋 it changes some of the [RFC5280] requirements for the signatures on CRLs, so pay attention to that part 💜

the signatures on CRLs in this profile MUST follow the same rules from this profile that apply to signatures in the certificates. See Section 4 🫶

8. Security Considerations 💀

the security considerations in [RFC3279], [RFC4055], [RFC5280], [RFC5480], [RFC5758], and [RFC8017] all apply. no skipping these, bestie, they're serious 😭

⚠️ a single key pair SHOULD NOT be used for both signature and key establishment, per [SP80057]. mixing those two jobs on one key pair is a big no-no, so keep your keys separated 🙅‍♀️

9. IANA Considerations 🌸

this document has no IANA actions 🌸

10. References 📚

10.1. Normative References

10.2. Informative References ✨

okay bestie, these are the extra-credit reads 📚 they aren't required to implement the spec, but they're the sources the document points to for background 💅

  • [SEC2] Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", January 2010, https://www.secg.org/sec2-v2.pdf. 🦋
  • [SP80057] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57 Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf. 🔑
  • [SP80059] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", NIST Special Publication 800-59, DOI 10.6028/NIST.SP.800-59, August 2003, https://csrc.nist.gov/publications/detail/sp/800-59/final. 🌸
  • [X962] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry; The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005. 🧚

Authors' Addresses 🎀

Michael Jenkins National Security Agency

Email: mjjenki@nsa.gov 💜

Lydia Zieglar National Security Agency

Email: llziegl@tycho.ncsc.mil 🫶

📦 where this page comes from