RFC 5759

Suite B Certificate and Certificate Revocation List (CRL) Profile

📅 published January 2010, from ietf

RFC 5759: Suite B Certificate and Certificate Revocation List (CRL) Profile 🎀

Okay bestie, let's get into this one 💅 Here's the header tea:

  • Series: Internet Engineering Task Force (IETF) 🦋
  • Authors: J. Solinas and L. Zieglar, with L. Zieglar listed at the NSA 🧚
  • Category: Informational 📚
  • ISSN: 2070-1721
  • Date: January 2010 📅
  • Obsoletes/Updates: the header doesn't list anything it obsoletes or updates ✨

Abstract 💖

So this doc lays out a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs), made for use with the United States National Security Agency's Suite B Cryptography 🔐. It assumes you already know RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", so don't skip that one 🙈

Status of This Memo 📝

This is not an Internet Standards Track specification. It's published for informational purposes, so it's giving "good to know" vibes 📚

It's a product of the IETF, it represents the consensus of the IETF community, it got public review, and the IESG approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5759 🔗

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Read them carefully, because they spell out your rights and restrictions for this document ⚖️

If you pull Code Components out of this document, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, as the Simplified BSD License describes 💜

Table of Contents 🧾

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

1. Introduction 🌸

This doc lays out a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs), for use by apps that support the United States National Security Agency's Suite B Cryptography 🔐

You're assumed to know [RFC5280], and this Suite B Certificate and CRL Profile is a profile of RFC 5280. All MUST-level requirements of RFC 5280 apply throughout this profile, and they're generally not repeated here 🫶 When a MUST-level requirement gets repeated for emphasis, the text says it's "in adherence with [RFC5280]".

Here's the plot twist: this profile bumps some MAY-level options in RFC 5280 up to SHOULD-level and MUST-level. It also bumps some SHOULD-level options in RFC 5280 up to MUST-level for this profile 👑 Any RFC 5280 options that aren't listed in this profile keep the requirement level they have in RFC 5280 ✨

You're also assumed to know [RFC5480], which covers the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography, and [RFC5758], which covers algorithm identifiers for Elliptic Curve Digital Signature Algorithm (ECDSA) 🧚

2. Conventions Used in This Document 📖

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

3. Requirements and Assumptions 💅

The goal here is simple: define a base set of certificate and CRL formats so Suite B solutions can work together 🦋 Specific communities, like the US National Security Systems, can write community profiles that restrict certificate and CRL formats further. They can do that by requiring extensions that are optional in this base profile, defining new optional or critical extension types, or restricting the values and/or presence of fields in existing extensions.

