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
<draft-solinas-suiteb-cert-profile-00.txt>
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]
