GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Trace: • rfc9152
rfc:rfc9152



Independent Submission M. Jenkins Request for Comments: 9152 NSA Category: Informational S. Turner ISSN: 2070-1721 sn3rd 

                                                            April 2022

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

                     Symmetric Keys to Clients

Abstract 

 This document specifies protocol interfaces profiled by the United
 States National Security Agency (NSA) for National Security System
 (NSS) servers that provide public key certificates, Certificate
 Revocation Lists (CRLs), and symmetric keys to NSS clients.  Servers
 that support these interfaces are referred to as Secure Object
 Delivery Protocol (SODP) servers.  The intended audience for this
 profile comprises developers of client devices that will obtain key
 management services from NSA-operated SODP servers.  Interfaces
 supported by SODP servers include Enrollment over Secure Transport
 (EST) and its extensions as well as Certificate Management over CMS
 (CMC).
 This profile applies to the capabilities, configuration, and
 operation of all components of US National Security Systems (SP
 800-59).  It is also appropriate for other US Government systems that
 process high-value information.  It is made publicly available for
 use by developers and operators of these and any other system
 deployments.

Status of This Memo 

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not candidates for any level of Internet Standard;
 see Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc9152.

Copyright Notice 

 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 of this document.  Please review these documents
 carefully, as they describe 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 document specifies protocol interfaces profiled by the United
 States National Security Agency (NSA) for National Security System
 (NSS) servers that provide public key certificates, Certificate
 Revocation Lists (CRLs), and symmetric keys to NSS clients.  Servers
 that support these interfaces are referred to as Secure Object
 Delivery Protocol (SODP) servers.  The purpose of this document is to
 indicate options from, and requirements in addition to, the base
 specifications listed in Section 1.1 that are necessary for client
 interoperability with NSA-operated SODP servers.  Clients are always
 devices and need not implement all of the interfaces specified
 herein; clients are free to choose which interfaces to implement
 based on their operational requirements.  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 applies to the capabilities, configuration, and
 operation of all components of US National Security Systems
 [SP-800-59].  It is also appropriate for other US Government systems
 that process high-value information.  It is made publicly available
 for use by developers and operators of these and any other system
 deployments.
 This profile conforms to the existing requirements of the NSA's
 Commercial National Security Algorithms (CNSAs).  As operational
 needs evolve over time, this profile will be updated to incorporate
 new commercial algorithms and protocols as they are developed and
 approved for use.

1.1. Documents to be Familiar With 

 Familiarity with the follow specifications is assumed:
  • EST and EST extensions: [RFC7030] and [RFC8295]
  • PKI-related specifications: [RFC2986], [RFC3739], [RFC5274],

[RFC5280], [RFC5912], [RFC5913], [RFC5916], [RFC5917], [RFC6010], 

    and [RFC6402]
  • Key-format-related specifications: [RFC5915], [RFC5958],

[RFC5959], [RFC6031], [RFC6032], [RFC6160], [RFC6161], [RFC6162], 

    [RFC7191], [RFC7192], [RFC7292], and [RFC7906]
  • CMS-related (Cryptographic Message Syntax) documents: [RFC5652]

and [RFC6268]

  • CNSA-related documents: [RFC8603], [RFC8755], [RFC8756], and

[RFC9151] 

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

1.2. Document Organization 

 The document is organized as follows:
  • The remainder of this section describes the operational

