RFC 8756

Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS

📅 published March 2020, from ietf

📜 RFC 8756: CNSA Suite Profile of Certificate Management over CMS 💖

okay bestie, let's get into this one 🎀✨ it's an Informational RFC (so it's not an Internet Standard, it's more like a very serious, very official guidebook 💅), written by M. Jenkins and L. Zieglar from the NSA 🇺🇸, published in March 2020 🌸. It's an Independent Submission, which means it came in from outside the usual IETF stream 🦋. It doesn't obsolete or update any other RFCs, so it's a fresh little drop 💜.

Abstract

okay so the whole point is this 🫶 it's a profile of the Certificate Management over CMS (CMC) protocol for handling X.509 public key certificates in apps that use the Commercial National Security Algorithm (CNSA) Suite from the US Government 🔥. It's built for all parts of US National Security Systems that manage X.509 certs over CMS, and it's also good for any other US Government systems that handle high-value info 👑. They made it public so devs and operators of these systems (and anyone else) can use it 🌈.

Status of This Memo

ngl this section is the legal-ish bit, but here's the tea 🍓. This document is not an Internet Standards Track spec, it's just published for info 💅. It's a contribution to the RFC Series, independent of any other RFC stream, and the RFC Editor chose to publish it at their discretion. They make no statement about whether it's valuable for implementation or deployment 🙈. Anything the RFC Editor approves is not a candidate for any level of Internet Standard (see Section 2 of RFC 7841, bestie). You can find the current status, errata, and feedback info at https://www.rfc-editor.org/info/rfc8756 ✨.

Copyright (c) 2020 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) as they were on the publication date. Read those carefully, because they spell out your rights and restrictions 🧚.

📚 Table of Contents

1.  Introduction
  1.1.  Terminology
2.  The Commercial National Security Algorithm Suite
3.  Requirements and Assumptions
4.  Client Requirements: Generating PKI Requests
  4.1.  Tagged Certification Request
  4.2.  Certificate Request Message
5.  RA Requirements
  5.1.  RA Processing of Requests
  5.2.  RA-Generated PKI Requests
  5.3.  RA-Generated PKI Responses
6.  CA Requirements
  6.1.  CA Processing of PKI Requests
  6.2.  CA-Generated PKI Responses
7.  Client Requirements: Processing PKI Responses
8.  Shared-Secrets
9.  Security Considerations
10. IANA Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Appendix A.  Scenarios
  A.1.  Initial Enrollment
  A.2.  Rekey
Authors' Addresses

1. Introduction 🌷

okay so this doc is a profile of CMC 🎀 made to follow the NSA's CNSA Suite [CNSA]. It covers all parts of US National Security Systems [SP80059] and is good for other US Gov systems with high-value info too 💅. Anyone can use it for their own deployments 🦋.

It doesn't invent any new crypto algorithm suites 🙅‍♀️. Instead it's a CNSA-compliant profile of CMC, which is defined in [RFC5272], [RFC5273], and [RFC5274], and updated by [RFC6402] ✨. The profile is for managing X.509 public key certs that comply with the CNSA Suite Certificate and CRL profile [RFC8603] 💜. It's specifically about the initial enrollment and rekey of CNSA Suite certs between a client and a Certification Authority (CA) 🌈. There can be one or more Registration Authorities (RAs) acting as middlemen between the client and the CA 🫶. Communities can tailor this profile more, and they'll define the certificate policies that implementations need to follow 🍓.

1.1. Terminology

okay the key words here 🔥: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" mean what BCP 14 [RFC2119] [RFC8174] says, but only when they show up in ALL CAPS like this 💅.

The terminology in [RFC5272], Section 2.1 applies here too 🎀.

The term "certificate request" means a single PKCS #10 or Certificate Request Message Format (CRMF) structure 🦋. All PKI Requests are Full PKI Requests and all PKI Responses are Full PKI Responses, and those terms should be read as synonyms in this doc ✨.

2. The Commercial National Security Algorithm Suite 🌸

the NSA profiles commercial crypto algorithms and protocols to support secure, interoperable comms for US Gov National Security Systems 👑. They publish guidance to help the Gov transition to new algorithms and to give vendors, and the Internet community in general, info on using them properly in those systems 💖.

