RFC 9152

Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients

📅 published April 2022, from ietf

Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients 💖

Okay bestie, this one is RFC 9152 🎀 It's an Independent Submission that landed in April 2022 with Category: Informational and ISSN: 2070-1721. The authors are M. Jenkins from the NSA and S. Turner from sn3rd 💅 The title block doesn't list anything it obsoletes or updates, so this doc isn't replacing or patching any other RFC.

Abstract ✨

This doc spells out the protocol interfaces that the United States National Security Agency (NSA) profiled for National Security System (NSS) servers. These servers hand out public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients 🔐 Servers that support these interfaces are called Secure Object Delivery Protocol (SODP) servers. The target audience is developers building client devices that will get key management services from NSA-operated SODP servers 🧚 The interfaces include Enrollment over Secure Transport (EST) and its extensions, plus Certificate Management over CMS (CMC).

This profile covers the capabilities, configuration, and operation of all components of US National Security Systems (SP 800-59). It's also a good fit for other US Government systems that handle high-value information. It's published publicly so that developers and operators of these systems, and of any other deployments, can use it 🦋

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for informational purposes only 🙈

This is a contribution to the RFC Series, made independently of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for more on that 💅

Information about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc9152.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions with respect to this document 📜

Table of Contents 🗂️

   1.  Introduction
     1.1.  Documents to be Familiar With
     1.2.  Document Organization
     1.3.  Environment
   2.  Abstract Syntax Notation One
   3.  EST Interface
     3.1.  Hypertext Transfer Protocol Layer
     3.2.  Transport Layer Security
     3.3.  Eligibility
     3.4.  Authentication
     3.5.  Authorization
     3.6.  EST and EST Extensions
       3.6.1.  /pal
       3.6.2.  /cacerts
       3.6.3.  /simpleenroll
       3.6.4.  /simplereenroll
       3.6.5.  /fullcmc
       3.6.6.  /serverkeygen
       3.6.7.  /csrattrs
       3.6.8.  /crls
       3.6.9.  /symmetrickeys
       3.6.10. /eecerts, /firmware, /tamp
   4.  CMC Interface
     4.1.  RFC 5273 Transport Protocols
     4.2.  Eligibility
     4.3.  Authentication
     4.4.  Authorization
     4.5.  Full PKI Requests/Responses
   5.  Trust Anchor Profile
   6.  Non-Self-Signed Certification Authority Certificate Profile
   7.  End-Entity Certificate Profile
     7.1.  Source of Authority Certificate Profile
     7.2.  Client Certificate Profile
   8.  Relying Party Applications
   9.  CRL Profile
   10. IANA Considerations
   11. Security Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Authors' Addresses

1. Introduction 🌈