environment used by clients 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 obtain secure "objects" or "packages" from the client-server-
 based environment.  Objects/packages vary based on the Source of
 Authority (SOA), but all objects are "secured" minimally through the
 use of one or more digital signatures and zero or more layers of
 encryption, as profiled in this document.  An SOA is the authority
 for the creation of objects that the client will recognize as valid.
 An SOA can delegate its authority to other actors; delegation occurs
 through the issuance of certificates.  An object or package is the
 generic term for certificates, certificate status information, and
 keys (both asymmetric and symmetric).  All of the objects except for
 the certificates and certificate status information are directly
 encapsulated in and protected by CMS content types.  CMS content
 types that provide security are referred to as "CMS-protecting
 content types".  All others are simply referred to as "CMS content
 types".  All secured objects are distributed either as CMS packages
 or as part of a CMS package.
 In the example depicted in Figure 1, there are two SOAs: one for
 symmetric keys, as depicted by the Key Trust Anchor (KTA), and one
 for public key certificates, as depicted by the PKI Trust Anchor
 (TA).  The KTA is responsible for the creation and distribution of
 symmetric keys.  The KTA delegates the creation and distribution
 responsibilities to separate entities through the issuance of
 certificates to a Key Source Authority (KSA) and a Key Distribution
 Authority (KDA).  The KSA generates the keys, digitally signs the
 keys, and encrypts the key for the end client using CMS content types
 for each step.  The KDA distributes the KSA-generated and KSA-
 protected key to the client; the key may also be signed by the KDA.
 The resulting CMS package is provided to the client through the EST
 extension's /symmetrickey service.  The PKI TA is responsible for the
 creation, distribution, and management of public key certificates.
 The PKI TA delegates these responsibilities to Certification
 Authorities (CAs), and CAs, in turn, are responsible for creating,
 distributing, and managing 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 and 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; 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 about
 the differences between the 2002 and 2008 ASN.1 versions.

3. EST Interface 

 Client options for EST [RFC7030] and EST extensions [RFC8295] are
 specified in this section.

3.1. Hypertext Transfer Protocol Layer 

 Clients that receive redirection responses (3xx status codes) will
 terminate the connection ([RFC7030], Section 3.2.1).
 Per Section 2.2 of [RFC8295], clients indicate the format
 ("application/xml" or "application/json") of the PAL information
 ([RFC8295], Section 2.1.1) via the HTTP Accept header.

3.2. Transport Layer Security 

 TLS implementations are configured as specified in [RFC9151]; the
 notable exception is that only EC-based algorithms are used.

3.3. Eligibility 

 At the EST interface, servers only enroll clients that they have
 established a prior relationship with independently of the EST
 service.  To accomplish this, client owners/operators interact in
 person with the human acting as the Registration Authority (RA) to
 ensure the information included in the transmitted certificate
 request, which is sometimes called a Certificate Signing Request
 (CSR), is associated with a client.  The mechanism by which the
 owner/operator interacts with the RA as well as the information
 provided is beyond the scope of this document.  The information
 exchanged by the owner/operator might be something as simple as the
 subject name included in the CSR to be sent or a copy of the
 certificate that will be used to verify the certificate request,
 which is provided out of band.

3.4. Authentication 

 Mutual authentication occurs via "Certificate TLS Authentication"
 ([RFC7030], Section 2.2.1).  Clients provide their certificate to
 servers in the TLS Certificate message, which is sent in response to
 the server's TLS Certificate Request message.  Both servers and
 clients reject all attempts to authenticate based on certificates
 that cannot be validated back to an installed TA.

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 check that the server's certificate includes the id-kp-cmcRA
 Extended Key Usage (EKU) value ([RFC6402], Section 2.10).
 Clients that support processing of the CMS Content Constraints
 extension [RFC6010] 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.

3.6. EST and EST Extensions 

 This section profiles SODP's interfaces for EST [RFC7030] and EST
 extensions [RFC8295].

3.6.1. /pal 

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

3.6.2. /cacerts 

 The CA certificates located in the explicit TA database are
 distributed to the client when it is registered.  This TA
 distribution mechanism is out of scope.
 CA certificates provided through this service are as specified in
 Sections 5 and 6 of this document.

3.6.3. /simpleenroll 

 CSRs follow the specifications in Section 4.2 of [RFC8756], except
 that the CMC-specific ChangeSubjectName and the 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 of "text/plain" ([RFC2046], Section 4.1) is
 used to return human-readable errors.