lowkey the big deal is that cryptographic transition plans got overshadowed by the possibility of a cryptographically relevant quantum computer 🧚. The NSA set up the CNSA Suite to give vendors and IT users near-term flexibility for cybersecurity interoperability 🔥. The whole point is avoiding two major transitions in a short window, since a shift to quantum-resistant crypto is expected soon 🙈.

The NSA is writing a set of RFCs (this one included) to give updated guidance on using certain common commercial algorithms in IETF protocols 🌈. These can be used alongside other RFCs and crypto guidance (like NIST Special Publications) to protect Internet traffic and data-at-rest for US Gov National Security Systems 🫶.

3. Requirements and Assumptions 💅

okay so ECDSA and ECDH key pairs are on the P-384 curve 💎. FIPS 186-4 [FIPS186], Appendix B.4 has guidance on elliptic curve key pair generation, and systems that conform to this doc SHOULD follow it 🎀.

RSA key pairs get identified by their modulus size in bits, so RSA-3072 and RSA-4096 use moduli of 3072 bits and 4096 bits 🦋.

RSA signature key pairs in CNSA Suite-compliant implementations are either RSA-3072 or RSA-4096 ✨. The RSA exponent e MUST satisfy 2^(16) < e < 2^(256) and be odd per [FIPS186] 🔥.

it's giving "the vast majority of RSA signatures are made with RSASSA-PKCS1-v1_5 right now, but the preferred scheme for new apps is RSASSA-PSS" 💜. CNSA Suite-compliant X.509 certs are issued per [RFC8603], and while those certs MUST be signed and validated using RSASSA-PKCS1-v1_5, the subject's private key can generate signatures in either scheme 🌈. Wherever this doc says to use RSASSA-PSS, these parameters apply 🫶:

  • The hash algorithm MUST be id-sha384 as defined in [RFC8017] 🍓;
  • The mask generation function MUST use the algorithm identifier mfg1SHA384Identifier as defined in [RFC4055] 💅;
  • The salt length MUST be 48 octets; and 🎀
  • The trailerField MUST have value 1. 🦋

these params won't show up in a certificate, but they MUST be securely communicated with the signature, as required by Section 2.2 of [RFC4056] ✨. App devs are on the hook for making sure the chosen signature scheme fits the app and will be interoperable within its intended operating scope 🌸.

This doc assumes the required trust anchors have been securely provisioned to the client and, when it applies, to any RAs 👑.

All requirements in [RFC5272], [RFC5273], [RFC5274], and [RFC6402] apply, unless this profile overrides them 💖.

This profile was built with the Appendix A scenarios in mind 🧚, but using it isn't limited to just those scenarios 🔥.

The term "client" here usually means an end-entity 🙈. It can also mean a third party acting on the end-entity's behalf 🌈. The client might or might not be the one generating the key pair, but it does do the CMC protocol interactions with the RA and/or CA 🫶. For example, the client could be a token management system talking to a cryptographic token through an out-of-band secure protocol 🍓.

This profile uses "rekey" the same way CMC does (defined in Section 2 of [RFC5272]) 💅. It makes no specific statements about "renewal" operations, but the "rekey" statements should be applied to "renewal" too 🎀.

This profile can manage RA and/or CA certs. In that case, the RA and/or CA whose cert is being managed counts as the end-entity 🦋.

This profile does NOT discuss key establishment certification requests from crypto modules that can't generate a one-time signature with a key establishment key for proof-of-possession purposes ✨. For those, a separate profile would be needed to define another proof-of-possession technique 💜.

okay bestie that's part 1 done 🎀💖 the rest of the RFC is coming in the next parts, so stay tuned 🦋✨

4. Client Requirements: Generating PKI Requests 🎀

okay so this section is all about what a client has to do when it asks a Public Key Infrastructure (PKI) for a certificate. bestie, the rules are very specific, so read closely 🧐