This doc spells out the protocol interfaces that the United States National Security Agency (NSA) profiled for National Security System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients. Those servers are called Secure Object Delivery Protocol (SODP) servers 🦋 The point of this document is to list the options from, and the extra requirements on top of, the base specifications in Section 1.1 that clients need in order to interoperate with NSA-operated SODP servers. Clients are always devices, and they don't need to implement every interface here. They get to pick which interfaces they implement based on their operational needs 💅 The interfaces supported by SODP servers include:

  • Enrollment over Secure Transport (EST) [RFC7030] and its extensions [RFC8295], and
  • Certificate Management over CMS (CMC) [RFC5274] [RFC6402] for both Simple Public Key Infrastructure (PKI) requests and responses (i.e., PKCS#10 requests and PKCS#7 responses) and Full PKI requests and responses.

This profile covers the capabilities, configuration, and operation of all components of US National Security Systems [SP-800-59]. It's also a good fit for other US Government systems that process high-value information. It's published publicly so that developers and operators of these systems, and of any other system deployments, can use it 🍓

This profile conforms to the existing requirements of the NSA's Commercial National Security Algorithms (CNSAs). As operational needs change, this profile will be updated to bring in new commercial algorithms and protocols as they're developed and approved for use 🌸

1.1. Documents to be Familiar With 📚

Familiarity with the following specifications is assumed:

The requirements from RFCs apply throughout this profile and generally aren't repeated here. This document is purposely written without using the requirements language described in [RFC2119] and [RFC8174] 🫶

1.2. Document Organization 🗺️

Here's how the doc is laid out:

  • The rest of this section describes the operational environment clients use to retrieve secure objects.
  • Section 2 specifies the Abstract Syntax Notation One (ASN.1) version used.
  • Section 3 specifies SODP's EST interface.
  • Section 4 specifies SODP's CMC interfaces.
  • Sections 5-7 specify Trust Anchor (TA), Certification Authority (CA), and End-Entity (EE) certificates, respectively.
  • Sections 8 and 9 specify Relying Party Applications and CRL Profile, respectively.

1.3. Environment 🧚

Clients get secure "objects" or "packages" from a client-server-based environment. Objects and packages vary based on the Source of Authority (SOA), but every object is "secured" at a minimum through one or more digital signatures and zero or more layers of encryption, as this profile describes 🔐 An SOA is the authority for creating objects that the client will recognize as valid. An SOA can delegate its authority to other actors, and delegation happens through the issuance of certificates. An object or package is the generic term for certificates, certificate status information, and keys (both asymmetric and symmetric). Every object except the certificates and certificate status information is directly encapsulated in, and protected by, CMS content types. CMS content types that provide security are called "CMS-protecting content types", and all others are simply called "CMS content types". Every secured object is distributed either as a CMS package or as part of one 💜

Figure 1 shows two SOAs. One is for symmetric keys, shown as the Key Trust Anchor (KTA). The other is for public key certificates, shown as the PKI Trust Anchor (TA). The KTA creates and distributes symmetric keys. It delegates the creation and distribution jobs to separate entities by issuing certificates to a Key Source Authority (KSA) and a Key Distribution Authority (KDA). The KSA generates the keys, digitally signs them, and encrypts the key for the end client, using CMS content types at each step. The KDA distributes the KSA-generated, KSA-protected key to the client, and the KDA may also sign the key. The resulting CMS package is delivered to the client through the EST extension's /symmetrickey service 🎀 The PKI TA handles the creation, distribution, and management of public key certificates. It delegates those jobs to Certification Authorities (CAs), and the CAs in turn create, distribute, and manage End-Entity (EE) certificates. CAs distribute PKI-related information through the /cacerts, /crls, /eecerts, /fullcmc, /simpleenroll, /simplereenroll, and /csrattrs EST and EST extension services 💖

      +-----+                            +--------+
      | KTA |                            | PKI TA |
      +-----+                            +--------+
         |                                   |
         | Signs                             | Signs
         |                                   |
         +-------------+                     V
         |             |                   +----+
         V             V                   | CA |
      +-----+       +-----+                +----+
      | KSA |       | KDA |                   |
      +-----+       +-----+                   | Signs
         |           |                        |
         | Signs &   | Optionally             +---------------+
         | Encrypts  | Signs                  |               |
         |           |                        V               V
         |           |                +-------------+ +-------------+
         |           V                | Certificate | | Certificate |
     +---|-------------+              +-------------+ | Revocation  |
     |   V             | CMS Content                  | List        |
     | +-------------+ | Types                        +-------------+
     | | Key Package | |
     | +-------------+ |
     +-----------------+

Figure 1: Operating Environment (Key and PKI Sources of Authority)

For clients that support the CMC interface but not the EST interface, the environment includes only the PKI TAs 🦋

2. Abstract Syntax Notation One 🌸

Implementations of this specification use the 2002/2008 ASN.1 version. The 2002/2008 ASN.1 modules can be found in [RFC5911], [RFC5912], and [RFC6268] (use [RFC6268] for the CMS syntax), while other specifications already include the 2002/2008 ASN.1 along with the 1988 ASN.1. See Section 1.1 of [RFC6268] for a discussion of the differences between the 2002 and 2008 ASN.1 versions 💅

3. EST Interface 👑

This section specifies the client options for EST [RFC7030] and EST extensions [RFC8295]. Let's get into it ✨

3.1. Hypertext Transfer Protocol Layer

okay bestie 🎀 so if a client gets a redirect response (3xx status code), it has to terminate the connection 📞💅 that's from [RFC7030], Section 3.2.1 ✨

also, per Section 2.2 of [RFC8295], clients tell the server which format they want the PAL info in (application/xml or application/json) using the HTTP Accept header 🦋 the PAL info itself is described in [RFC8295], Section 2.1.1 💖

3.2. Transport Layer Security

TLS implementations are set up as [RFC9151] describes 🔐 the one big plot twist is that only EC-based algorithms are used 💜

3.3. Eligibility

okay this one is so real 🥹 at the EST interface, servers only enroll clients they already have a prior relationship with, separate from the EST service itself 🫶 so client owners/operators have to show up in person to the human acting as the Registration Authority (RA) and make sure the info in the certificate request (aka the CSR, Certificate Signing Request) is tied to a real client 🧚 how they do that, and what info they share, is totally out of scope here. it could be as simple as the subject name in the CSR, or a copy of the cert that'll verify the request, passed along out of band ✨

3.4. Authentication

mutual authentication happens through "Certificate TLS Authentication" ([RFC7030], Section 2.2.1) 🤝 clients send their certificate in the TLS Certificate message, and that's sent back in response to the server's TLS Certificate Request message 💅 and honestly, both sides throw out any certificate they can't validate back to an installed TA. no drama, just rejection 🙅‍♀️💀

3.5. Authorization

clients always use an explicit TA database ([RFC7030], Section 3.6.1) 📚 at a minimum, clients support two TAs: one for the PKI and one for symmetric keys 🔑✨

clients also check that the server's certificate includes the id-kp-cmcRA Extended Key Usage (EKU) value ([RFC6402], Section 2.10) 👑

and if clients support processing the CMS Content Constraints extension [RFC6010], they make sure returned CMS content comes from an SOA or an entity an SOA authorized for that CMS content 🧐 for SOA certificates, see Section 7.1 🌸

3.6. EST and EST Extensions

this section profiles SODP's interfaces for EST [RFC7030] and EST extensions [RFC8295] 🎀 here comes the endpoint tour, bestie 🧚

3.6.1. /pal

the Package Availability List (PAL) is limited to 32 entries 📋 and the 32nd entry links to an additional PAL (i.e., PAL Package Type 0001) 🔗 the PAL is XML [XML] 💖

3.6.2. /cacerts

the CA certificates in the explicit TA database get distributed to the client when it's registered 📮 how that TA distribution works is out of scope, so don't look for it here 🙈 CA certificates provided through this service follow Sections 5 and 6 of this document ✨

3.6.3. /simpleenroll

CSRs follow the specs in Section 4.2 of [RFC8756] 📝 the exceptions are that the CMC-specific ChangeSubjectName and POP Link Witness V2 attributes do not apply 🚫 only EC-based algorithms are used 💜

client certificates provided through this service are as specified in Section 7 of this document 🦋

the HTTP content type text/plain ([RFC2046], Section 4.1) is used to return human-readable errors 🙏

3.6.4. /simplereenroll

no extra requirements for requests beyond what's in Sections 3.4 and 3.6.3 of this document 🥰

the HTTP content type text/plain ([RFC2046], Section 4.1) is used to return human-readable errors 💌

3.6.5. /fullcmc

requests follow [RFC8756], with the one notable exception that only EC-based algorithms are used 💅

additional attributes for returned CMS packages can be found in [RFC7906] ✨

certificates provided through this service are as specified in Section 7 of this document 🎀

3.6.6. /serverkeygen

okay so PKCS#12 [RFC7292] (sometimes called "PFX" for Personal Information Exchange, or "P12") is how server-generated asymmetric private keys and the matching certificate get handed to clients 🔐🧚 this interface is one-way, since the RA is the one that requests these from the server 📨

PFXs [RFC7292] are exchanged using both password privacy mode and integrity password mode 🔒 the PRF algorithm for PBKDF2 (the KDF for PBES2 and PBMAC1) is HMAC-SHA-384, and the PBES2 encryption scheme is AES-256 💜🔥

the HTTP content type text/plain ([RFC2046], Section 4.1) is used to return human-readable errors 🫶

/serverkeygen/return is not supported at this time 🙅‍♀️

3.6.7. /csrattrs

clients use this service to grab partially filled PKIRequests 🧩 these have no public key and no proof-of-possession signature, which means their values are set to zero length (either a zero length BIT STRING or OCTET STRING) 🫧 the pKCS7PDU attribute, defined in [RFC2985], holds the partially filled PKIRequest as the only element in the CsrAttrs sequence 💖 even though CsrAttrs is defined as a set, there is only ever exactly one instance of values present 👑

3.6.8. /crls

CRLs provided through this service are as specified in Section 9 of this document 🌈

3.6.9. /symmetrickeys

clients that claim to support SODP interoperation will be able to process the following messages from an SODP server 🧚

  • additional encryption and origin authentication ([RFC8295], Section 5); and
  • server-provided Symmetric Key Content Type [RFC6032] encapsulated in an Encrypted Key Content Type using the EnvelopedData choice [RFC6033] with an SOA certificate that includes the CMS Content Constraints extension (see Section 7.1).

the client-supported algorithms for decrypting the server-returned symmetric key are as follows 🔑💅

  • Message Digest: See Section 4 of [RFC8755].
  • Digital Signature Algorithm: See Section 5 of [RFC8755].
  • Key Agreement: See Section 6.1 of [RFC8755].
  • Key Wrap: AES-256 Key Wrap with Padding [RFC6033] is used. AES-128 Key Wrap with Padding is not used.
  • Content Encryption: AES-256 Key Wrap with Padding [RFC6033] is used. AES-128 Key Wrap with Padding is not used.

/symmetrickeys/return is not used at this time 🙈

3.6.10. /eecerts, /firmware, /tamp

/eecerts, /firmware, and /tamp are not used at this time 💤

4. CMC Interface

client options for CMC [RFC5274] [RFC6402] are specified in this section 🎀

4.1. RFC 5273 Transport Protocols

clients only use the HTTPS-based transport 🔒 the TLS implementation and configuration are as specified in [RFC9151], with the notable exception that only EC-based algorithms are used 💜

clients that receive HTTP redirection responses (3xx status codes) will terminate the connection ([RFC7030], Section 3.2.1) 📞✨

4.2. Eligibility

same energy as the EST side 🫶 at the CMC interface, servers only enroll clients they already have a prior relationship with, independent of the EST service 🤝 client owners/operators interact in person with the human acting as the Registration Authority (RA), so the info in the certificate request (the CSR, Certificate Signing Request) is associated with a client 🧚 the mechanism and the info provided are beyond the scope of this document 🙈 it might be as simple as the subject name in the CSR, or a copy of the certificate that'll verify the request, provided out of band 💌

4.3. Authentication

mutual authentication happens via client and server signing of CMC protocol elements, as required by [RFC8756] 🖋️ all such signatures are validated against an installed TA, and any that fail validation are rejected 🚫

4.4. Authorization

clients support the simultaneous presence of as many TAs as they need for all of their functions, and only these TAs 📚

clients check that the server's certificate includes the id-kp-cmcRA Extended Key Usage (EKU) value ([RFC6402], Section 2.10) 👑

if clients support processing the CMS Content Constraints extension [RFC6010], they ensure returned CMS content is from an SOA or an entity authorized by an SOA for that CMS content; see Section 7.1 for SOA certificates 🌸

4.5. Full PKI Requests/Responses

requests follow [RFC8756], with the notable exception that only EC-based algorithms are used 💅

additional attributes for returned CMS packages can be found in [RFC7906] ✨

certificates provided through this service are as specified in Section 7 of this document 🦋

5. Trust Anchor Profile

clients are free to store the TA in whatever format they like 🗂️ however, servers provide TA information as self-signed CA certificates 🫧 this section documents requirements for self-signed certificates in addition to those in [RFC8603], which itself adds requirements on top of [RFC5280] 🤓

only EC-based algorithms are used 💜

issuer and subject names are composed of only the following naming attributes: country name, domain component, organization name, organizational unit name, common name, state or province name, distinguished name qualifier, and serial number 🌈

in the Subject Key Identifier extension, the keyIdentifier is the 64 low-order bits of the subject's subjectPublicKey field 🔑

in the Key Usage extension, the nonRepudiation bit is never set 🙅‍♀️💀

6. Non-Self-Signed Certification Authority Certificate Profile ✨

okay bestie, this section is the rules for non-self-signed CA certificates 🎀 It's stacked on top of [RFC8603], and [RFC8603] is stacked on top of [RFC5280], so it's a whole pile of rules 🥞💅

Only EC-based algorithms are used. 🦋

Subject names are made up of only these naming attributes: country name, domain component, organization name, organizational unit name, common name, state or province name, distinguished name qualifier, and serial number. 🌸

In the Authority Key Identifier extension, the keyIdentifier choice is always used. The keyIdentifier is the 64 low-order bits of the issuer's subjectPublicKey field. 🔑

In the Subject Key Identifier extension, the keyIdentifier is the 64 low-order bits of the subject's subjectPublicKey field. 💜

In the Key Usage extension, the nonRepudiation bit is never set. 🙈

The Certificate Policies extension is always included, and policyQualifiers are never used. ✨

Non-self-signed CA certificates can also include the following:

Name Constraints: permittedSubtrees constraints are included, and excludedSubstree constraints are not. Of the GeneralName choices, issuers support the following: rfc822Name, dNSName, uniformResourceIdentifier, and iPAddress (both IPv4 and IPv6) as well as hardwareModuleName, which is defined in [RFC4108]. Note that rfc822Name, dNSName, and uniformResourceIdentifier are defined as IA5 strings, and the character sets allowed are not uniform amongst these three name forms 🧚

CRL Distribution Points: A distributionPoint is always the fullName choice. The uniformResourceIdentifier GeneralName choice is always included, but others can also be used as long as the first element in the sequence of CRLDistributionPoints is the uniformResourceIdentifier choice. The reasons and cRLIssuer fields are never populated. This extension is never marked as critical. 🌈

Authority Information Access: Only one instance of AccessDescription is included. accessMethod is id-caIssuers, and accessLocation's GeneralName is always the uniformResourceIdentifier choice. 🦋

Extended Key Usage: EST servers and RAs include the id-kp-cmcRA EKU, and the CAs include the id-kp-cmcCA, which are both specified in [RFC6402]. 👑

Issuers include the Authority Clearance Constraints extension [RFC5913] in non-self-signed CA certificates that are issued to non-SOAs. Values for the Certificate Policy (CP) Object Identifier (OID) and the supported classList values are found in the issuer's CP. Criticality is determined by the issuer, and a securityCategories is never included. Only one instance of Clearance is generated in the AuthorityClearanceConstraints sequence. 💅

Issuers include a critical CMS Content Constraints extension [RFC6010] in CA certificates used to issue SOA certificates. This is necessary to enable enforcement of scope of the SOA authority. The content types included depend on the packages the SOA sources, but include key packages (i.e., Encrypted Key Packages, Symmetric Key Packages, and Asymmetric Key Packages). 🔐

7. End-Entity Certificate Profile 🧁

This section documents requirements for EE signature and key establishment certificates in addition to those listed in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280]. 💖