3.6.4. /simplereenroll 

 There are no additional requirements for requests beyond those
 specified in Sections 3.4 and 3.6.3 of this document.
 The HTTP content type of "text/plain" ([RFC2046], Section 4.1) is
 used to return human-readable errors.

3.6.5. /fullcmc 

 Requests are as specified in [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.

3.6.6. /serverkeygen 

 PKCS#12 [RFC7292] -- sometimes referred to as "PFX" (Personal
 Information Exchange) or "P12" -- is used to provide server-generated
 asymmetric private keys and the associated certificate to clients.
 This interface is a one-way interface as the RA 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 of "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 retrieve partially filled PKIRequests
 with no public key or proof-of-possession signature, i.e., their
 values are set to zero length, either a zero length BIT STRING or
 OCTET STRING.  The pKCS7PDU attribute, defined in [RFC2985], includes
 the partially filled PKIRequest as the only element in the CsrAttrs
 sequence.  Even though the CsrAttrs syntax 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).
 Client-supported algorithms to decrypt 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 

 At the CMC interface, servers only enroll clients that they have
 established a prior relationship with independently of the EST
 service.  To accomplish this, client owners/operators interact in
 person with the human acting as the Registration Authority (RA) to
 ensure the information included in the transmitted certificate
 request, which is sometimes called a Certificate Signing Request
 (CSR), is associated with a client.  The mechanism by which the
 owner/operator interacts with the RA as well as the information
 provided is beyond the scope of this document.  The information
 exchanged by the owner/operator might be something as simple as the
 subject name included in the CSR to be sent or a copy of the
 certificate that will be used to verify the certificate request,
 which is provided out of band.

4.3. Authentication 

 Mutual authentication occurs via client and server signing of CMC
 protocol elements, as required by [RFC8756].  All such signatures are
 validated against an installed TA; any that fail validation are
 rejected.