Now the important bit 🚨 Communications between distinct communities MUST use the formats in this document when interoperability is desired. (Apps can add extra non-critical extensions to these formats, but they MUST NOT assume a remote peer can process them. Don't be that person 🙈)

3.1. Implementing Suite B 🔥

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

  • An ECDSA-capable signing key, using curve P-256 or P-384; or
  • An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment key, using curve P-256 or P-384.

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

3.2. Suite B Object Identifiers 🧾

Here's the primary OID structure for Suite B, per [X9.62], [SEC2], [RFC5480], and [RFC5758]. It's a lot of numbers, but they're the building blocks, so 🧚

ansi-X9-62 OBJECT IDENTIFIER ::= {
   iso(1) member-body(2) us(840) 10045 }

certicom-arc OBJECT IDENTIFIER ::= {
   iso(1) identified-organization(3) certicom(132) }

id-ecPublicKey OBJECT IDENTIFIER ::= {
   ansi-X9-62 keyType(2) 1 }

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

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

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

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

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

4. Suite B Certificate and Certificate Extensions Profile 💖

This Suite B certificate profile is a profile of [RFC5280], and the changes from RFC 5280's requirements are listed here ✨ Heads up: RFC 5280 has varying mandates for marking extensions as critical or non-critical. This profile changes some of those mandates for extensions that show up in Suite B certificates 🙈

4.1. signatureAlgorithm 🖋️

The two algorithm identifiers Suite B uses are 1.2.840.10045.4.3.2 for ecdsa-with-SHA256 and 1.2.840.10045.4.3.3 for ecdsa-with-SHA384, as described in [RFC5758] AND [X9.62] 💅

The parameters MUST be absent, as per [RFC5758] 🔐

4.2. signatureValue ✍️

ECDSA digital signature generation is described in [FIPS186-3] 🤓 An ECDSA signature value is made of two unsigned integers, called r and s. r and s MUST be represented as ASN.1 INTEGERs. If the high order bit of the unsigned integer is a 1, an octet with the value 0x00 MUST be prepended to the binary representation before it's encoded 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. So converting each r and s to an ASN.1 INTEGER gives a maximum of 33 bytes for the P-256 curve and 49 bytes for the P-384 curve 🧮

The ECDSA signatureValue in an X.509 certificate is encoded as a BIT STRING value of a DER-encoded SEQUENCE of the two INTEGERS. As per [RFC5480], the structure (included for convenience) looks like this:

ECDSA-Sig-Value ::= SEQUENCE {
    r  INTEGER,
    s  INTEGER
  }

Here's an example using P-256 in hex notation. Honestly it's giving math homework, but it's worth seeing how it all fits together 🧚

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

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

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

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

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

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

That's the whole signature glow-up 🌈✨

4.3. Version 🎀

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

Part 2 has the CRL profile, the rest of the certificate extensions, and the references, so stay tuned 🧚🫶

4.4. SubjectPublicKeyInfo ✨

okay bestie, for ECDSA signing keys and ECDH key agreement keys, the algorithm ID, id-ecPublicKey, MUST be used 🧚 one ID for both, no cap 💅

the parameters of the AlgorithmIdentifier in this field MUST use the namedCurve option. the specifiedCurve and implicitCurve options described in [RFC5480] MUST NOT be used 🙅‍♀️ the namedCurve MUST be either the OID for secp256r1 (curve P-256) or secp384r1 (curve P-384) [RFC5480] ✨

the elliptic curve public key, ECPoint, SHALL be the OCTET STRING representation of an elliptic curve point, following the conversion routine in section 2.2 of [RFC5480] and sections 2.3.1 and 2.3.2 of [SEC1] 🌸

Suite B implementations MAY use either the uncompressed form or the compressed form of the elliptic curve point [RFC5480]. for interoperability purposes, all relying parties MUST be prepared to process the uncompressed form 🫶 the bestie-safe move is making sure your app can read the uncompressed one, lowkey essential

the elliptic curve public key (an ECPoint that is an OCTET STRING) is mapped to a subjectPublicKey (a BIT STRING) like this: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING, and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING [RFC5480] 🦋

here's an octet string for a P-256 uncompressed elliptic curve point 🍓

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

and the DER-encoded bit string for the subject public key 🎀

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

the DER-encoded AlgorithmIdentifier 💜

30130607 2a8648ce 3d020106 082a8648
ce3d0301 07

and finally, the DER-encoded subjectPublicKeyInfo using the P-256 curve, the whole glow-up 👑

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

4.5. Certificate Extensions for Particular Types of Certificates 🌈

different types of certificates in this profile have different required and recommended extensions, and they're all listed in this section 📋 any extensions from RFC 5280 that aren't explicitly listed in this profile stay at the requirement levels of RFC 5280 ✨

4.5.1. Suite B Self-Signed CA Certificates 👑

in adherence with [RFC5280], self-signed CA certificates in this profile MUST contain the subjectKeyIdentifier, keyUsage, and basicConstraints extensions 🧁

the keyUsage extension MUST be marked as critical. the keyCertSign and cRLSign bits MUST be set. the digitalSignature and nonRepudiation bits MAY be set. all other bits MUST NOT be set 🙈

in adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. the cA boolean MUST be set to indicate that the subject is a CA, and the pathLenConstraint MUST NOT be present 🫠

4.5.2. Suite B Non-Self-Signed CA Certificates 🦄

non-self-signed CA certificates in this profile MUST contain the authorityKeyIdentifier, keyUsage, and basicConstraints extensions. if there is a policy to be asserted, then the certificatePolicies extension MUST be included 📜

the keyUsage extension MUST be marked as critical. the keyCertSign and CRLSign bits MUST be set. the digitalSignature and nonRepudiation bits MAY be set. all other bits MUST NOT be set 💅

in adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. the cA boolean MUST be set to indicate that the subject is a CA, and the pathLenConstraint subfield is OPTIONAL 🌷

if a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies, and SHOULD NOT use the policyQualifiers option. if a policy is not asserted, the certificatePolicies extension MUST be omitted 🎀

relying party applications conforming to this profile MUST be prepared to process the policyMappings, policyConstraints, and inhibitAnyPolicy extensions, regardless of criticality, following the guidance in [RFC5280] when they appear in non-self-signed CA certificates 🫶

4.5.3. Suite B End Entity Signature and Key Establishment Certificates 💖

in adherence with [RFC5280], end entity certificates in this profile MUST contain the authorityKeyIdentifier and keyUsage extensions. if there is a policy to be asserted, then the certificatePolicies extension MUST be included. end entity certificates SHOULD contain the subjectKeyIdentifier extension 🧚

the keyUsage extension MUST be marked as critical 🔥

for end entity digital signature certificates, the keyUsage extension MUST be set for digitalSignature. the nonRepudiation bit MAY be set. all other bits in the keyUsage extension MUST NOT be set 🦋

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

if a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies, and SHOULD NOT use the policyQualifiers option. if a policy is not asserted, the certificatePolicies extension MUST be omitted 🌸

5. Suite B CRL and CRL Extensions Profile 🧾

this Suite B CRL profile is a profile of [RFC5280]. there are changes in the requirements from [RFC5280] for the signatures on CRLs of this profile ✨

the signatures on CRLs in this profile MUST follow the same rules from this profile that apply to signatures in the certificates, see section 4 💜

6. Security Considerations 🚨

the security considerations in [RFC5280], [RFC5480], and [RFC5758] apply. the vibe is serious, so read them 😭

a single key pair SHOULD NOT be used for both signature and key establishment per [SP-800-57]. this one is a big deal, bestie 💀

the Suite B algorithms provide significantly improved performance when compared to equivalent-strength cryptography that does not employ elliptic curve cryptography. where performance has previously been an impediment, use of Suite B may permit employment of PKI-based cryptographic security mechanisms. ⚠️ the speed boost is real, and it can unlock PKI-based security that used to feel impossible 🔐

7. IANA Considerations 🧚

this document makes extensive use of object identifiers to register public key types, elliptic curves, and algorithms. most of them are registered in the ANSI X9.62 arc, with the exception of some of the curves, which are in the Certicom, Inc. arc (these curves have been adopted by ANSI and NIST) 🌈

extensions in certificates and CRLs are identified using the object identifiers defined in an arc delegated by IANA to the PKIX working group. no further action by IANA is necessary for this document or any anticipated updates 🫶

8. References 📚

8.1. Normative References

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

[RFC5758]    Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
             Polk, "Internet X.509 Public Key Infrastructure:
             Additional Algorithms and Identifiers for DSA and
             ECDSA", RFC 5758, January 2010.

8.2. Informative References

[FIPS186-3]  "Digital Signature Standard (DSS)", June 2009.

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

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

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

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

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

Authors' Addresses 🎀

Jerome Solinas
National Information Assurance Research Laboratory
National Security Agency

EMail: jasolin@orion.ncsc.mil


Lydia Zieglar
National Information Assurance Research Laboratory
National Security Agency

EMail: llziegl@tycho.ncsc.mil
📦 where this page comes from