Only EC-based algorithms are used. 🦋

Subject names are composed of the following naming attributes: country name, domain component, organization name, organizational unit name, common name, state or province name, distinguished name qualifier, and serial number. 🌸

In the Authority Key Identifier extension, the keyIdentifier choice is always used. The keyIdentifier is the 64 low-order bits of the issuer's subjectPublicKey field. 🔑

In the Subject Key Identifier extension, the keyIdentifier is the 64 low-order bits of the subject's subjectPublicKey field. 💜

In the Key Usage extension, signature certificates only assert digitalSignature, and key establishment certificates only assert keyAgreement. 🎯

The Certificate Policies extension is always included, and policyQualifiers are never used. ✨

When included, the non-critical CRL Distribution Point extension's distributionPoint is always identified by the fullName choice. The uniformResourceIdentifier GeneralName choice is always included, but others can also be used as long as the first element in the sequence of distribution points is the URI choice and it is an HTTP/HTTPS scheme. The reasons and cRLIssuer fields are never populated. 🌈

The following subsections provide additional requirements for the different types of EE certificates. 🫶

7.1. Source of Authority Certificate Profile

This section specifies the format for SOA certificates, i.e., certificates issued to those entities that are authorized to create, digitally sign, encrypt, and distribute packages. These certificates are issued by non-PKI TAs. 👑