The Full PKI Request MUST be used; it MUST be encapsulated in a SignedData; and the SignedData MUST be constructed in accordance with [RFC8755]. The PKIData content type defined in [RFC5272] is used with the following additional requirements:

  • controlSequence SHOULD be present.
    • TransactionId and SenderNonce SHOULD be included. Other CMC controls MAY be included.
    • If the request is being authenticated using a shared-secret, then Identity Proof Version 2 control MUST be included with the following constraints:
      • hashAlgId MUST be id-sha384 for all certification requests (algorithm OIDs are defined in [RFC5754]).
      • macAlgId MUST be HMAC-SHA384 (the Hashed Message Authentication Code (HMAC) algorithm is defined in [RFC4231]).
    • If the subject name included in the certification request is NULL or otherwise does not uniquely identify the end-entity, then the POP Link Random control MUST be included, and the POP Link Witness Version 2 control MUST be included in the inner PKCS #10 [RFC2986] or Certificate Request Message Format (CRMF) [RFC4211] request as described in Sections 4.1 and 4.2.
  • reqSequence MUST be present. It MUST include at least one tcr (see Section 4.1) or crm (see Section 4.2) TaggedRequest. Support for the orm choice is OPTIONAL.

The private signing key used to generate the encapsulating SignedData MUST correspond to the public key of an existing signature certificate unless an appropriate signature certificate does not yet exist, such as during initial enrollment.

The encapsulating SignedData MUST be generated using SHA-384 and either ECDSA on P-384 or RSA using either RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.

If an appropriate signature certificate does not yet exist and if a Full PKI Request includes one or more certification requests and is authenticated using a shared-secret (because no appropriate certificate exists yet to authenticate the request), the Full PKI Request MUST be signed using the private key corresponding to the public key of one of the requested certificates. When necessary (i.e., because there is no existing signature certificate and there is no signature certification request included), a Full PKI Request MAY be signed using a key pair intended for use in a key establishment certificate. However, servers are not required to allow this behavior.

4.1. Tagged Certification Request 💅

The reqSequence tcr choice conveys PKCS #10 [RFC2986] syntax. The CertificateRequest MUST comply with [RFC5272], Section 3.2.1.2.1, with the following additional requirements:

  • certificationRequestInfo:
    • subjectPublicKeyInfo MUST be set as defined in Section 5.4 of [RFC8603].
    • Attributes:
      • The ExtensionReq attribute MUST be included with its contents as follows:
        • The keyUsage extension MUST be included, and it MUST be set as defined in [RFC8603].
        • For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the subject field of the certificate being used to generate the signature is NULL.
        • Other extension requests MAY be included as desired.
      • The ChangeSubjectName attribute, as defined in [RFC6402], MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's subject field or SubjectAltName extension does not match the desired subject name or SubjectAltName extension of this certification request.
      • The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the subject name in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha384 for certification requests, as defined in [RFC5754]; macAlgorithm MUST be HMAC-SHA384, as defined in [RFC4231].
    • signatureAlgorithm MUST be ecdsa-with-sha384 for P-384 certification requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests.
    • signature MUST be generated using the private key corresponding to the public key in the CertificationRequestInfo for both signature and key establishment certification requests. The signature provides proof-of-possession of the private key to the CA.

4.2. Certificate Request Message 🦋

The reqSequence crm choice conveys Certificate Request Message Format (CRMF) [RFC4211] syntax. The CertReqMsg MUST comply with [RFC5272], Section 3.2.1.2.2, with the following additional requirements:

  • popo MUST be included using the signature (POPOSigningKey) proof-of-possession choice and be set as defined in [RFC4211], Section 4.1 for both signature and key establishment certification requests. The POPOSigningKey poposkInput field MUST be omitted. The POPOSigningKey algorithmIdentifier MUST be ecdsa-with-sha384 for P-384 certification requests and sha384WithRSAEncryption or id-RSASSA-PSS for RSA-3072 and RSA-4096 certification requests. The signature MUST be generated using the private key corresponding to the public key in the CertTemplate.

