PKIX J. Solinas INTERNET-DRAFT L. Zieglar Intended Status: Informational NSA Expires June 5, 2009 December 5, 2008 Suite B Certificate and Certificate Revocation List (CRL) Profile Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 Abstract This document specifies a base profile for X.509 Certificates and Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. This profile is a refinement of RFC5280. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology. . . . . . . . . . . . . . . . . . . 4 3. Requirements and Assumptions. . . . . . . . . . . . . . . . . 5 3.1. Implementing Suite B. . . . . . . . . . . . . . . . . . . 5 3.2. Commercial Protocols. . . . . . . . . . . . . . . . . . . 6 3.2.1. Transport Layer Security (TLS). . . . . . . . . . . . 6 3.2.2. Internet Key Exchange (IKE) . . . . . . . . . . . . . 6 Solinas, Zieglar [Page 1] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 3.2.3. S/MIME. . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.4. Secure Shell (SSH). . . . . . . . . . . . . . . . . . 7 4. Suite B Certificate and Certificate Extensions Profile. . . . 7 4.1. Basic Certificate Fields. . . . . . . . . . . . . . . . . 8 4.1.1. Certificate Fields . . . . . . . . . . . . . . . . . 8 4.1.1.1. tbsCertificate. . . . . . . . . . . . . . . . . 8 4.1.1.2. signatureAlgorithm. . . . . . . . . . . . . . . 8 4.1.1.3. signatureValue. . . . . . . . . . . . . . . . . 9 4.1.2. TBSCertificate. . . . . . . . . . . . . . . . . . . . 9 4.1.2.1. Version . . . . . . . . . . . . . . . . . . . . 9 4.1.2.2. Serial Number . . . . . . . . . . . . . . . . . 9 4.1.2.3. Signature . . . . . . . . . . . . . . . . . . . 9 4.1.2.4. Issuer. . . . . . . . . . . . . . . . . . . . . 9 4.1.2.5. Validity. . . . . . . . . . . . . . . . . . . . 9 4.1.2.6. Subject . . . . . . . . . . . . . . . . . . . .10 4.1.2.7. Subject Public Key Info . . . . . . . . . . . .10 4.1.2.8. Unique Identifiers. . . . . . . . . . . . . . .10 4.1.2.9. Extensions. . . . . . . . . . . . . . . . . . .11 4.2. Certificate Extensions. . . . . . . . . . . . . . . . . .11 4.2.1. Suite B Root CA Self-Signed . . . . . . . . . . . .11 4.2.2. Suite B Subordinate CA Certificates . . . . . . . .11 4.2.2.1. REQUIRED Extensions . . . . . . . . . . . . . .11 4.2.2.2. RECOMMENDED Extensions. . . . . . . . . . . . .12 4.2.3 Suite B Cross-Certificates. . . . . . . . . . . . .12 4.2.3.1. REQUIRED Extensions . . . . . . . . . . . . . .12 4.2.3.2. RECOMMENDED Extensions. . . . . . . . . . . . .13 4.2.4. Suite B End Entity Signature and Key Establishment Certificates. . . . . . . . . . .13 4.2.4.1. REQUIRED Extensions . . . . . . . . . . . . . .13 4.2.4.2. RECOMMENDED Extensions. . . . . . . . . . . . .14 5. Suite B Certificate Revocation List (CRL) and CRL Extensions Profile. . . . . . . . . . . . . . . . . . . . . .14 5.1. CRL Fields. . . . . . . . . . . . . . . . . . . . . . . .15 5.1.1. tbsCertList . . . . . . . . . . . . . . . . . . . .15 5.1.1.1. Version . . . . . . . . . . . . . . . . . . . .15 5.1.1.2. Signatue. . . . . . . . . . . . . . . . . . . .15 5.1.1.3. Issuer. . . . . . . . . . . . . . . . . . . . .15 5.1.1.4. ThisUpdate. . . . . . . . . . . . . . . . . . .15 5.1.1.5. NextUpdate. . . . . . . . . . . . . . . . . . .16 5.1.1.6. RevokedCertificates . . . . . . . . . . . . . .16 5.1.2. signatureAlgorithm . . . . . . . . . . . . . . . . .16 5.1.3. signatureValue . . . . . . . . . . . . . . . . . . .16 5.2. CRL Extensions. . . . . . . . . . . . . . . . . . . . . .16 6. Security Considerations . . . . . . . . . . . . . . . . . . .17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .17 8. References. . . . . . . . . . . . . . . . . . . . . . . . . .18 8.1 Normative . . . . . . . . . . . . . . . . . . . . . . . .18 8.2. Informative . . . . . . . . . . . . . . . . . . . . . . .19 Appendix A. Reference Sections for Certificate and CRL Fields. .20 A.1. Reference Sections for Certificate Fields . . . . . . . .20 Solinas, Zieglar [Page 2] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 A.2. Reference Sections for CRL Fields . . . . . . . . . . . .23 Appendix B. Certificate Field Values . . . . . . . . . . . . . .24 B.1. Root CA Self-Signed Certificate using P-256 signed with P-256. . . . . . . . . . . . . . . . . . . . . . . .24 B.2. Root CA Self-Signed Certificate using P-384 signed with P-384. . . . . . . . . . . . . . . . . . . . . . . .25 B.3. Subordinate CA Certificate using P-256 signed with P-256 . . . . . . . . . . . . . . . . . . . . . . . . . .26 B.4. Subordinate CA Certificate using P-384 signed with P-384 . . . . . . . . . . . . . . . . . . . . . . . . . .28 B.5. Subordinate CA Certificate using P-256 signed with P-384 . . . . . . . . . . . . . . . . . . . . . . . . . .29 B.6. CA Cross-Certificate using P-256 signed with P-256. . . .31 B.7. CA Cross-Certificate using P-384 signed with P-384. . . .33 B.8. CA Cross-Certificate using P-256 signed with P-384. . . .35 B.9. End Entity Signature Certificate using P-256 signed . with P-256. . . . . . . . . . . . . . . . . . . . . . . .37 B.10. End Entity Signature Certificate using P-384 signed . with P-384. . . . . . . . . . . . . . . . . . . . . . . .38 B.11. End Entity Signature Certificate using P-256 signed . with P-384. . . . . . . . . . . . . . . . . . . . . . . .40 B.12. End Entity Key Establishment Certificate using P-256. Signed with P-256 . . . . . . . . . . . . . . . . . . . .42 B.13. End Entity Key Establishment Certificate using P-384. Signed with P-384 . . . . . . . . . . . . . . . . . . . .43 B.14. End Entity Key Establishment Certificate using P-256. Signed with P-384 . . . . . . . . . . . . . . . . . . . .45 Appendix C. Certificate Revocation List (CRL) Field Values . . .47 C.1. Certificate Revocation List (CRL) Signed with P-256 . . .47 C.2. Certificate Revocation List (CRL) Signed with P-384 . . .47 1. Introduction This document specifies a base profile for X.509v3 Certificates and Certificate Revocation Lists for use by implementations of Transport Layer Security (TLSv1.2), IPsec Internet Key Exchange (IKEv1 and IKEv2), S/MIME, Cryptographic Message Syntax (CMS) and Secure Shell (SSH) which support the United States National Security Agency's (NSA) Suite B Cryptography. This profile is also applicable to protocols under revision in the international standards environment which will incorporate suite B cryptography, such as XML Encryption or XML Signature. Solinas, Zieglar [Page 3] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 This Suite B certificate and CRL profile complements [RFC5280]. If a specific program needs to implement a subset of the Suite B certificate and CRL profile, the program should tailor its X.509 certificate and CRL profile using the parameters stipulated in this document together with the parameters stipulated in [RFC5280]. Parameters stipulated in this document should take precedence. When "no specific requirements" is stated for a particular field or extension in this profile, then no specific requirements apply except for those stated by [RFC5280]. In case of discrepancies between the present profile and [RFC5280], the present document is the normative one for Suite B. The format is applicable to the following Suite B certificate and CRL types: * Root Certification Authority (CA) Self-Signed Certificate using P-256 signed with P-256 * Root CA Self-Signed Certificate using P-384 signed with P-384 * Subordinate CA Certificate using P-256 signed with P-256 * Subordinate CA Certificate using P-384 signed with P-384 * Subordinate CA Certificate using P-256 signed with P-384 * CA Cross-Certificate using P-256 signed with P-256 * CA Cross-Certificate using P-384 signed with P-384 * CA Cross-Certificate using P-256 signed with P-384 * End-Entity Signature Certificate using P-256 signed with P-256 * End-Entity Signature Certificate using P-384 signed with P-384 * End-Entity Signature Certificate using P-256 signed with P-384 * End-Entity Key Establishment Certificate using P-256 signed with P-256 * End-Entity Key Establishment Certificate using P-384 signed with P-384 * End-Entity Key Establishment Certificate using P-256 signed with P-384 * CRL signed with P-256 * CRL signed with P-384 This document does not address implementation requirements. It does not address requirements on the use of specific protocols, equipment, or key strength levels to protect information with specific sensitivity levels and/or in specific threat environments. 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]. Solinas, Zieglar [Page 4] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 3. Requirements and Assumptions The goal of this document is to define a base set of certificate and CRL formats to support interoperability between distinct 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.) In most applications, performance, scalability, and cost will require the infrastructure to delegate reponsibility for generating end-entity key pairs to the nodes themselves. With the end-entities performing the key generation, the infrastructure is only required to support X.509v3 certificate issuance and signing functions. When necessary, key pairs may be generated centrally by the infrastructure. The infrastructure is responsible for revocation, protection of centrally generated private keys, and other certificate management functions. In either key generation model, the format of the Suite B certificates shall remain as specified in this document. This Suite B certificate and CRL profile complements [RFC5280]. If a specific program needs to implement s subset of the Suite B certificate and CRL profile, the program should tailor its X.509 certificate and CRL profile using the parameters stipulated in this document together with the parameters stipulated in [RFC5280]. Parameters stipulated in this document should take precedence. When "no specific requirements" is stated for a particular field or extension in this profile, then no specific requirements apply except for those stated by [RFC5280]. In case of discrepancies between the present profile and [RFC5280], the present document is the normative one for Suite B. 3.1 Implementing Suite B Every Suite B certificate must use the X.509v3 format, and contain either: * An ECDSA capable signing key, using group P-256 or P-384; or * An ECDH capable key establishment key, using group P-256 or P-384. Solinas, Zieglar [Page 5] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Every Suite B certificate and CRL must be signed using ECDSA. The signing CA's key must be on the group P-256 or P-384 if the certificate contains a key on the group P-256. If the certificate contains a key on the group P-384, the signing CA's key must be on the group P-384. Any certificate must be hashed using SHA256 or SHA384, matched to the size of the signing CA's key. Compliant Suite B implementations that use an ECDSA signing key or static ECDH key must be compatible with issuing certificate requests and resolving certificate responses. The preferred protocol is [RFC5272], Certificate Management Messages over CMS (CMC). The infrastructure supporting Suite B must be capable of issuing X.509v3 certificates and CRLs, signed with ECDSA with the appropriate P-256 or P-384 curve. 3.2 Commercial Protocols The following sections provide guidance for the use of Suite B cryptography in commercial protocols. 3.2.1 Transport Layer Security (TLS) Suite B TLS implementations should reference Internet-Draft "Suite B Profile for Transport Layer Security (TLS)", dated December 17, 2008 (draft-rescorla-tls-suiteb-11.txt). TLS utilizes ECDHE (ephemeral) and ECDSA (with P-256 or P-384) [SuiteBTLS]. The ECDH key exchange is Ephemeral-Ephemeral (E-E) with the server supplying a certificate containing an ECDSA key, signed with ECDSA. At a minimum, ECDHE-ECDSA (with P-256) should be implemented. If the client is to be authenticated, it must acquire an X.509v3 certificate containing an ECDSA key, signed with ECDSA to be used in TLS exchanges. Note that the TLS protocol would indicate the server sent a request for a certificate type "ECDSA_sign". Clients in a Suite B TLS exchange never require static key establishment keys. 3.2.2. Internet Key Exchange (IKE) Suite B IKE implementations MUST follow [RFC4869]. Solinas, Zieglar [Page 6] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 IKE shared secrets always involve E-E Diffie-Hellman (DH) key exchange, so there are no static ECDH keys in this protocol. Authentication via public key will require an ECDSA capable certificate. These will be X.509v3 certificates containing a key from the Suite B elliptic curve P-256 or P-384, and signed with ECDSA. 3.2.3 S/MIME Suite B S/MIME implementations MUST follow [RFC5008]. Suite B key establishment in S/MIME uses an ECDH key establishment key and an ECDSA signing key, both signed using ECDSA. The ECDH involves E-S using P-256 or P-384 curves. Any message peer in a Suite B compliant S/MIME environment must have an ECDH X.509v3 certificate, signed with ECDSA. Some current RSA-based implementations of S/MIME certificates contain a key with key usage extension bits set for both key establishment and signing. Suite B implementations are not permitted to use a single certificate for multiple key usages. 3.2.4 Secure Shell (SSH) Suite B implementations of SSH should reference Internet-Draft "Suite B Cryptographic Suites for Secure Shell", dated September 2008 (draft-igoe-secsh-suiteb-00.txt). In the SSH environment, ECDH is always E-E, with the server authentication to the client using ECDSA. Therefore the only certificate required to support SSH contains an ECDSA key, signed with ECDSA. 4. Suite B X.509 Certificate and Certificate Extensions Profile [RFC5280] describes the basic structure of an X.509 version 3 certificate and CRL, and provides a provfile to faciliate the use of X.509 certificates and CRLs within the Internet community for various applications such as WWW (TLS), electronic email (S/MIME), and IPSec. This Suite B certificate and CRL profile complements [RFC5280]. As previously stated, programs that need to be interoperable or compatible with Suite B should tailor their X.509 certificate and CRL profile using the parameters stipulated in this document together with the parameters stipulated in [RFC5280]. Parameters in this document take precedence over those in [RFC 5280]. If "no specific requirements" are stated for a particular field in this document, then those in [RFC5280] apply. Solinas, Zieglar [Page 7] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 4.1. Basic Certificate Fields The basic X.509v3 certificate syntax is as follows from [RFC5280]: Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL --If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL --If present, version MUST be v2 or v3 Extensions [3] EXPLICIT Extensions OPTIONAL --If present, version MUST be v3 } 4.1.1. Certificate Fields Certificate is REQUIRED and MUST include the three fields: tbsCertificate, signatureAlgorithm, and signatureValue, as specified in [RFC5280]. Further requirements for these fields for Suite B follows: 4.1.1.1. tbsCertificate The tbsCertificate field contains the names of the subject and issuer, a public key associated with the subject, a validity period, and other associated information. The fields are described in detail in Section 4.1.2 of this document, and Section 4.1.2 of [RFC5280]. 4.1.1.2. signatureAlgorithm The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate per [RFC5280], Section 4.1.1.2. The two algorithm identifiers used by Suite B are ecdsa-with-SHA256 and ecdsa-with-SHA384 per [X9.62], Section E.8. Solinas, Zieglar [Page 8] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 4.1.1.3. signatureValue The signatureValue field, for Suite B Certificates, contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate [RFC5280], Section 4.1.1.3. The ECDSA digital signature MUST be used for Suite B certificates [X9.62], Section 7. The ECDSA signature value is comprised of two unsigned integers, denoted r and s. However, ASN.1 encoding of INTEGER is used to represent r and s in the signatureValue field. If the high order bit of the unsigned integer is a 1, a byte with 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 to an ASN.1 INTEGER will mean a maximum of 33 bytes for the P-256 curve and 49 bytes for the P-384 curve. The ECDSA signatureValue is encoded as a BIT STRING value of a DER encoded SEQUENCE of the two INTEGERS, and stored in the signatureValue field of the Certificate. 4.1.2. TBSCertificate As stated in [RFC5280], TBSCertificate contains information associated with the subject of the certificate and the CA that issued it. The fields are described in detail as follows and in [RFC5280]. 4.1.2.1. Version Version is REQUIRED and MUST be set to 2 to denote X.509 version 3 public key certificates [RFC5280], Section 4.1.2.1. 4.1.2.2. SerialNumber SerialNumber is REQUIRED and MUST follow [RFC5280], Section 4.1.2.2. 4.1.2.3. Signature Signature is REQUIRED and contains an algorithm identifier to denote the algorithm used by the issuer to sign the certficate. The two algorithm identifers used by Suite B are ecdsa-with-SHA256 and ecdsa-with-SHA384 [X9.62], Section E.8. 4.1.2.4. Issuer Issuer is REQUIRED and MUST follow [RFC5280], Section 4.1.2.4. 4.1.2.5. Validity Validity is required and MUST follow [RFC5280], Section 4.1.2.5. Solinas, Zieglar [Page 9] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 4.1.2.6. Subject Subject is REQUIRED and MUST follow [RFC5280], Section 4.1.2.6. 4.1.2.7. SubjectPublicKeyInfo SubjectPublicKeyInfo is REQUIRED and MUST follow [RFC5280], Section 4.1.2.7. SubjectPublicKeyInfo will contain the Elliptic Curve public key and usually the algorithm with which the key is used. The following conditions apply: * For ECDSA signing keys, the algorithm ID, id-ecPublicKey, MUST be used, indicating unrestricted algorithm usage of the public key [RFC3279], Section 2.3.5. * For ECDH key establishment keys, the algorithm ID, id-ecPublicKey, MUST be supported. The algorithm ID, id-ecDH, MAY be supported, [DRAFT3279bis], Section 2.1. * The intended application for the pulbic key is indicated in the key usage extension that is described in Section 4.2.3.1 of this document. * The parameters of the AlgorithmIdentifier of the subjectPublicKeyInfo MUST use the namedCurve option; the ecParameters and implicitlyCA options MUST NOT be used [RFC3279], Section 2.3.5. * The namedCurve MUST be either the OID for secp256r1 (P-256 curve) or secp384r1 (P-384 curve) [SEC2], Section A.2.1. The elliptic curve public key, ECPoint, SHALL be the octet string representation of an elliptic curve point following the conversion routine in [X9.63], Section 4.3.6, and [RFC3279], Section 2.3.5. * Suite B implementations MUST support the uncompressed form of the elliptic curve point [X9.63], Section 4.3.6. Suite B certificates MAY suppport the compressed form of the elliptic curve point [x9.63], Section 4.3.6. * 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], Section 2.3.5. 4.1.2.8. Unique Identifiers IssuerUniqueID and SubjectUniqueID MUST NOT be used in Suite B certificates [RFC5280], Section 4.1.2.8. Solinas, Zieglar [Page 10] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 4.2. Certificate Extensions The following sections specify the REQUIRED and RECOMMENDED extensions for the different types of Suite B certificates. All other extensions that are not described in this profile should be considered OPTIONAL; their inclusion or exclusion and their values will depend upon the particular application or profile incorporating this Suite B Certificate and CRL profile as a base. 4.2.1. Suite B Root CA Self-Signed The following extensions MUST be included in Suite B Root CA Self- Signed Certificates: subjectKeyIdentifer, keyUsage, and basicConstraints [RFC5280], Section 4.2. Specifically, * The subjectKeyIdentifier extension MUST be marked as non-critical. Its value will be computed following the guidance in [RFC5280], Section 4.2.1.2. * The keyUsage extension MUST be marked as critical and MUST be set for keyCertSign and cRLSign [RFC5280], Section 4.2.1.3. * The basicConstraints extension MUST be marked as critical, the cA bit subfield MUST be set to indicate that the subject is a CA and the pathLenConstraint subfield MUST NOT be set [RFC5280], Section 4.2.1.9. * The certificatePolicies extension MUST be marked as non-critical, MUST contain the OID for the applicable certificate policy and SHOULD NOT us the policyQualifiers option [RFC5280], Section 4.2.1.4. Following the guidance in section 4.2.1.4 of [RFC5280], when a CA does not wish to limit the set of policies for certification paths that include this certificate, it MAY assert the special policy anyPolicy, with a value of {2 5 29 32 0}. 4.2.2. Suite B Subordinate CA Certificates Extensions for subordinate CA certificates are detailed in the following sections: 4.2.2.1. REQUIRED Extensions The following extensions MUST be included in Suite B Subordinate CA Certificates: authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, basicConstraints and certificatePolicies [RFC5280], Section 4.2. Solinas, Zieglar [Page 11] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Specifically, * The authorityKeyIdentifier extension MUST be marked as non-critical and MUST include the keyIdentifier field. The value of the keyIdentifier field will be computed following the guidance in [RFC5280], Section 4.2.1.1. * The subjectKeyIdentifier extension MUST be marked as non-critical and its value will be computed following the guidance in [RFC5280], Section 4.2.1.2. * The keyUsage extension MUST be marked as critical and MUST be set for keyCertSign and cRLSign [RFC5280], Section 4.2.1.3. * The basicConstraints extension MUST be marked as critical, the cA bit subfield MUST be set to indicate that the subject is a CA and the pathLenConstraint subfield is OPTIONAL [RFC5280], Section 4.2.1.9. 4.2.2.2. RECOMMENDED Extensions The following extensions are RECOMMENDED in CA Cross-Certificates: policyMappings, policyConstraints and inhibitAnyPolicy [RFC5280], Section 4.2. Specifically, * The policyMappings extension MUST NOT be marked as critical. Following the guidance in [RFC5280], Section 4.2.1.5, policies MUST NOT be mapped to either to or from the special value anyPolicy. * The policyConstraints extension MUST be marked as critical. The requireExplicitPolicy and inhibitPolicyMapping fields MUST be set to zero [RFC5280], Section 4.2.1.11. * The inhibitAnyPolicy extension MUST be marked as critical. SkipCerts MUST be set to zero [RFC5280], Section 4.2.1.14. 4.2.3. Suite B CA Cross-Certificates Extensions for CA cross-certificates are detailed in the following sections: 4.2.3.1. REQUIRED Extensions The following extensions MUST be included in Suite B CA cross-certificates: authorityKeyIdentifier, subjectKeyIdentifier, keyUsage, basicConstraints and certificatePolicies [RFC5280], Section 4.2. Solinas, Zieglar [Page 12] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Specifically, * The authorityKeyIdentifier extension MUST be marked as non-critical and MUST include the keyIdentifier field. The value of the keyIdentifier field will be computed following the guidance in [RFC5280], Section 4.2.1.1. * The subjectKeyIdentifier extension MUST be marked as non-critical and its value will be computed following the guidance in [RFC5280], Section 4.2.1.2. * The keyUsage extension MUST be marked as critical and MUST be set for keyCertSign and cRLSign [RFC5280], Section 4.2.1.3. * The basicConstraints extension MUST be marked as critical, the cA bit subfield MUST be set to indicate that the subject is a CA and the pathLenConstraint subfield MUST NOT be set [RFC5280], Section 4.2.1.9. * 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 [RFC5280], Section 4.2.1.4. 4.2.3.2. RECOMMENDED Extensions The following extensions are RECOMMENDED in CA cross-certificates: policyMappings, policyConstraints, and inhibitAnyPolicy {RFC5280], Section 4.2. Specifically, * The policyMappings extension MUST NOT be marked as critical. Following the guidance in [RFC5280], Section 4.2.1.5, policies MUST NOT be mapped either to or from the special value anyPolicy. * The policyConstraints extension MUST be marked as critical. The requireExplicitPolicy and inhibitPolicyMapping fields MUST be set to zero [RFC5280], Section 4.2.1.11. * The inhibitAnyPolicy extension MUST be marked as critical. SkipCerts MUST be set to zero [RFC5280], Section 4.2.1.14. 4.2.4. Suite B End Entity Signature and Key Establishment Certificates Extensions for end entity certificates are detailed in the following sections: 4.2.4.1. REQUIRED Extensions The following extensions MUST be included in Suite B End Entity Signature and Key Establishment certificates: authorityKeyIdentifier, keyUsage and certificatePolicies [RFC5280], Section 4.2. Solinas, Zieglar [Page 13] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Specifically, * The authorityKeyIdentifier extension MUST be marked as non-critical and MUST include the keyIdentifier field. The value of the keyIdentifier field will be computed following the guidance in [RFC5280], Section 4.2.1.1. * The keyUsage extension MUST be marked as critical and MUST be set for digitalSignature for end-entity signature certificates or for keyAgreement for end entity key establishment certificates [RFC5280], Section 4.2.1.3. * 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 [RFC5280], Section 4.2.1.4. Following the guidance in [RFC5280], Section 4.2.1.4, the special policy, anyPolicy, with a value of {2 5 29 32 0} MAY be included in this certificate. If the subject name is an empty sequence, then the subjectAltName extension MUST be added in Suite B End Entity Signature and Key Establishment Certificates and MUST be marked as critical [RFC5280], Section 4.2.1.6. The subjectAltName extension is OPTIONAL otherwise and if included, MUST be marked as non-critical. 4.2.4.2. RECOMMENDED Extensions The following extension is RECOMMENDED in Suite B End Entity Signature and Key Establishment Certificates: subjectKeyIdentifer. * The subjectKeyIdentifier extension MUST be marked as non-critical and its value will be computed following the guidance in [RFC5280], Section 4.2.1.2. 5. Certificate Revocation List (CRL) and CRL Extensions Profile The basic X.509 Certificate Revocation List (CRL) is as follows [RFC5280], Section 5.1: CertificateList ::= SEQUENCE { tbsCertList TBSCertList signatureAlgorithm AlgorithmIdentifier signatureValue BIT STRING } Solinas, Zieglar [Page 14] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 TBSCertList ::= SEQUENCE { version Version OPTIONAL; if present, MUST be v2 signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL; -- if present, MUST be v2 } OPTIONAL crlExtensions [0] EXPLICIT Extensions OPTIONAL -- if present, MUST be v2 } CertifiateList is REQUIRED and MUST include the three fields: tbsCertList, signatureAlgorithm, and signatureValue. 5.1. CRL Fields Suite B CRL fields are described as follows: 5.1.1. TBSCertList Fields TBSCertList fields are described as follows: 5.1.1.1. Version Version is REQUIRED and MUST be set to 1 to denote version 2 CRLs per [RFC5280], Section 5.1.2.1. 5.1.1.2. Signature Signature is REQUIRED and contains an algorithm identifer to denote the algorithm used by the issuer to sign the CRL. The two algorithm identifiers used by Suite B are ecdsa-with-SHA256 and ecdsa-with-SHA384 [X9.62], Section E.8. 5.1.1.3. Issuer Issuer is REQUIRED and MUST follow [RFC5280], Section 5.1.2.3. 5.1.1.4. ThisUpdate ThisUpdate follows [RFC5280] and indicates the date that this CRL was issued [RFC5280], Section 5.1.2.4. Solinas, Zieglar [Page 15] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 5.1.1.5. NextUpdate NextUpdate follows [RFC5280] and indicates the date by which the next CRL will be issued [RFC5280], Section 5.1.2.5. 5.1.1.6. RevokedCertificates RevokedCertificates follows [RFC5280], Section 5.1.2.6. 5.1.2. SignatureAlgorithm and SignatureValue Fields The signatureAlgorithm and signatureValue fields of the Suite B CRL follow the previous description for these fields in the X.509 Suite B Certificate Profile, Sections 4.1.1.2 and 4.1.1.3 of this document. The signatureAlgorithm and signatureValue fields in the Certificate and CertificateList sequences, the signature and subjectPublicKeyInfo in the TBSCertificate subcomponent, and the signature in the TBSCertList subcomponent MUST identify Suite B through the use of algorithm identifiers. The primary OID structure for Suite B is as follows [X9.62], [SEC2], [RFC3279], and [RFC5280]. ansi-X9-62 OID::={iso(1) member-body(2) us(840) 10045} certicom-arc OID::={iso(1) identified-organization(3) certicom(132)} id-ecPublicKey OID::={ansi-X9.62 keyType(2) 1} id-ecDh OID::={certicom-arc schemes(1) ecdh(12)} secp256r1 OID::={ansi-X9-62 signatures(4)} secp384r1 OID::={certiciom-arc curve(0) 34} id-ecSigType OID::={ansi X9.62 signatures(4)} ecdsa-with-SHA256 OID::={id-ecSigType specified(3) 2} ecdsa-with-SHA384 OID::={id-ecSigType specified(3) 3} 5.2 CRL Extensions CrlExtensions MUST include the authority key identifier and the CRL Number extensions [RFC5280], Section 5.2. Solinas, Zieglar [Page 16] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 In particular, * The authorityKeyIdentifier extension MUST be marked as non-critical and MUST use the keyIdentifier field [RFC5280], Section 5.2.1. The value of the keyIdentifier field will be computed following the guidance in [RFC5280], Section 4.2.1.1. * The crlNumber extension MUST be marked as non-critical and follows [RFC5280], Section 5.2.3. All extensions not described in this profile should be considered OPTIONAL; their inclusion or exclusion and their values will depend on the particular application or environment incorporating this Suite B Certificate and CRL profile as a base. 6. Security Considerations The security considerations in [RFC5280] and [DRAFT3279bis] apply. A single key pair MUST NOT be used for both signature and key establishment. 7. IANA Considerations This document makes extensive use of object identifiers to register public key types, elliptic curves, and algorithms. Most 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 adopeted 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 [Page 17] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 8. References 8.1. Normative [DRAFT3279bis] Turner, S., Brown, D., Yiu, K., Housely, R., Polk, T., "Elliptic Curve Cryptography Subject Public Key Information", draft-ietf-pkix-ecc-subpublkeyinfo-10.txt, December 2008. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [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. [RFC4492] Blake-Wilson, S., Bolyard, N. Gupta, V., Hawk, C., Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", May 2006. [RFC4869] Law, L., Solinas, J., "Suite B Cryptographic Suites for IPsec", RFC4869, May 2007. [RFC5008] Housley, R., "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", September 2007. [RFC5272] Schaad, J., Myers, M., "Certificate Management Messages over CMS (CMC)", RFC 5272, June 2008. [RFC5280] Cooper, D., Santesson, S. Farrell., S., Boeyen, S., Housely, R., Polk, W., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [SEC2] Standards for Efficient Cryptography, "SEC 2: Recommended Elliptic Curve Domain Parameters", September 2000. [SP-800-56A] Barker, E., Johnson, D., Smid, M., "NIST SP-800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", March 2007. [SuiteBTLS] Rescorla, E., Salter, M., Housley, R., "Suite B Profile for Transport Layer Security (TLS)", draft-rescorla-tls-suiteb-11.txt, November 2008. [X9.62] ANS X9.62, "Public Key Cryptography for the Financial Services Industry; The Elliptic Curve Digital Signature Algorithm (ECDSA)", December 2005. Solinas, Zieglar [Page 18] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 [X9.63] ANS X9.63, "Public Key Cryptography for the Financial Services Industry; Key Agreement and Key Transport Using Elliptic Curve Cryptography", December 2001. 8.2 Informative [CASE] "The Case for Elliptic Curve Cryptography", (http://www.nsa.gov/ia/indutsry/crypto_elliptic_curve.cfm). [RFC4251] Ylonen, T., Lonvick, C., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC5272] Myers, M., Schaad, J., "Certificate Management Messages over CMS (CMC)", RFC 5272, June 2008. [RFC5273] Schaad, J., Myers, M., "Certificate Management Messsages over CMS (CMC): Transport Protocols", RFC 5273, June 2008. [RFC5274] Schaad, J., Myers, M., "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008. [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode", RFC 5289, August 2008. [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. [SuiteB] U.S. National Security Agency, "Fact Sheet NSA Suite B Cryptography", July 2005. (http://www.nsa.gov/ia/industry/crypto_Suite_b.cfm?MenuID=10.2.7) Solinas, Zieglar [Page 19] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Appendix A. A.1. Reference Sections for Certificate Fields Referenced Requirement or Component Standard Section Recommendation --------- -------- ------- -------------- version RFC5280 4.1.2.1 Set to 2 for Version 3 Certificates. serialNumber RFC5280 4.1.2.2 SHALL be a positive (non-negative integer) and SHALL NOT be longer that 20 octets. signature X9.62 E.8 OIDs for ECDSA with SHA-256 OR ECDSA with SHA-384. issuer RFC5280 4.1.2.4 Follows guidance in RFC5280. validity RFC5280 4.1.2.5 Follows guidance in RFC5280. subject RFC5280 4.1.2.6 Follows guidance in RFC5280. subjectPublicKeyInfo: RFC5280 4.1.2.7 The algorithm identifer AlgorithmIdentifer RFC3279 2.3.5 uses the OIDs for ECDSA X9.62 E.7 and ECDH public keys DRAFT3279bis 2.1.2 and OIDs for P-256 and P-384 curves in the algorithm and parameter subfields. subjectPublicKeyInfo: X9.63 4.3.6 First byte is 0x00 subjectPublicKey RFC3279 2.3.5 (number of unused bits in last octet); 2nd byte is 0x04 for uncompressed; followed by 256(384) bits for x-coordinate; 256(384) bits for y-coordiante for P-256 and P-384 curves, respectively. Solinas, Zieglar [Page 20] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Referenced Requirement or Component Standard Section Recommendation --------- -------- ------- -------------- authorityKeyIdentifier RFC5280 4.2.1.1 Follows guidance in RFC5280; criticality is FALSE. subjectKeyIdentifier RFC5280 4.2.1.2 Follows guidance in RFC5280; criticality is FALSE. keyUsage RFC5280 4.2.1.3 Set keyCertSign and cRLSign bits for Root CA Self-Signed certificate, Subordinate CA certificate and Cross-Certificate; sets digitalSignature for end entity Signature certificate; sets keyAgreement for end entity key establishment certificate; criticality is TRUE. certificatePolicies RFC5280 4.2.1.4 Set to OID for particular certificate policy in use; can use the anyPolicy OID; policyQualifiers is NOT RECOMMENDED; criticality is FALSE. basicConstraints RFC5280 4.2.1.9 Sets the cA bit in root CA self-signed certificate, subordinate CA certificate and cross- certificate; criticaility is TRUE; pathLenConstraint is not set in CA root self-signed nor CA cross-certificates; is optional in CA subordinate certificates. Solinas, Zieglar [Page 21] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Referenced Requirement or Component Standard Section Recommendation --------- -------- ------- -------------- policyMappings RFC5280 4.2.1.5 Recommended for CA cross-certificates; criticality is FALSE; policies MUST NOT be mapped either to or from anyPolicy. policyConstraints RFC5280 4.2.1.11 Recommended for CA cross-certificates; criticality is TRUE; requireExplicitPolicy and inhibitPolicyMapping MUST be set to zero. inhibitAnyPolicy RFC5280 4.2.1.14 Recommended for CA cross-certificates; criticality is TRUE; SkipCerts MUST be set to zero. subjectAltName RFC5280 4.2.1.6 In end entity certificates, if subject name is empty sequence, MUST include subjectAltName; criticality is then TRUE; otherwise FALSE. signatureAlgorithm RFC5280 4.1.1.2 OIDs for ECDSA with X9.62 E.8 SHA-256 or ECDSA with SHA-384 signatureValue RFC5280 4.1.1.3 Encoded BIT STRING X9.62 7 value of a DER ASN.1 5.4.5.7 encoded SEQUENCE of two INTEGERS; each a maximum of 33 (49) bytes for P-256 and P-384, respectively. Solinas, Zieglar [Page 22] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 A.2. Reference Sections for CRL Fields Referenced Requirement or Component Standard Section Recommendation --------- -------- ------- ---------------------- version RFC5280 5.1.2.1 Set to 1 for Version 2 certificates. signature X9.62 E.8 OIDs for ECDSA with SHA-256 or ECDSA with SHA-384. issuer RFC5280 5.1.2.3 Follows guidance in RFC5280. thisUpdate RFC5280 5.1.2.4 Indicates the issue date of this CRL. nextUpdate RFC5280 5.1.2.5 Indicates date by which the next CRL will be issued. revokedCertificates RFC5280 5.1.2.6 List of revoked certificates. authorityKeyIdentifier RFC5280 5.2.1 Follows the guidance in 4.2.1.1 RFC5280; criticality is FALSE. cRLNumber RFC5280 5.2.3 A monotonically increasing sequence number for a given CRL scope and issuer; criticality is FALSE. signatureAlgorithm RFC5280 5.1.1.2 OIDs for ECDSA with X9.62 E.8 SHA-256 or ECDSA with SHA-384. signatureValue RFC5280 5.1.1.3 Encoded BIT STRING value X9.62 7 of a DER encoded ANS.1 5.4,5.7 SEQUENCE of two INTEGERS; each a maximum of 33 (49) bytes for P-256 and P-384 respectively. Solinas, Zieglar [Page 23] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Appendix B. Certificate Field Values B.1. Root CA Self-Signed Certificate using P-256 Signed with P-256 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.2 ECDSA with SHA-256 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; must match the issuer name, MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 Solinas, Zieglar [Page 24] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE MUST NOT be set. Value:pathLenConstraint {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.2 ECDSA with SHA-256 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 33 bytes. B.2. Root CA Self-Signed Certificate using P-384 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; must match the issuer name, MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.3.132.0.34 P-384 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (784 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 384-bit x-coordinate and 384-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Solinas, Zieglar [Page 25] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- Required Extensions: subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE MUST NOT be set. Value:pathLenConstraint {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. B.3. Subordinate CA Certificate using P-256 Signed with P-256 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.2 ECDSA with SHA-256 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option Solinas, Zieglar [Page 26] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE is OPTIONAL. Value:pathLenConstraint certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 CriticaL FALSE Value OID {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.2 ECDSA with SHA-256 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 33 bytes. Solinas, Zieglar [Page 27] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 B.4. Subordinate CA Certificate using P-384 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.3.132.0.34 P-384 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (784 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 384-bit x-coordinate and 384-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 Solinas, Zieglar [Page 28] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE is OPTIONAL. Value:pathLenConstraint certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 Critical FALSE Value OID {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. B.5. Subordinate CA Certificate using P-256 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Solinas, Zieglar [Page 29] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE is OPTIONAL. Value:pathLenConstraint certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 CriticaL FALSE Value OID {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. Solinas, Zieglar [Page 30] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 B.6. CA Cross-Certificate Using P-256 Signed with P-256 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.2 ECDSA with SHA-256 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 Solinas, Zieglar [Page 31] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE MUST NOT be set. Value:pathLenConstraint certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 CriticaL FALSE Value OID Recommended Extensions: policyMappings Follows RFC5280 Identifier 2.5.29.33 Critical FALSE Value SEQUENCE policyConstraints The requireExplicitPolicy Identifier 2.5.29.36 and inhibitPolicyMapping Critical TRUE fields MUST be set to zero. Value SEQUENCE inhibitAnypolicy SkipCerts MUST be set to Identifer 2.5.29.54 zero. Critical TRUE Value INTEGER {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.2 ECDSA with SHA-256 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 33 bytes. Solinas, Zieglar [Page 32] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 B.7. CA Cross-Certificate Using P-384 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.3.132.0.34 P-384 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (784 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 384-bit x-coordinate and 384-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 Solinas, Zieglar [Page 33] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE MUST NOT be set. Value:pathLenConstraint certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 CriticaL FALSE Value OID Recommended Extensions: policyMappings Follows RFC5280 Identifier 2.5.29.33 Critical FALSE Value SEQUENCE policyConstraints The requireExplicitPolicy Identifier 2.5.29.36 and inhibitPolicyMapping Critical TRUE fields MUST be set to zero. Value SEQUENCE inhibitAnypolicy SkipCerts MUST be set to Identifer 2.5.29.54 zero. Critical TRUE Value INTEGER {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. Solinas, Zieglar [Page 34] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 B.8. CA Cross-Certificate Using P-256 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; MUST be non-empty field. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING subjectKeyIdentifier: Follows RFC5280 Identifer 2.5.29.14 Critical FALSE Value OCTET STRING keyUsage: keyCertSign and crlSign bits Identifer 2.5.29.15 are set. Value is a DER Critical TRUE encoded BIT STRING Value 03 02 01 06 Solinas, Zieglar [Page 35] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- basicConstraints: cA bit is set to TRUE to Identifier 2.5.29.19 indicate that the subject Critical TRUE is a CA; pathLenConstraint Value:cA TRUE MUST NOT be set. Value:pathLenConstraint certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 Critical FALSE Value OID Recommended Extensions: policyMappings Follows RFC5280 Identifier 2.5.29.33 Critical FALSE Value SEQUENCE policyConstraints The requireExplicitPolicy Identifier 2.5.29.36 and inhibitPolicyMapping Critical TRUE fields MUST be set to zero. Value SEQUENCE inhibitAnypolicy SkipCerts MUST be set to Identifer 2.5.29.54 zero. Critical TRUE Value INTEGER {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. Solinas, Zieglar [Page 36] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 B.9. End Entity Signature Certificate Using P-256 Signed with P-256 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.2 ECDSA with SHA-256 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; if empty, must contain the subjectAltName extension. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING keyUsage: digitalSignature bit is Identifer 2.5.29.15 set. Value is a DER Critical TRUE encoded BIT STRING. Value 03 02 07 80 certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 Critical FALSE Value OID Solinas, Zieglar [Page 37] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- subjectAltName If the subject name is an Identifier 2.5.29.17 empty sequence, then the Critical TRUE or FALSE subjectAltName extension Value OID must be included and the criticality flag marked TRUE. Otherwise, this extension is optional and if included, the criticality flag is marked FALSE. Recommended Extension: subjectKeyIdentifier Follows RFC5280 Identifier 2.5.29.14 Critical FALSE Value OCTET STRING {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.2 ECDSA with SHA-256 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 33 bytes. B.10. End Entity Signature Certificate Using P-384 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; if empty, must contain the subjectAltName extension. Solinas, Zieglar [Page 38] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.3.132.0.34 P-384 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (784 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 384-bit x-coordinate and 384-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING keyUsage: digitalSignature bit is Identifer 2.5.29.15 set. Value is a DER Critical TRUE encoded BIT STRING. Value 03 02 07 80 certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 Critical FALSE Value OID subjectAltName If the subject name is an Identifier 2.5.29.17 empty sequence, then the Critical TRUE or FALSE subjectAltName extension Value OID must be included and the criticality flag marked TRUE. Otherwise, this extension is optional and if included, the criticality flag is marked FALSE. Solinas, Zieglar [Page 39] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- Recommended Extension: subjectKeyIdentifier Follows RFC5280 Identifier 2.5.29.14 Critical FALSE Value OCTET STRING {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. B.11. End Entity Signature Certificate Using P-256 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; if empty, must contain the subjectAltName extension. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Solinas, Zieglar [Page 40] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING keyUsage: digitalSignature bit is Identifer 2.5.29.15 set. Value is a DER Critical TRUE encoded BIT STRING. Value 03 02 07 80 certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 Critical FALSE Value OID subjectAltName If the subject name is an Identifier 2.5.29.17 empty sequence, then the Critical TRUE or FALSE subjectAltName extension Value OID must be included and the criticality flag marked TRUE. Otherwise, this extension is optional and if included, the criticality flag is marked FALSE. Recommended Extension: subjectKeyIdentifier Follows RFC5280 Identifier 2.5.29.14 Critical FALSE Value OCTET STRING {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. Solinas, Zieglar [Page 41] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 B.12. End Entity Key Establishment Certificate Using P-256 Signed with P-256 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.2 ECDSA with SHA-256 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; if empty, must contain the subjectAltName extension. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key MAY use id-ecDH=(1.3.132.1.12) AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for (528 bits) number of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING keyUsage: Key agreement bit is set. Identifer 2.5.29.15 Value is a DER encoded BIT Critical TRUE STRING. Value 03 02 03 08 certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 Critical FALSE Value OID Solinas, Zieglar [Page 42] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- subjectAltName If the subject name is an Identifier 2.5.29.17 empty sequence, then the Critical TRUE or FALSE subjectAltName extension Value OID must be included and the criticality flag marked TRUE. Otherwise, this extension is optional and if included, the criticality flag is marked FALSE. Recommended Extension: subjectKeyIdentifier Follows RFC5280 Identifier 2.5.29.14 Critical FALSE Value OCTET STRING {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.2 ECDSA with SHA-256 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 33 bytes. B.13. End Entity Key Establishment Certificate Using P-384 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; if empty, must contain the subjectAltName extension. Solinas, Zieglar [Page 43] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key MAY use id-ecDH=(1.3.132.1.12) AlgorithmIdentifer:parameters 1.2.132.0.34 P-384 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for number (784 bits) of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 384-bit x-coordinate and 384-bit y-coordinate. Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING keyUsage: Key agreement bit is set. Identifer 2.5.29.15 Value is a DER encoded BIT Critical TRUE STRING. Value 03 02 03 08 certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 CriticaL FALSE Value OID subjectAltName If the subject name is an Identifier 2.5.29.17 empty sequence, then the Critical TRUE or FALSE subjectAltName extension Value OID must be included and the criticality flag marked TRUE. Otherwise, this extension is optional and if included, the criticality flag is marked FALSE. Solinas, Zieglar [Page 44] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- Recommended Extension: subjectKeyIdentifier Follows RFC5280 Identifier 2.5.29.14 Critical FALSE Value OCTET STRING {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. B.14. End Entity Key Establishment Certificate Using P-256 Signed with P-384 Field Value Comments ----- ----- -------- tbsCertificate: version 2 Value=0x02 for version 3 certificates. serialNumber INTEGER Follows RFC5280. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. validity Follows RFC5280. subject Follows RFC5280; if empty, must contain the subjectAltName extension. subjectPublicKeyInfo: AlgorithmIdentifer:algorithm 1.2.840.10045.2.1 EC public key MAY use id-ecDH=(1.3.132.1.12) AlgorithmIdentifer:parameters 1.2.840.10045.3.1.7 P-256 curve named curve option subjectPublicKey BIT STRING First byte is 0x00 for number (528 bits) of unused bits in last octet; second byte is 0x04 to denote uncompressed format. Followed by 256-bit x-coordinate and 256-bit y-coordinate. Solinas, Zieglar [Page 45] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- Unique Identifiers: issuerUniqueID Not present subjectUniqueID Not present Required Extensions: authorityKeyIdentifier: Follows RFC5280 Identifier 2.5.29.35 Critical FALSE Value OCTET STRING keyUsage: Key agreement bit is set. Identifer 2.5.29.15 Value is a DER encoded BIT Critical TRUE STRING. Value 03 02 03 08 certificatePolicies: Follows RFC5280 Identifier 2.5.29.32 Critical FALSE Value OID subjectAltName If the subject name is an Identifier 2.5.29.17 empty sequence, then the Critical TRUE or FALSE subjectAltName extension Value OID must be included and the criticality flag marked TRUE. Otherwise, this extension is optional and if included, the criticality flag is marked FALSE. Recommended Extension: subjectKeyIdentifier Follows RFC5280 Identifier 2.5.29.14 Critical FALSE Value OCTET STRING {end tbsCertificate} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS; each a maximum of 49 bytes. Solinas, Zieglar [Page 46] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Appendix C. Certificate Revocation List (CRL) Field Values C.1. Certificate Revocation List (CRL) Signed with P-256 Field Value Comments ----- ----- -------- tbsCertList: version 1 Value=0x01 for version 2 CRL. signature 1.2.840.10045.4.3.2 ECDSA with SHA-256 issuer Follows RFC5280. thisUpdate Follows RFC5280. nextUpdate Follows RFC5280. revokedCertificates Follows RFC5280. Required CRL Extensions: authorityKeyIdentifer Identifier 2.5.29.35 Follows RFC5280. Critical FALSE Value INTEGER cRLNumber Follows RFC5280. Identifier 2.5.29.20 Critical FALSE Value INTEGER {end tbsCertList} signatureAlgorithm 1.2.840.10045.4.3.2 ECDSA with SHA-256 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS each a maximum of 33 bytes. C.2. Certificate Revocation List (CRL) Signed with P-384 Field Value Comments ----- ----- -------- tbsCertList: version 1 Value=0x01 for version 2 CRL. signature 1.2.840.10045.4.3.3 ECDSA with SHA-384 issuer Follows RFC5280. thisUpdate Follows RFC5280. nextUpdate Follows RFC5280. revokedCertificates Follows RFC5280. Solinas, Zieglar [Page 47] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 Field Value Comments ----- ----- -------- Required CRL Extensions: authorityKeyIdentifer Follows RFC5280. Identifier 2.5.29.35 Critical FALSE Value INTEGER cRLNumber Follows RFC5280. Identifier 2.5.29.20 Critical FALSE Value INTEGER {end tbsCertList} signatureAlgorithm 1.2.840.10045.4.3.3 ECDSA with SHA-384 signatureValue BIT STRING Encoded BIT STRING value of a DER encoded SEQUENCE of two INTEGERS each a maximum of 49 bytes. Solinas, Zieglar [Page 48] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 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 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Solinas, Zieglar [Page 49] INTERNET-DRAFT Suite B Certificate and CRL Profile December 2008 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Expires June 5, 2009 Solinas, Zieglar [Page 50]