The Subject Alternative Name extension is always included. The following choices are supported: rfc822Name, dNSName, ediPartyName, uniformResourceIdentifier, or iPAddress (both IPv4 and IPv6). This extension is never critical. 🦋

A critical CMS Content Constraints extension [RFC6010] is included in SOA signature certificates. The content types included depend on the packages the SOA sources (e.g., Encrypted Key Packages, Symmetric Key Packages, and Asymmetric Key Packages). 🔥

7.2. Client Certificate Profile

This section specifies the format for certificates issued to clients. 🍓

A non-critical Subject Directory Attributes extension is always included with the following attributes:

The following extensions are also included at the discretion of the CA:

  • The Authority Information Access extension with only one instance of AccessDescription included. accessMethod is id-caIssuers, and accessLocation's GeneralName is always the uniformResourceIdentifier choice. 🌸
  • A non-critical Subject Alternative Name extension that includes the hardwareModuleName form [RFC4108], rfc822Name, or uniformResourceIdentifier. 🧚
  • A critical Subject Alternative Name extension that includes dNSName, rfc822Name, ediPartyName, uniformResourceIdentifier, or iPAddress (both IPv4 and IPv6). ⭐

8. Relying Party Applications 💅

This section documents requirements for Relying Parties (RPs) in addition to those listed in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280]. 🥰