The CertTemplate MUST comply with [RFC5272], Section 3.2.1.2.2, with the following additional requirements:

  • If version is included, it MUST be set to 2 as defined in Section 5.3 of [RFC8603].
  • publicKey MUST be set as defined in Section 5.4 of [RFC8603].
  • Extensions:
    • The keyUsage extension MUST be included, and it MUST be set as defined in [RFC8603].
    • For rekey requests, the SubjectAltName extension MUST be included and set equal to the SubjectAltName of the certificate that is being used to sign the SignedData encapsulating the request (i.e., not the certificate being rekeyed) if the subject name of the certificate being used to generate the signature is NULL.
    • Other extension requests MAY be included as desired.
  • Controls:
    • The ChangeSubjectName attribute, as defined in [RFC6402], MUST be included if the Full PKI Request encapsulating this Tagged Certification Request is being signed by a key for which a certificate currently exists and the existing certificate's subject name or SubjectAltName extension does not match the desired subject name or SubjectAltName extension of this certification request.
    • The POP Link Witness Version 2 attribute MUST be included if the request is being authenticated using a shared-secret and the subject name in the certification request is NULL or otherwise does not uniquely identify the end-entity. In the POP Link Witness Version 2 attribute, keyGenAlgorithm MUST be id-sha384 for certification requests; macAlgorithm MUST be HMAC-SHA384 when keyGenAlgorithm is id-sha384.

5. RA Requirements 🫶

this part is for RAs, the middlemen 🤝 who sit between clients and a CA. they're optional, but when they show up they've got rules too. in this section, "client" means whichever entity the RA got the PKI Request from. and yep, this section only applies to RAs 💜

This section addresses the optional case where one or more RAs act as intermediaries between clients and a CA as described in Section 7 of [RFC5272]. In this section, the term "client" refers to the entity from which the RA received the PKI Request. This section is only applicable to RAs.

5.1. RA Processing of Requests 🌸

RAs conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the RA MUST reject those requests. The RA SHOULD return a CMCFailInfo with the value of badAlg [RFC5272].

When processing end-entity-generated SignedData objects, RAs MUST NOT perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension processing [RFC6010].

Other RA processing is performed as described in [RFC5272].

5.2. RA-Generated PKI Requests 🍓

RAs mediate the certificate request process by collecting client requests in batches. The RA MUST encapsulate client-generated PKI Requests in a new RA-signed PKI Request, it MUST create a Full PKI Request encapsulated in a SignedData, and the SignedData MUST be constructed in accordance with [RFC8755]. The PKIData content type complies with [RFC5272] with the following additional requirements:

  • controlSequence MUST be present. It MUST include the following CMC controls: Transaction ID, Sender Nonce, and Batch Requests. Other appropriate CMC controls MAY be included.
  • cmsSequence MUST be present. It contains the original, unmodified request(s) received from the client.
  SignedData (applied by the RA)
    PKIData
      controlSequence (Transaction ID, Sender Nonce,
                                           Batch Requests)
      cmsSequence
        SignedData (applied by client)
          PKIData
            controlSequence (Transaction ID, Sender Nonce)
            reqSequence
              TaggedRequest
              {TaggedRequest}
        {SignedData     (second client request)
          PKIData...}

Authorization to sign RA-generated Full PKI Requests SHOULD be indicated in the RA certificate by inclusion of the id-kp-cmcRA Extended Key Usage (EKU) from [RFC6402]. The RA certificate MAY also include the CCC certificate extension [RFC6010], or it MAY indicate authorization through inclusion of the CCC certificate extension alone. The RA certificate may also be authorized through the local configuration.

If the RA is authorized via the CCC extension, then the CCC extension MUST include the object identifier for the PKIData content type. CCC SHOULD be included if constraints are to be placed on the content types generated.

The outer SignedData MUST be generated using SHA-384 and either ECDSA on P-384 or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key.

If the Full PKI Response is a successful response to a PKI Request that only contained a Get Certificate or Get CRL control, then the algorithm used in the response MUST match the algorithm used in the request.

5.3. RA-Generated PKI Responses ✨

In order for an RA certificate using the CCC certificate extension to be authorized to generate responses, the object identifier for the PKIResponse content type must be present in the CCC certificate extension.

6. CA Requirements 👑

last stop for this part: the CA, the one actually handing out the certificates 🏛️ this section lays out what CAs have to do when they get PKI Requests and send back PKI Responses 💖

This section specifies the requirements for CAs that receive PKI Requests and generate PKI Responses.

6.1. CA Processing of PKI Requests ✨

okay so the CA has a big job when a request rolls in 💅 first, it has to make sure only the permitted signature, hash, and MAC algorithms from this profile are used in the requests. if they're not, the CA MUST reject those requests. it SHOULD also send back a CMCStatusInfoV2 control with a CMCStatus of failed and a CMCFailInfo with the value of badAlg [RFC5272] 🙈

when an RA is involved (aka batched requests), the CA MUST verify that the RA is authorized 🫶 the publicKey field and the keyUsage extension are off-limits for the Modify Certification Request control, so they MUST NOT be modifiable. if a request tries to change them anyway, it MUST be rejected. the CA SHOULD send back a CMCStatusInfoV2 control with a CMCStatus of failed and a CMCFailInfo with a value of badRequest. not okay behavior, periodt 💀

when the CA is processing end-entity-generated SignedData objects, it MUST NOT do CCC certificate extension processing [RFC6010]. big no-no, don't even try it 🚫

if a client-generated PKI Request has the ChangeSubjectName attribute (from Section 4.1 or 4.2 above), the CA MUST make sure that name change is authorized ✨ how it checks that is out of scope, so the spec doesn't weigh in. if the CA checks and finds the name change isn't authorized, it MUST reject the PKI Request. it SHOULD return an Extended CMC Status Info control (CMCStatusInfoV2) with a CMCStatus of failed. the vibe is "no unauthorized glow-ups" 🦋

everything else about processing PKIRequests follows [RFC5272] 🌸

6.2. CA-Generated PKI Responses

the CA sends PKI Responses back to both client-generated requests and RA-generated requests 💖 if a Full PKI Response is returned straight to a client-generated request, it MUST be wrapped in a SignedData, and that SignedData MUST be built according to [RFC8755]. main character energy 👑

if the PKI Response is answering an RA-generated PKI Request, it gets an extra layer. the response above gets wrapped in another CA-generated PKI Response. that outer one MUST be wrapped in a SignedData, and that SignedData MUST be built according to [RFC8755]. the inner response goes in the encapsulating PKI Response's cmsSequence field. the other fields stay the same as before, plus the batch response control in controlSequence. here's what a successful CA response to an RA-encapsulated PKI Request looks like (both include Transaction IDs and Nonces) 🧚

      SignedData (applied by the CA)
        PKIResponse
          controlSequence (Transaction ID, Sender Nonce, Recipient
                           Nonce, Batch Response)
          cmsSequence
            SignedData (applied by CA and includes returned
                        certificates)
              PKIResponse
                controlSequence (Transaction ID, Sender Nonce,
                                 Recipient Nonce)

the private key the CA uses to sign certificates MUST NOT be the same one used to sign Full PKI Response messages 🙅‍♀️ instead, a separate certificate that says "yep, this one can sign CMC responses" MUST be used. separate keys, separate vibes ✨

the CA SHOULD indicate authorization to sign Full PKI Responses in its certificate by including the id-kp-cmcCA EKU from [RFC6402] 🎀 the CA certificate MAY also include the CCC certificate extension [RFC6010], or it MAY indicate authorization through the CCC certificate extension alone. it's also fine if the CA certificate gets authorized through local configuration 🌈

for a CA certificate using the CCC certificate extension to be allowed to generate responses, the object identifier for the PKIResponse content type must be present in that extension. CCC SHOULD be included if you want to put constraints on the content types generated 🍓

signatures on individual certificates follow what [RFC8603] requires ✨

the signature on the SignedData of a successful response to a client-generated request, or each individual inner SignedData on a successful response to an RA-generated request, MUST be generated using SHA-384. the signing options are ECDSA on P-384, or RSA using RSASSA-PKCS1-v1_5 or RSASSA-PSS with an RSA-3072 or RSA-4096 key 🔥 an unsuccessful response MUST be signed with the same key type and algorithm that signed the request. consistency is everything 💅

the outer SignedData on the Full PKI Response to any RA-generated PKI Request MUST be signed with the same key type and algorithm that signed the request 🫶

the SignedData on a successful Full PKI Response to a PKI Request that only contained a Get Certificate or Get CRL control MUST be signed with the same key type and algorithm that signed the request. same energy, every time 🦋

7. Client Requirements: Processing PKI Responses ✨

clients following this document MUST make sure that only the permitted signature, hash, and MAC algorithms from this profile are used in responses. if they're not, the client MUST reject those responses 🚫

clients MUST authenticate all Full PKI Responses 🔐 that means checking the response is signed by an authorized CA or RA whose certificate validates back to a trust anchor. the authorized CA certificate MUST include the id-kp-cmcCA EKU and/or a CCC extension that includes the object identifier for the PKIResponse content type. if not, the CA is considered authorized to sign responses through some implementation-specific mechanism 🤷‍♀️ a PKI Response can be signed by an RA if it's an error message, if it's a response to a Get Certificate or Get CRL request, or if the PKI Response contains an inner PKI Response signed by a CA. in that last case, each layer of PKI Response MUST still contain an authorized, valid signature from an entity with a valid certificate that verifies back to an acceptable trust anchor. the authorized RA certificate MUST include the id-kp-cmcRA EKU and/or include a CCC extension that includes the object identifier for the PKIResponse content type. otherwise, the RA is considered authorized to sign responses through local configuration 🧚

when a newly issued certificate comes along in the PKI Response, the client MUST verify that the new certificate's public key matches the public key the client requested 👀 the client MUST also make sure the certificate's signature is valid, and that it validates back to an acceptable trust anchor. no shortcuts, bestie ✨

clients MUST reject PKI Responses that don't pass these tests 💀 local policy decides whether the client returns a Full PKI Response with an Extended CMC Status Info control (CMCStatusInfoV2) with the CMCStatus set to failed, sending it to a user console, an error log, or the server 🌸

if the Full PKI Response contains an Extended CMC Status Info control with a CMCStatus set to failed, local policy decides whether the client resends a duplicate certification request back to the server, or whether an error state gets shown in a console or error log 🙈

8. Shared-Secrets

when the Identity Proof V2 and POP Link Witness V2 controls are used, the shared-secret MUST be randomly generated and securely distributed 🔐 it MUST also provide at least 192 bits of strength. that's a serious secret, babe 💜

9. Security Considerations

okay this section is SERIOUS, so buckle up 😭🔥

protocol security considerations live in [RFC2986], [RFC4211], [RFC8755], [RFC5272], [RFC5273], [RFC5274], [RFC8603], and [RFC6402]. when CCC is used to authorize RA and CA certificates, the security considerations in [RFC6010] also apply. algorithm security considerations are found in [RFC8755] 🛡️

following NIST Special Publication 800-57 [SP80057], this profile defines proof-of-possession of a key establishment private key by performing a digital signature. except for one-time proof-of-possession, a single key pair MUST NOT be used for both signature and key establishment. one key, one job, no exceptions 🙅‍♀️

this spec requires implementations to generate key pairs and other random values 🎲 using inadequate pseudorandom number generators (PRNGs) can result in little or no security, so this is not the place to cut corners. generating quality random numbers is genuinely difficult 😭 NIST Special Publication 800-90A [SP80090A], FIPS 186-3 [FIPS186], and [RFC4086] have random number generation guidance if you need it 📚

when RAs are used, the list of authorized RAs MUST be securely distributed out of band to CAs 🔒

the presence of the POP Link Witness Version 2 and POP Link Random attributes protects against substitution attacks 🛡️ so keep them around, ngl

the certificate policy for a particular environment will specify whether expired certificates can be used to sign certification requests. read your policy, no cap 🧐

10. IANA Considerations

this document has no IANA actions 🌷 nothing to register here, all clear ✨

11. References

11.1. Normative References ✨

okay bestie, these are the docs this one needs to read first, so no skipping 🫶

11.2. Informative References 📚

