Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8603.
Authors Michael J. Jenkins , Lydia Zieglar
Last updated 2018-01-29
RFC stream (None)
Formats
IETF conflict review conflict-review-jenkins-cnsa-cert-crl-profile, conflict-review-jenkins-cnsa-cert-crl-profile, conflict-review-jenkins-cnsa-cert-crl-profile, conflict-review-jenkins-cnsa-cert-crl-profile, conflict-review-jenkins-cnsa-cert-crl-profile, conflict-review-jenkins-cnsa-cert-crl-profile
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 8603 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jenkins-cnsa-cert-crl-profile-01
Internet Engineering Task Force                               M. Jenkins
Internet-Draft                                                L. Zieglar
Intended status: Informational                                       NSA
Expires: August 2, 2018                                 January 29, 2018

  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

Jenkins & Zieglar        Expires August 2, 2018                 [Page 1]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

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:

Jenkins & Zieglar        Expires August 2, 2018                 [Page 2]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

   o  [RFC5480] for the syntax and semantics for the Subject Public Key
      Information field in certificates that support Elliptic Curve
      Cryptography;

   o  [RFC5758] for the algorithm identifiers for Elliptic Curve Digital
      Signature Algorithm (ECDSA);

   o  [RFC3279] for the syntax and semantics for the Subject Public Key
      Information field in certificates that support RSA Cryptography;
      and

   o  [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:

   o  An ECDSA-capable signing key using curve P-384; or

   o  An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment
      key using curve P-384; or

   o  An RSA-capable signing key using RSA-3072 or RSA-4096; or

Jenkins & Zieglar        Expires August 2, 2018                 [Page 3]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

   o  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:

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

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

   o  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

   The primary Object Identifier (OID) structure for the CNSA Suite is
   as follows per [X9.62], [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 }

Jenkins & Zieglar        Expires August 2, 2018                 [Page 4]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

3.2.2.  CNSA Suite Object Identifiers for RSA

   The primary OID structure for CNSA Suite is as follows 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 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.

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

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

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.

Jenkins & Zieglar        Expires August 2, 2018                 [Page 5]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

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
   [RFC8017]

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

Jenkins & Zieglar        Expires August 2, 2018                 [Page 6]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

   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.

Jenkins & Zieglar        Expires August 2, 2018                 [Page 7]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

   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.

Jenkins & Zieglar        Expires August 2, 2018                 [Page 8]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

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

   [FIPS186-4]
              National Institute of Standards and Technology, "Digital
              Signature Standard", FIPS 186-4, July 2013,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-4.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
              Identifiers for the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
              2002, <https://www.rfc-editor.org/info/rfc3279>.

Jenkins & Zieglar        Expires August 2, 2018                 [Page 9]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,
              DOI 10.17487/RFC4055, June 2005,
              <https://www.rfc-editor.org/info/rfc4055>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
              <https://www.rfc-editor.org/info/rfc5480>.

   [RFC5758]  Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
              Polk, "Internet X.509 Public Key Infrastructure:
              Additional Algorithms and Identifiers for DSA and ECDSA",
              RFC 5758, DOI 10.17487/RFC5758, January 2010,
              <https://www.rfc-editor.org/info/rfc5758>.

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <https://www.rfc-editor.org/info/rfc8017>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [CNSA]     Committee for National Security Systems, "Commercial
              National Security Algorithm (CNSA) Suite", 2015,
              <https://www.iad.gov/iad/programs/iad-initiatives/
              cnsa-suite.cfm>.

   [SEC1]     Standards for Efficient Cryptography Group, "SEC1:
              Elliptic Curve Cryptography", September 2000.

   [SEC2]     Standards for Efficient Cryptography Group, "SEC 2:
              Recommended Elliptic Curve Domain Parameters", September
              2000.

Jenkins & Zieglar        Expires August 2, 2018                [Page 10]
Internet-Draft   CNSA Suite Certificate and CRL Profile     January 2018

   [SP-800-57]
              Barker, E., "Recommendation for Key Management-Part 1
              Revision 4: General", Special Publication 800-57, January
              2016,
              <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-57pt1r4.pdf>.

   [X9.62]    American National Standards Institute, "Public Key
              Cryptography for the Financial Services Industry; The
              Elliptic Curve Digital Signature Algorithm (ECDSA)",
              ANS X9.62, December 2005.

   [X9.63]    American National Standards Institute, "Public Key
              Cryptography for the Financial Services Industry; Key
              Agreement and Key Transport Using Elliptic Curve
              Cryptography", ANS X9.63, December 2001.

Authors' Addresses

   Michael Jenkins
   National Security Agency

   Email: mjjenki@tycho.ncsc.mil

   Lydia Zieglar
   National Security Agency

   Email: llziegl@nsa.gov

Jenkins & Zieglar        Expires August 2, 2018                [Page 11]