doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc5759.txt b/doc/rfc/rfc5759.txt
new file mode 100644
index 0000000..67f03ea
--- /dev/null
+++ b/doc/rfc/rfc5759.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Solinas
+Request for Comments: 5759                                    L. Zieglar
+Category: Informational                                              NSA
+ISSN: 2070-1721                                             January 2010
+
+
+   Suite B Certificate and Certificate Revocation List (CRL) Profile
+
+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".
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5759.
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (http://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.
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 1]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................3
+   3. Requirements and Assumptions ....................................3
+      3.1. Implementing Suite B .......................................3
+      3.2. Suite B Object Identifiers .................................4
+   4. Suite B Certificate and Certificate Extensions Profile ..........4
+      4.1. signatureAlgorithm .........................................4
+      4.2. signatureValue .............................................5
+      4.3. Version ....................................................6
+      4.4. SubjectPublicKeyInfo .......................................6
+      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 .............8
+           4.5.3. Suite B End Entity Signature and Key
+                  Establishment Certificates ..........................8
+   5. Suite B CRL and CRL Extensions Profile ..........................9
+   6. Security Considerations .........................................9
+   7. IANA Considerations .............................................9
+   8. References .....................................................10
+      8.1. Normative References ......................................10
+      8.2. Informative References ....................................10
+
+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
+   generally not repeated here.  In cases where a MUST-level requirement
+   is repeated for emphasis, the text notes the requirement is "in
+   adherence with [RFC5280]".  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.
+
+
+
+
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 2]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+   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 [RFC5758], which specifies algorithm identifiers for
+   Elliptic Curve Digital Signature Algorithm (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 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 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 (Elliptic Curve Diffie-Hellman) key
+        establishment key, using curve P-256 or P-384.
+
+   Every Suite B certificate and CRL MUST be signed using ECDSA.  The
+   signing Certification 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 SHA-256 or SHA-384, matched to the size of the signing
+   CA's key.
+
+
+
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 3]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+3.2.  Suite B Object Identifiers
+
+   The primary OID structure for Suite B 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 }
+
+      secp256r1 OBJECT IDENTIFIER ::= {
+         ansi-X9-62 curves(3) prime(1) 7 }
+
+      secp384r1 OBJECT IDENTIFIER ::= {
+         certicom-arc curve(0) 34 }
+
+      id-ecSigType OBJECT IDENTIFIER ::= {
+         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 [RFC5758] AND [X9.62].
+
+   The parameters MUST be absent as per [RFC5758].
+
+
+
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 4]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+4.2.  signatureValue
+
+   ECDSA digital signature generation is described in [FIPS186-3].  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.  As per
+   [RFC5480], the structure, included for convenience, is as follows:
+
+      ECDSA-Sig-Value ::= SEQUENCE {
+          r  INTEGER,
+          s  INTEGER
+        }
+
+   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
+
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 5]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+      Representation of resulting signatureValue:
+         03480030 45022052 e3f7b727 fba9e8ed
+         db1d083b 75c18825 17e6dc63 ded9c052
+         4f8f9a45 dc866102 2100b893 0438de8d
+         33bdab12 c3a2bdad 979592a1 fd6576d1
+         734c3eb0 af340456 aef4
+
+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 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
+   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.2 of [RFC5480] and sections 2.3.1 and 2.3.2 of
+   [SEC1].
+
+   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 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 6]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+   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
+
+   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 MUST NOT be set.
+
+
+
+Solinas & Zieglar             Informational                     [Page 7]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+   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.  Suite B 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.  Suite B 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.
+
+
+
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 8]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+   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 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.  Suite B CRL and CRL Extensions Profile
+
+   This Suite B 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 [RFC5280], [RFC5480], and [RFC5758]
+   apply.
+
+   A single key pair SHOULD NOT be used for both signature and key
+   establishment per [SP-800-57].
+
+   The Suite B algorithms provide significantly improved performance
+   when compared to equivalent-strength cryptography that does not
+   employ elliptic curve cryptography.  Where performance has previously
+   been an impediment, use of Suite B may permit employment of PKI-based
+   cryptographic security mechanisms.
+
+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.
+
+
+
+
+
+
+Solinas & Zieglar             Informational                     [Page 9]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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, May 2008.
+
+   [RFC5480]    Turner, S., Brown, D., Yiu, K., Housley, R., and T.
+                Polk, "Elliptic Curve Cryptography Subject Public Key
+                Information", RFC 5480, March 2009.
+
+   [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, January 2010.
+
+8.2.   Informative References
+
+   [FIPS186-3]  "Digital Signature Standard (DSS)", June 2009.
+
+   [SEC1]       Standards for Efficient Cryptography, "SEC1: Elliptic
+                Curve Cryptography", September 2000.
+
+   [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.
+
+
+
+
+
+
+
+
+Solinas & Zieglar             Informational                    [Page 10]
+
+RFC 5759           Suite B Certificate and CRL Profile      January 2010
+
+
+Authors' Addresses
+
+   Jerome Solinas
+   National Information Assurance Research Laboratory
+   National Security Agency
+
+   EMail: jasolin@orion.ncsc.mil
+
+
+   Lydia Zieglar
+   National Information Assurance Research Laboratory
+   National Security Agency
+
+   EMail: llziegl@tycho.ncsc.mil
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Solinas & Zieglar             Informational                    [Page 11]
+