Only EC-based algorithms are used. 🦋

RPs support the Authority Key Identifier and the Subject Key Identifier extensions. 🔑

RPs should support the following extensions: CRL Distribution Points, Authority Information Access, Subject Directory Attribute, Authority Clearance Constraints, and CMS Content Constraints. 🌟

Within the Subject Directory Attribute extension, RPs should support the Clearance Sponsor, Clearance, and Device Owner attributes. 💜

RPs support the id-kp-cmcRA and id-kp-cmcCA EKUs. 👑

Failure to support extensions in this section might limit the suitability of a device for certain applications. 💀

9. CRL Profile 📜

This section documents requirements for CRLs in addition to those listed in [RFC8603], which in turn specifies requirements in addition to those in [RFC5280]. 🌈

Only EC-based algorithms are used. 🦋

Two types of CRLs are produced: complete base CRLs and partitioned base CRLs. 🍓

crlEntryExtensions are never included, and the reasons and cRLIssuer fields are never populated. 🙈

All CRLs include the following CRL extensions:

  • The Authority Key Identifier extension: The keyIdentifier is the 64 low-order bits of the issuer's subjectPublicKey field. 🔑
  • As per [RFC5280], the CRL Number extension. 🔢

The only other extension included in partitioned base CRLs is the Issuing Distribution Point extension. The distributionPoint is always identified by the fullName choice. The uniformResourceIdentifier GeneralName choice is always included, but others can also be used as long as the first element in the sequence of distribution points is the uniformResourceIdentifier choice and the scheme is an HTTP/HTTPS scheme. All other fields are omitted. 🧁

10. IANA Considerations 🎀

This document has no IANA actions. Nothing for IANA to do here, bestie 🙌

11. Security Considerations 🔐

This entire document is about security. 😭 This document profiles the use of many protocols and services: EST, CMC, and PKCS#10/#7/#12 as well as certificates, CRLs, and their extensions [RFC5280]. These have been cited throughout this document, and the specifications identified by those citations should be consulted for security considerations related to implemented protocols and services. 🛡️💖

12. References 📚

12.1. Normative References 📚

These are the must-read ones bestie, the docs the spec leans on so hard that you can't really get the full picture without them. 🤓

12.2. Informative References 💡

These ones are the friendly background reads, good for context but not strictly required to get the spec. 🌸

Authors' Addresses 🎀

  • Michael Jenkins, National Security Agency. Email: mjjenki@cyber.nsa.gov
  • Sean Turner, sn3rd. Email: sean@sn3rd.com
📦 where this page comes from