4.4. Authorization 

 Clients support the simultaneous presence of as many TAs as are
 required for all of the functions of the client, 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).
 Clients that support processing of the CMS Content Constraints
 extension [RFC6010] 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 are as specified in [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 the format of their choosing;
 however, servers provide TA information in the form of self-signed CA
 certificates.  This section documents requirements for self-signed
 certificates in addition to those specified in [RFC8603], which in
 turn specifies requirements in addition to those in [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 

 This section documents requirements for non-self-signed CA
 certificates in addition to those specified in [RFC8603], which in
 turn specifies requirements in addition to those in [RFC5280].
 Only EC-based algorithms are used.
 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 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:
  • Device Owner [RFC5916]
  • Clearance Sponsor [RFC5917]
  • Clearance [RFC5913]
 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.

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 

 [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
            Extensions (MIME) Part Two: Media Types", RFC 2046,
            DOI 10.17487/RFC2046, November 1996,
            <https://www.rfc-editor.org/info/rfc2046>.
 [RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
            Classes and Attribute Types Version 2.0", RFC 2985,
            DOI 10.17487/RFC2985, November 2000,
            <https://www.rfc-editor.org/info/rfc2985>.
 [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
            Request Syntax Specification Version 1.7", RFC 2986,
            DOI 10.17487/RFC2986, November 2000,
            <https://www.rfc-editor.org/info/rfc2986>.
 [RFC3739]  Santesson, S., Nystrom, M., and T. Polk, "Internet X.509
            Public Key Infrastructure: Qualified Certificates
            Profile", RFC 3739, DOI 10.17487/RFC3739, March 2004,
            <https://www.rfc-editor.org/info/rfc3739>.
 [RFC4108]  Housley, R., "Using Cryptographic Message Syntax (CMS) to
            Protect Firmware Packages", RFC 4108,
            DOI 10.17487/RFC4108, August 2005,
            <https://www.rfc-editor.org/info/rfc4108>.
 [RFC5274]  Schaad, J. and M. Myers, "Certificate Management Messages
            over CMS (CMC): Compliance Requirements", RFC 5274,
            DOI 10.17487/RFC5274, June 2008,
            <https://www.rfc-editor.org/info/rfc5274>.
 [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, DOI 10.17487/RFC5280, May 2008,
            <https://www.rfc-editor.org/info/rfc5280>.
 [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
            RFC 5652, DOI 10.17487/RFC5652, September 2009,
            <https://www.rfc-editor.org/info/rfc5652>.
 [RFC5911]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for
            Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
            DOI 10.17487/RFC5911, June 2010,
            <https://www.rfc-editor.org/info/rfc5911>.
 [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
            Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
            DOI 10.17487/RFC5912, June 2010,
            <https://www.rfc-editor.org/info/rfc5912>.
 [RFC5913]  Turner, S. and S. Chokhani, "Clearance Attribute and
            Authority Clearance Constraints Certificate Extension",
            RFC 5913, DOI 10.17487/RFC5913, June 2010,
            <https://www.rfc-editor.org/info/rfc5913>.
 [RFC5915]  Turner, S. and D. Brown, "Elliptic Curve Private Key
            Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010,
            <https://www.rfc-editor.org/info/rfc5915>.
 [RFC5916]  Turner, S., "Device Owner Attribute", RFC 5916,
            DOI 10.17487/RFC5916, June 2010,
            <https://www.rfc-editor.org/info/rfc5916>.
 [RFC5917]  Turner, S., "Clearance Sponsor Attribute", RFC 5917,
            DOI 10.17487/RFC5917, June 2010,
            <https://www.rfc-editor.org/info/rfc5917>.
 [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958,
            DOI 10.17487/RFC5958, August 2010,
            <https://www.rfc-editor.org/info/rfc5958>.
 [RFC5959]  Turner, S., "Algorithms for Asymmetric Key Package Content
            Type", RFC 5959, DOI 10.17487/RFC5959, August 2010,
            <https://www.rfc-editor.org/info/rfc5959>.
 [RFC6010]  Housley, R., Ashmore, S., and C. Wallace, "Cryptographic
            Message Syntax (CMS) Content Constraints Extension",
            RFC 6010, DOI 10.17487/RFC6010, September 2010,
            <https://www.rfc-editor.org/info/rfc6010>.
 [RFC6031]  Turner, S. and R. Housley, "Cryptographic Message Syntax
            (CMS) Symmetric Key Package Content Type", RFC 6031,
            DOI 10.17487/RFC6031, December 2010,
            <https://www.rfc-editor.org/info/rfc6031>.
 [RFC6032]  Turner, S. and R. Housley, "Cryptographic Message Syntax
            (CMS) Encrypted Key Package Content Type", RFC 6032,
            DOI 10.17487/RFC6032, December 2010,
            <https://www.rfc-editor.org/info/rfc6032>.
 [RFC6033]  Turner, S., "Algorithms for Cryptographic Message Syntax
            (CMS) Encrypted Key Package Content Type", RFC 6033,
            DOI 10.17487/RFC6033, December 2010,
            <https://www.rfc-editor.org/info/rfc6033>.
 [RFC6160]  Turner, S., "Algorithms for Cryptographic Message Syntax
            (CMS) Protection of Symmetric Key Package Content Types",
            RFC 6160, DOI 10.17487/RFC6160, April 2011,
            <https://www.rfc-editor.org/info/rfc6160>.
 [RFC6161]  Turner, S., "Elliptic Curve Algorithms for Cryptographic
            Message Syntax (CMS) Encrypted Key Package Content Type",
            RFC 6161, DOI 10.17487/RFC6161, April 2011,
            <https://www.rfc-editor.org/info/rfc6161>.
 [RFC6162]  Turner, S., "Elliptic Curve Algorithms for Cryptographic
            Message Syntax (CMS) Asymmetric Key Package Content Type",
            RFC 6162, DOI 10.17487/RFC6162, April 2011,
            <https://www.rfc-editor.org/info/rfc6162>.
 [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
            for the Cryptographic Message Syntax (CMS) and the Public
            Key Infrastructure Using X.509 (PKIX)", RFC 6268,
            DOI 10.17487/RFC6268, July 2011,
            <https://www.rfc-editor.org/info/rfc6268>.
 [RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)
            Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
            <https://www.rfc-editor.org/info/rfc6402>.
 [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
            "Enrollment over Secure Transport", RFC 7030,
            DOI 10.17487/RFC7030, October 2013,
            <https://www.rfc-editor.org/info/rfc7030>.
 [RFC7191]  Housley, R., "Cryptographic Message Syntax (CMS) Key
            Package Receipt and Error Content Types", RFC 7191,
            DOI 10.17487/RFC7191, April 2014,
            <https://www.rfc-editor.org/info/rfc7191>.
 [RFC7192]  Turner, S., "Algorithms for Cryptographic Message Syntax
            (CMS) Key Package Receipt and Error Content Types",
            RFC 7192, DOI 10.17487/RFC7192, April 2014,
            <https://www.rfc-editor.org/info/rfc7192>.
 [RFC7292]  Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
            and M. Scott, "PKCS #12: Personal Information Exchange
            Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
            <https://www.rfc-editor.org/info/rfc7292>.
 [RFC7906]  Timmel, P., Housley, R., and S. Turner, "NSA's
            Cryptographic Message Syntax (CMS) Key Management
            Attributes", RFC 7906, DOI 10.17487/RFC7906, June 2016,
            <https://www.rfc-editor.org/info/rfc7906>.
 [RFC8295]  Turner, S., "EST (Enrollment over Secure Transport)
            Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018,
            <https://www.rfc-editor.org/info/rfc8295>.
 [RFC8603]  Jenkins, M. and L. Zieglar, "Commercial National Security
            Algorithm (CNSA) Suite Certificate and Certificate
            Revocation List (CRL) Profile", RFC 8603,
            DOI 10.17487/RFC8603, May 2019,
            <https://www.rfc-editor.org/info/rfc8603>.
 [RFC8755]  Jenkins, M., "Using Commercial National Security Algorithm
            Suite Algorithms in Secure/Multipurpose Internet Mail
            Extensions", RFC 8755, DOI 10.17487/RFC8755, March 2020,
            <https://www.rfc-editor.org/info/rfc8755>.
 [RFC8756]  Jenkins, M. and L. Zieglar, "Commercial National Security
            Algorithm (CNSA) Suite Profile of Certificate Management
            over CMS", RFC 8756, DOI 10.17487/RFC8756, March 2020,
            <https://www.rfc-editor.org/info/rfc8756>.
 [RFC9151]  Cooley, D., "Commercial National Security Algorithm (CNSA)
            Suite Profile for TLS and DTLS 1.2 and 1.3", RFC 9151,
            DOI 10.17487/RFC9151, April 2022,
            <https://www.rfc-editor.org/info/rfc9151>.
 [SP-800-59]
            National Institute of Standards and Technology, "Guideline
            for Identifying an Information System as a National
            Security System", DOI 10.6028/NIST.SP.800-59, NIST Special
            Publication 800-59, August 2003,
            <https://csrc.nist.gov/publications/detail/sp/800-59/
            final>.
 [XML]      Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
            and F. Yergeau, "Extensible Markup Language (XML) 1.0
            (Fifth Edition)", World Wide Web Consortium
            Recommendation REC-xml-20081126, November 2008,
            <https://www.w3.org/TR/2008/REC-xml-20081126/>.

12.2. Informative References 

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
            2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
            May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses 

 Michael Jenkins
 National Security Agency
 Email: mjjenki@cyber.nsa.gov
 Sean Turner
 sn3rd
 Email: sean@sn3rd.com
/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc9152.txt · Last modified: 2022/04/26 22:46 by 127.0.0.1
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki