Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile
draft-jenkins-cnsa-cert-crl-profile-01

Abstract

This 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 reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 2, 2018.

Copyright Notice

Copyright (c) 2018 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) 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions
• 3. Requirements and Assumptions
• 3.1. Implementing the CNSA Suite
• 3.2. CNSA Suite Object Identifiers
• 4. CNSA Suite Certificate and Certificate Extensions Profile
• 4.1. signatureAlgorithm
• 4.2. signatureValue
• 4.3. Version
• 4.4. SubjectPublicKeyInfo
• 4.5. Certificate Extensions for Particular Types of Certificates
• 5. CNSA Suite CRL and CRL Extensions Profile
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

This document specifies 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].

This profile of [RFC5280] applies to all CNSA Suite solutions that make use of X.509 v3 Certificates or X.509 v2 CRLs. The reader is assumed to have familiarity with RFC 5280. All MUST-level requirements of RFC 5280 apply throughout this profile and are generally not repeated here. In cases where a MUST-level requirement is repeated for emphasis, the text notes the requirement is "in adherence with RFC 5280". This profile contains changes that elevate some MAY-level options in RFC 5280 to SHOULD-level and MUST-level in this profile; this profile also contains changes that elevate some SHOULD-level options in RFC 5280 to MUST-level for this profile. All options from RFC 5280 that are not listed in this profile remain at the requirement level of RFC 5280.

The reader is also assumed to have familiarity 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. 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.

3. Requirements and Assumptions

The goal of this document is to define a base set of certificate and CRL formats to support interoperability among CNSA Suite solutions. Specific communities, such as the US National Security Systems, may define community profiles that further restrict certificate and CRL formats by mandating the presence of extensions that are optional in this base profile, defining new optional or critical extension types, or restricting the values and/or presence of fields within existing extensions. However, communications between distinct communities MUST use the formats specified in this document when interoperability is desired. Applications may add additional non-critical extensions to these formats but they MUST NOT assume that a remote peer will be able to process them.

3.1. Implementing the CNSA Suite

Every CNSA Suite certificate MUST use the X.509 v3 format, and contain either:

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

All CNSA Suite certificates and CRLs MUST be hashed using SHA-384. The signing Certification Authority's (CA) key MUST conform to the following:

• for certificates containing key generated on the curve P-384, or CRLs citing such certificates, the CA’s certificate signing key MUST also have been generated on the curve P-384.
• for certificates containing an RSA-3072 key, or CRLs citing such certificates, the CA’s certificate signing key MUST be either an RSA-3072 key or RSA-4096 key.
• for certificates containing an RSA-4096 key, or CRLs citing such certificates, the CA’s certificate signing key MUST also be an RSA-4096 key.

The RSA exponent e MUST satisfy 2^16<e<2^256 and be prime per [FIPS186-4].

3.2. CNSA Suite Object Identifiers

3.2.1. CNSA Suite Object Identifiers for ECDSA

      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 }
               

The primary Object Identifier (OID) structure for the CNSA Suite is as follows per [X9.62], [SEC2], [RFC5480], and [RFC5758].

3.2.2. CNSA Suite Object Identifiers for RSA

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

The primary OID structure for CNSA Suite is as follows per [RFC3279].

The rsaEncryption OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field MUST have ASN.1 type NULL for this algorithm identifier.

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

The object identifier used to identify the PKCS #1 version 1.5 signature algorithm with SHA-384 is per [RFC4055]:

4. CNSA Suite Certificate and Certificate Extensions Profile

This section specifies changes to the basic requirements in [RFC5280] for applications that create or use CNSA Suite certificates. Note that RFC 5280 has varying mandates for marking extensions as critical or non-critical. This profile changes some of those mandates for extensions that are included in CNSA Suite certificates.

4.1. signatureAlgorithm

4.1.1. ECDSA

For ECDSA, the algorithm identifier used by the CNSA Suite is:

• 1.2.840.10045.4.3.3 for ecdsa-with-SHA384, as described in [RFC5758] and [X9.62].

The parameters MUST be absent as per [RFC5758].

4.1.2. RSA

For RSA, the algorithm identifier used by the CNSA Suite is:

• 1.2.840.113549.1.1.12 for sha384WithRSAEncryption, as described in [RFC4055]

Per [RFC4055], the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present.

4.2. signatureValue

4.2.1. ECDSA

ECDSA digital signature generation is described in [FIPS186-4]. An ECDSA signature value is composed of two unsigned integers, denoted as 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 encoding it as an ASN.1 INTEGER. Unsigned integers for the P-384 curves can be a maximum of 48 bytes. Therefore, converting each r and s to an ASN.1 INTEGER will result in 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.

4.2.2. RSA

The RSA signature generation process and the encoding of the result is RSASSA-PKCS1-v1_5 as described in detail in PKCS #1 version 2.2

4.3. Version

For this profile, Version MUST be v3, which means the value MUST be set to 2.

4.4. SubjectPublicKeyInfo

4.4.1. Elliptic Curve Cryptography

For ECDSA signing 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) is mapped to a subjectPublicKey (a BIT STRING) as follows: 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].

4.4.2. RSA

For RSA signing 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].

4.5. Certificate Extensions for Particular Types of Certificates

Different types of certificates in this profile have different required and recommended extensions. Those are listed in this section. Those extensions from RFC 5280 not explicitly listed in this profile remain at the requirement levels of RFC 5280.

4.5.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.

4.5.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 is 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 conforming to this profile MUST be prepared to process the policyMappings, policyConstraints, and inhibitAnyPolicy extensions, regardless of criticality, following the guidance in [RFC5280] when they appear in non-self-signed CA certificates.

4.5.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 is 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.

5. CNSA Suite CRL and CRL Extensions Profile

This CNSA Suite CRL profile is a profile of [RFC5280]. There are changes in the requirements from [RFC5280] for the signatures on CRLs of this profile.

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.

6. Security Considerations

The security considerations in [RFC3279], [RFC4055], [RFC5280], [RFC5480], and [RFC5758], and [RFC8017] apply.

A single key pair SHOULD NOT be used for both signature and key establishment per [SP-800-57].

7. IANA Considerations

No IANA actions are required.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses