INTERNET-DRAFT                                                J. Solinas
Intended Status: Informational                                L. Zieglar
                                                                     NSA
Expires November 6, 2009                                     May 6, 2009

                  Suite B Certificate and Certificate
                     Revocation List (CRL) Profile
               <draft-solinas-suiteb-cert-profile-02.txt>

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright Notice

   Copyright (c) 2009 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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.










Solinas, Zieglar             Expires September 6, 2009                [Page 1]


INTERNET-DRAFT    Suite B Certificate and CRL Profile           May 2009


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


Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Requirements Terminology. . . . . . . . . . . . . . . . . . . 2
   3.  Requirements and Assumptions. . . . . . . . . . . . . . . . . 3
     3.1.  Implementing Suite B. . . . . . . . . . . . . . . . . . . 3
     3.2.  Suite B Object Identifiers. . . . . . . . . . . . . . . . 4
   4.  Suite B Certificates and Certificate Extensions Profile . . . 4
     4.1.  signatureAlgorithm. . . . . . . . . . . . . . . . . . . . 4
     4.2.  signatureValue. . . . . . . . . . . . . . . . . . . . . . 4
     4.3.  Version . . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.4.  SubjectPublicKeyInfo. . . . . . . . . . . . . . . . . . . 5
     4.5.  Certificate Extensions for Particular Types of
           Certificates. . . . . . . . . . . . . . . . . . . . . . . 7
         4.5.1.  Suite B Self-Signed CA Certificates . . . . . . . . 7
         4.5.2   Suite B Non-Self-Signed CA Certificates . . . . . . 7
         4.5.3.  Suite B End Entity Signature and Key Establishment.
                 Certificates. . . . . . . . . . . . . . . . . . . . 8
   5.  Suite B CRL and CRL Extensions Profile. . . . . . . . . . . . 8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . . 9
     8.1  Normative. . . . . . . . . . . . . . . . . . . . . . . . . 9
     8.2  Informative. . . . . . . . . . . . . . . . . . . . . . . . 9


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 Suite B
   Cryptography.

   The reader is assumed to have familiarity with [RFC5280].  This
   Suite B Certificate and CRL Profile is a profile of RFC 5280.
   All MUST-level requirements of RFC 5280 apply throughout this
   profile and are not repeated here.  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



Solinas, Zieglar             Expires September 6, 2009                [Page 2]


INTERNET-DRAFT    Suite B Certificate and CRL Profile           May 2009


   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 requirements level of RFC 5280.

   The reader is also assumed to have familiarity with [RFC5480],
   which specifies the syntax and semantics for the Subject Public
   Key Information field in certificates that support Elliptic Curve
   Cryptography and [sha2-dsa-ecdsa] which specifies algorithm
   identifiers for ECDSA.


2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3. Requirements and Assumptions

   The goal of this document is to define a base set of certificate and
   CRL formats to support interoperability among Suite B solutions.
   Specific communities, such as the US National Security Systems, may
   define community profiles which further restrict certificate and CRL
   formats by mandating the presence of extensions which 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 Suite B

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

      * An ECDSA capable signing key, using curve P-256 or P-384; or
      * An ECDH capable key establishment key, using curve P-256 or
        P-384.

   Every Suite B certificate and CRL MUST be signed using ECDSA.  The
   signing Certifcation Authority's  (CA's) key MUST be on the curve P-256
   or P-384 if the certificate contains a key on the curve P-256.  If the
   certificate contains a key on the curve P-384, the signing CA's key MUST
   be on the curve P-384.  Any certificate and CRL MUST be hashed using
   SHA256 or SHA384, matched to the size of the signing CA's key.



Solinas, Zieglar             Expires September 6, 2009                [Page 3]


INTERNET-DRAFT    Suite B Certificate and CRL Profile           May 2009


3.2  Suite B Object Identifiers

   The primary OID structure for Suite B is as follows per [X9.62],
   [SEC2], [RFC5480], and [sha2-dsa-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 }

      id-ecDh OBJECT IDENTIFIER ::= {
         certicom-arc schemes(1) ecdh(12) }

      secp256r1 OBJECT IDENTIFIER ::= {
         ansi-X9-62 curves(3) prime(1) 7 }

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

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

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

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


4. Suite B Certificate and Certificate Extensions Profile

   This Suite B certificate profile is a profile of [RFC5280].
   The changes in the requirements from RFC 5280 are listed here.
   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 Suite B certificates.

4.1.  signatureAlgorithm

   The two algorithm identifiers used by Suite B are:
   1.2.840.10045.4.3.2 for ecdsa-with-SHA256 and
   1.2.840.10045.4.3.3 for ecdsa-with-SHA384, as described in
   [X9.62] and [sha2-dsa-ecdsa].

   The parameters MUST be absent as per [sha2-dsa-ecdsa].



Solinas, Zieglar             Expires September 6, 2009                [Page 4]


INTERNET-DRAFT    Suite B Certificate and CRL Profile           May 2009


4.2.  signatureValue

   ECDSA digital signature generation is described in [X9.62]. An ECDSA
   signature value is comprised 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-256 and P-384
   curves can be a maximum of 32 and 48 bytes, respectively.  Therefore,
   converting each r and s to an ASN.1 INTEGER will result in a maximum of
   33 bytes for the P-256 curve and 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.  For
   example, in a signature using P-256 and hex notation:

   r=  52e3f7b7 27fba9e8 eddb1d08 3b75c188
       2517e6dc 63ded9c0 524f8f9a 45dc8661

   s=  b8930438 de8d33bd ab12c3a2 bdad9795
       92a1fd65 76d1734c 3eb0af34 0456aef4

   r represented as a DER encoded INTEGER:
      022052e3 f7b727fb a9e8eddb 1d083b75
      c1882517 e6dc63de d9c0524f 8f9a45dc
      8661

   s represented as a DER encoded INTEGER:
      022100b8 930438de 8d33bdab 12c3a2bd
      ad979592 a1fd6576 d1734c3e b0af3404
      56aef4

   Representation of SEQUENCE of r and s:
      30450220 52e3f7b7 27fba9e8 eddb1d08
      3b75c188 2517e6dc 63ded9c0 524f8f9a
      45dc8661 022100b8 930438de 8d33bdab
      12c3a2bd ad979592 a1fd6576 d1734c3e
      b0af3404 56aef4

   Representation of resulting signatureValue:
      03480030 45022052 e3f7b727 fba9e8ed
      db1d083b 75c18825 17e6dc63 ded9c052
      4f8f9a45 dc866102 2100b893 0438de8d
      33bdab12 c3a2bdad 979592a1 fd6576d1
      734c3eb0 af340456 aef4






Solinas, Zieglar             Expires September 6, 2009                [Page 5]


INTERNET-DRAFT    Suite B Certificate and CRL Profile           May 2009


4.3. Version

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

4.4. SubjectPublicKeyInfo

   For ECDSA signing keys, the algorithm ID, id-ecPublicKey, MUST be
   used.  For ECDH key establishment keys, either the algorithm ID,
   id-ecPublicKey, or the algorithm ID, id-ecDh, MAY be used, as
   described in [RFC5480]. However, for interoperability
   purposes all relying parties MUST be prepared to process the
   algorithm ID id-ecPublicKey.

   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 either the OID for secp256r1 (curve P-256) or 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.3.5 of [RFC3279] and section 4.3.6 of [X9.63].

   Suite B 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 which 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 [RFC3279].

   An octet string representation of a P-256 uncompressed elliptic curve
   point:

      046cc93a 2cdb0308 47fa0734 2bc8e130
      4c77f04f 63557372 43f3a5d7 f51baa82
      23d21ebf b87d9944 f7ec170d 64f9924e
      9ce20e4d 361c2db5 f1d52257 4259edad
      5e








Solinas, Zieglar             Expires September 6, 2009                [Page 6]


INTERNET-DRAFT    Suite B Certificate and CRL Profile           May 2009


   A DER encoded bit string representation of the subject public key:

      03420004 6cc93a2c db030847 fa07342b
      c8e1304c 77f04f63 55737243 f3a5d7f5
      1baa8223 d21ebfb8 7d9944f7 ec170d64
      f9924e9c e20e4d36 1c2db5f1 d5225742
      59edad5e

   A DER encoded representation of the AlgorithmIdentifier:

      30130607 2a8648ce 3d020106 082a8648
      ce3d0301 07

   A DER encoded representation of the subjectPublicKeyInfo using the
   P-256 curve:

      30593013 06072a86 48ce3d02 0106082a
      8648ce3d 03010703 4200046c c93a2cdb
      030847fa 07342bc8 e1304c77 f04f6355
      737243f3 a5d7f51b aa8223d2 1ebfb87d
      9944f7ec 170d64f9 924e9ce2 0e4d361c
      2db5f1d5 22574259 edad5e


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. Suite B 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 SHOULD 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.