these ones are more like "good to know" reading, not required reading 🌸

  • [SP80057] National Institute of Standards and Technology, "Recommendation for Key Management, Part 1: General", DOI 10.6028/NIST.SP.800-57pt1r4, Special Publication 800-57, Part 1, Revision 4, January 2016, <http://doi.org/10.6028/NIST.SP.800-57pt1r4>.
  • [SP80059] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", DOI 10.6028/NIST.SP.800-59, Special Publication 800-59, August 2003, <https://csrc.nist.gov/publications/detail/sp/800-59/final>.
  • [SP80090A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", DOI 10.6028/NIST.SP.800-90Ar1, Special Publication 800-90A Revision 1, June 2015, <http://doi.org/10.6028/NIST.SP.800-90Ar1>.

Appendix A. Scenarios 🎀

okay this is the fun part, the "here's how it actually plays out in real life" section 🦋 these are some enrollment and rekey scenarios the profile supports. it's not trying to lock anything down, so CMC can still do its thing 💅

A.1. Initial Enrollment 🌱

so there are three ways to authenticate a first-time enrollment request, periodt:

  1. Previously certified signature key-pair (e.g., Manufacturer Installed Certificate).
  2. Shared-secret distributed securely out of band.
  3. RA authentication.

A.1.1. Previously Certified Signature Key-Pair 🔑

in this one the end-entity already has a private signing key and a matching public key certificate, both from a cryptographic module manufacturer the CA recognizes. the end-entity signs a Full PKI Request with the private key that matches the subject public key of that previously installed signature certificate 🔐 then the CA checks that the old cert is still authorized and issues a shiny new certificate. so iconic, the old cert literally vouches for the new one ✨

A.1.2. Shared-Secret Distributed Securely Out of Band 🤫

here the CA sends a shared-secret out of band to the end-entity, and the end-entity uses it to authenticate its certification request. the end-entity signs the Full PKI Request with the private key it's requesting a certificate for, and it includes the Identity Proof Version 2 control to authenticate the request using that shared-secret 🫶 the CA can use either the Identification control or the subject name in the end-entity's enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] certification request message to figure out which request this is. then the end-entity does either the POP Link Witness Version 2 mechanism described in [RFC5272], Section 6.3.1.1, or the shared-secret/subject distinguished name linking mechanism described in [RFC5272], Section 6.3.2. one lowkey plot twist: the subject name in that enclosed PKCS #10 [RFC2986] or CRMF [RFC4211] request doesn't have to match the cert that gets issued 🙈 it's only there to help the CA find the right request (and the matching shared-secret).

A.1.3. RA Authentication 🧚

this one's for when the end-entity can't auto-authenticate its enrollment request to the CA, either because it has nothing to authenticate with or because organizational policy says an RA has to be involved 💜 the end-entity makes a Full PKI Request and sends it to an RA. the RA verifies the request is authentic. if it's approved, the RA encapsulates and signs the request as described in Section 4.2 and forwards the new request to the CA. the subject name in the PKCS #10 [RFC2986] or CRMF [RFC4211] certification request isn't required to match the issued certificate. it just helps identify the request to the RA and/or CA, bestie 🍓

A.2. Rekey 🔄

there are two rekey scenarios, one for signature certificates and one for key establishment certificates 🌈 usually organizational policy wants certificates to still be valid before they can be rekeyed, and if rekey isn't possible it may require initial enrollment to happen again. some policies might allow a grace period where an expired certificate can still be used to rekey, which is kinda giving second chances 🥹

A.2.1. Rekey of Signature Certificates ✍️

when a signature certificate gets rekeyed, the PKCS #10 [RFC2986] or CRMF [RFC4211] certification request message inside the Full PKI Request has the same subject name as the current signature certificate. and the Full PKI Request gets signed by the current private key that matches the current signature certificate 💅

A.2.2. Rekey of Key Establishment Certificates 🗝️

for key establishment certificates, the Full PKI Request usually gets signed by the current private key that matches the current signature certificate. if there isn't a current signature certificate, one of the initial enrollment options in Appendix A.1 may be used instead 💖

Authors' Addresses 🌸

  • Michael Jenkins, National Security Agency, Email: mjjenki@nsa.gov
  • Lydia Zieglar, National Security Agency, Email: llziegl@tycho.ncsc.mil
📦 where this page comes from