Solinas, Zieglar             Expires September 6, 2009                [Page 7]


INTERNET-DRAFT    Suite B Certificate and CRL Profile          May 2009


4.5.2. Suite B Non-Self-Signed CA Certificates

   Non-self-signed CA Certificates in this profile MUST contain the
   authorityKeyIdentifier, subjectKeyIdentifier, keyUsage,
   basicConstraints and certificatePolicies 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 SHOULD NOT be set.

   In adherence with [5280], 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.

   The certificatePolicies extension MUST be marked as non-critical,
   MUST contain the OID for the applicable certificate policy and
   SHOULD NOT use the policyQualifiers option; the "anyPolicy" policy
   MAY be used.

   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.  Suite B End Entity Signature and Key Establishment Certificates

   In adherence with [RFC5280], end entity certificates in this profile
   MUST contain the authorityKeyIdentifier, keyUsage and
   certificatePolicies extensions. 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 SHOULD NOT be set.

   For end entity key establishment certificates, the keyUsage extension
   MUST BE set for keyAgreement. The encipherOnly or decipherOnly bit
   MAY be set. All other bits in the keyUsage extension SHOULD NOT be
   set.

   The certificatePolicies extension MUST be marked as non-critical,
   MUST contain the OID for the applicable certificate policy and
   SHOULD NOT use the policyQualifiers option; the "anyPolicy" policy
   MAY be used.




Solinas, Zieglar             Expires September 6, 2009                [Page 8]


INTERNET-DRAFT    Suite B Certificate and CRL Profile          May 2009


5. Suite B CRL and CRL Extensions Profile

   This Suite B CRL profile is a profile of [RFC5280].  The changes in
   the requirements from [RFC5280] are listed here.

   Signatures in Suite B CRLs follow the same rules as signatures
   for Suite B certificates.


6. Security Considerations

   The security considerations in [RFC5280], [RFC5480],
   and [sha2-dsa-ecdsa] apply.

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


7. IANA Considerations

   This document makes extensive use of object identifiers to register
   public key types, elliptic curves, and algorithms.  Most of them are
   registered in the ANSI X9.62 arc with the exception of some of the
   curves, which are in the Certicom, Inc. arc (these curves have been
   adopted by ANSI and NIST). Extensions in certificates and CRLs are
   identified using the object identifiers defined in an arc delegated
   by IANA to the PKIX working group. No further action by IANA is
   necessary for this document or any anticipated updates.


8. References

8.1  Normative

   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
      Requirement Levels", BCP 14, March 1997.

   [RFC5280] Cooper, D., Santesson, S. Farrell., S., Boeyen, S.,
      Housley, R., Polk, W., "Internet X.509 Public Key Infrastructure
      Certificate and Certificate Revocation List (CRL) Profile",
      May 2008.










Solinas, Zieglar             Expires September 6, 2009                [Page 9]


INTERNET-DRAFT    Suite B Certificate and CRL Profile          May 2009


8.2  Informative

   [sha2-dsa-ecdsa] Dang, Q., Moriarty, K., Brown, D., Polk, T.,
      "Internet X.509 Public Key Infrastructure: Additional Algorithms
      and Identifiers for DSA and ECDSA",
      draft-ietf-pkix-sha2-dsa-ecdsa-06.txt., work-in-progress, March
      2009.

   [RFC3279] Polk, W., Housley, R., Bassham, L., "Algorithms and
      Identifiers for the Internet X.509 Public Key Infrastructure
      Certificate and Certificate Revocation List (CRL) Profile",
      April 2002.

   [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., Polk, T.,
      "Elliptic Curve Cryptography Subject Public Key Information",
      March 2009.

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

   [SP-800-57] Barker, E., Barker, W., Burr, W., Polk, W. Smid, M.,
      "NIST SP-800-57:Recommendation for Key Management-Part 1:
      General", March 2007.

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

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


Author's Address

   Solinas, J.
   National Information Assurance Research Laboratory
   National Security Agency
   Email: jasolin@orion.ncsc.mil

   Zieglar, L.
   National Information Assurance Research Laboratory
   National Security Agency
   Email: llziegl@tycho.ncsc.mil






Solinas, Zieglar             Expires November 6, 2009                [Page 10]