RFC 9733

BRSKI with Alternative Enrollment (BRSKI-AE)

📅 published March 2025, from ietf

RFC 9733: BRSKI with Alternative Enrollment (BRSKI-AE) 🎀

Okay bestie, so this one is from the IETF, and it's a Standards Track doc, which means it's the real deal, not just a vibe-check or an experiment 💅. It was written by D. von Oheimb (editor), S. Fries, and H. Brockhaus, all from Siemens 🦋, and it was published in March 2025 ✨. It's RFC 9733, and the ISSN is 2070-1721 🌸.

It doesn't obsolete anything, and it doesn't update anything listed here either, but it does update the BRSKI reference architecture, so that's the one to keep an eye on 👑.

Abstract

So the whole point of this doc is to make BRSKI (Bootstrapping Remote Secure Key Infrastructure) way more flexible 🧚. Normally BRSKI uses EST (Enrollment over Secure Transport) to get device certificates, and that's just... fine, but not always 🙈. BRSKI-AE says "hey, what if we use other enrollment protocols instead?" 💖

The big example is CMP (Certificate Management Protocol), which uses authenticated self-contained signed objects for its certification messages. Those objects carry their own proof of who sent them, which is lowkey iconic 😭. It means the device can get onboarded in lots of different network setups, and it's designed to be secure and scalable across all of them 🌈.

Status of This Memo

This is an Internet Standards Track document 💜. That's the IETF saying it's been properly reviewed, the community agrees on it, and the IESG approved it for publication ✨. If you want the deeper deets on what Internet Standards are, check Section 2 of RFC 7841 🫶.

If you want the latest status, any errata, or a way to send feedback, head to https://www.rfc-editor.org/info/rfc9733 🔥.

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

This doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions 💅. Any code components pulled out of this doc have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License 🎀.

Table of Contents

1.  Introduction
  1.1.  Supported Scenarios
2.  Terminology and Abbreviations
3.  Basic Requirements and Mapping to Solutions
  3.1.  Solution Options for Proof of Possession
  3.2.  Solution Options for Proof of Identity
4.  Adaptations to BRSKI
  4.1.  Architecture
  4.2.  Message Exchange
    4.2.1.  Pledge - Registrar Discovery
    4.2.2.  Pledge - Registrar - MASA Voucher Exchange
    4.2.3.  Pledge - Registrar - MASA Voucher Status Telemetry
    4.2.4.  Pledge - Registrar - RA/CA Certificate Enrollment
    4.2.5.  Pledge - Registrar Enrollment Status Telemetry
  4.3.  Enhancements to the Endpoint Addressing Scheme of BRSKI
5.  Instantiation with Existing Enrollment Protocols
  5.1.  BRSKI-CMP: BRSKI-AE Instantiated with CMP
  5.2.  Support of Other Enrollment Protocols
6.  IANA Considerations
7.  Security Considerations
8.  Privacy Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Appendix A.  Application Examples
  A.1.  Rolling Stock
  A.2.  Building Automation
  A.3.  Substation Automation
  A.4.  Electric Vehicle Charging Infrastructure
  A.5.  Infrastructure Isolation Policy
  A.6.  Sites with Insufficient Levels of Operational Security
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

So, BRSKI [RFC8995] is usually paired with EST [RFC7030] as the enrollment protocol for operator-specific device certificates. It runs over HTTP over TLS for secure message transfer 🌸. BRSKI-AE is the variant that swaps in alternative enrollment protocols, which use authenticated self-contained objects for getting the device certificate 💖.

This approach has some seriously good perks 🦋. It lets you authenticate where requests and responses came from, independently of how the messages get transported. That means you get end-to-end authentication (end-to-end proof of origin) even across multiple transport hops, and it supports asynchronous certificate enrollment too 😭. So you get architectural flexibility about where and when the final authentication and authorization of certification requests happens, and the integrity and authenticity of enrollment messages still stay protected with full cryptographic strength 💅.

This spec keeps the main BRSKI characteristics, which are:

  • The pledge is assumed to have gotten its Initial Device IDentifier (IDevID) [IEEE_802.1AR-2018] credentials during manufacturing 🏭. It uses them to authenticate itself to the Manufacturer Authorized Signing Authority (MASA) [RFC8995], to the registrar (the access point of the target domain), and possibly to other parts of the domain where it'll be operating 🧚.
  • The pledge first gets a trust anchor, via the voucher [RFC8366] exchange, for authenticating entities in the domain, like the domain registrar 👑.
  • The pledge then gets its Locally Significant Device IDentifier (LDevID) [IEEE_802.1AR-2018] 🎀. To do that, it generates a private key called an "LDevID secret". Then it asks the domain registrar, which asks the PKI of its new domain, for a domain-specific device certificate called an "LDevID certificate" 🔥. If that works, it gets the LDevID certificate along with its certificate chain ✨.

The goals of BRSKI-AE are to upgrade BRSKI by letting LDevID certificate enrollment run over an alternative protocol to EST that:

  • supports end-to-end authentication over multiple transport hops, and
  • makes secure message exchanges possible over any kind of transfer mechanism, including asynchronous delivery 🌈.

Fun fact: the BRSKI voucher exchange between pledge, registrar, and MASA already uses authenticated self-contained objects, and those inherently have these properties 💜.

The existing well-known URI structure for BRSKI and EST messages gets extended with one more path element, which says which enrollment protocol is being used 🦋.

This spec also lets the registrar offer multiple enrollment protocols, so pledges and their developers can pick the most fitting one based on the overall approach and the specific endpoints 💖.

Heads up: [RFC8995] specifies HTTP over TLS, but variations are possible too, like Constrained BRSKI [cBRSKI], which uses the Constrained Application Protocol (CoAP) over DTLS 🙈. Here, "HTTP" and "TLS" are just references to the most common implementation. Variants using CoAP and/or DTLS are implied wherever they apply, since the distinctions don't matter for this doc 🫶.

This spec, together with its referenced docs, is enough to support BRSKI with the Certificate Management Protocol (CMP) [RFC9480] as profiled in the Lightweight CMP Profile (LCMPP) [RFC9483] 🔥. If you want to integrate BRSKI with an enrollment protocol or profile other than LCMPP, you'll need additional IANA registrations, as detailed in this document 💅. You might also need extra specs for the protocol or profile details, but those are outside this doc's scope 🌸.

1.1. Supported Scenarios ✨

BRSKI-AE is designed for scenarios like these 🦋:

  • When pledges and/or the target domain use an existing certificate enrollment protocol other than EST, such as CMP 💖.
  • When the application context rules out EST for certificate enrollment, for reasons like:
    • The Registration Authority (RA) isn't co-located with the registrar and needs end-to-end authentication of requesters, which EST can't do over multiple transport hops 😭.
    • The RA or Certification Authority (CA) operator requires auditable proof of origin for Certificate Signing Requests (CSRs), and TLS can't provide that because it only offers transient source authentication 💅.
    • Certificates are requested for key types, like Key Encapsulation Mechanism (KEM) keys, that don't support signing or other single-shot proof-of-possession methods like the ones described in [RFC6955] 🧚. EST relies on CSRs in PKCS #10 format [RFC2986], and it can't handle these key types, because EST needs proof-of-possession methods that work inside a single message. Proof of possession for KEM keys needs a fresh challenge value received beforehand 🎀.
    • The pledge implementation uses security libraries that don't support EST, or uses a TLS library without support for the "tls-unique" value [RFC5929], which EST needs for strong binding of source authentication 👑.
  • When full RA functionality isn't available on-site in the target domain, and connectivity to an off-site RA might be intermittent or totally offline 🌈.
  • When authoritative actions by a local RA at the registrar aren't enough to fully and reliably authorize pledge certification requests, maybe because it can't access the necessary data or because security measures are inadequate, like storing private keys locally 🔥.

Bootstrapping can be managed in lots of ways depending on the application domain 💜. Appendix A has illustrative examples from different industrial control system environments and operational contexts that motivate supporting alternative enrollment protocols 🫶.

Part 1 of 7. Keep going, bestie, there's more coming 💖

2. Terminology and Abbreviations ✨

okay bestie, let's get into the key words first 🫶 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" mean what BCP 14 [RFC2119] [RFC8174] says they mean, but ONLY when they show up in all capitals like this. Lowercase ones are just regular English 💅

This doc leans on the terms defined in [RFC8995], [RFC5280], and [IEEE_802.1AR-2018], and it repeats some of them here, plus a few extra ones. To stay independent of any one enrollment protocol, it uses generic PKI management language 🦋

Here's the glossary 💖

asynchronous: messages get delivered with gaps in time between a pledge and some backend system (e.g., an RA) 🌸

attribute request: a message asking for content to be put into the certification request 🎀

attribute response: a message that answers the attribute request ✨

authenticated self-contained object: a data structure that's cryptographically bound to the identity of whoever made it, using a digital signature attached to the actual object and a private key of the originator, like the IDevID secret 🔐

backend: a domain component that's placed separately from the domain registrar, and it can be on-site or off-site 🧚

CA certs request: a message asking for CA certificates 🍓

CA certs response: a message that answers a CA certs request 💜

certificate confirm: a message telling the backend PKI that the requester got the new certificate and accepted it 🌈

certification request: a message asking for a certificate along with proof of identity 🦋

certification response: a message that answers a certification request 💅

local RA: the same thing as LRA 🌸

off-site: the location of a component, service, or functionality (like an RA or CA) that is NOT at the registrar's site. This could be a central site or a cloud service, and the connection to it may be intermittent ☁️

on-site: the location of a component, service, or functionality that IS at the registrar's site 🏠

PKI/registrar confirm: the PKI's acknowledgment of the certificate confirm 💖

pledge: a device that's about to be bootstrapped into a target domain. It requests an LDevID using IDevID credentials that its manufacturer installed 🎀

registrar: short for domain registrar ✨

site: the place where an entity like a pledge, registrar, or PKI component is deployed. A target domain can have multiple sites 🗺️

synchronous: messages get delivered with no interruptions in time between a pledge and a registrar or backend system (e.g., the MASA) ⭐

target domain: the domain that a pledge is going to be bootstrapped into 👑

And here are the abbreviations 🫶

BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995] 🔑

BRSKI-AE: BRSKI with Alternative Enrollment. This is a variation of BRSKI [RFC8995] where BRSKI-EST, the enrollment protocol between the pledge and the registrar, gets swapped out for enrollment protocols that support end-to-end authentication of the pledge to the RA, such as CMP 🦋

CA: Certification Authority 🏛️

CMC: Certificate Management over CMS 💌

CMP: Certificate Management Protocol [RFC4210] [RFC9480] 💎

CMS: Cryptographic Message Syntax 📜

CRMF: Certificate Request Message Format 📝

CSR: Certificate Signing Request 📨

EST: Enrollment over Secure Transport [RFC7030] 🌷

IDevID: Initial Device IDentifier (of a pledge, provided by the manufacturer and made up of a private key and the related X.509 certificate with its chain) 🪪

LCMPP: Lightweight CMP Profile [RFC9483] 🌙

LDevID: Locally Significant Device IDentifier (of a pledge, provided by its target domain and made up of a private key and the related X.509 certificate with its chain) 🏡

LRA: Local Registration Authority. A subordinate RA that sits close to the entities being enrolled and is separate from a subsequent RA. In BRSKI-AE, it's needed if a backend RA is used. In that case, the LRA is co-located with the registrar 🤝

MASA: Manufacturer Authorized Signing Authority. Provides vouchers 🎟️

RA: Registration Authority. The PKI component that a CA typically hands certificate management jobs to, like authenticating pledges and doing authorization checks on certification requests 👑

SCEP: Simple Certificate Enrolment Protocol 🍓

3. Basic Requirements and Mapping to Solutions 💅

based on the intended target scenarios from Section 1.1 and the application examples in Appendix A, here are the requirements we derive to support authenticated self-contained objects as containers carrying certification requests 🎀

The following properties are required for a certification request:

  • Proof of possession: shows access to the private key that goes with the public key inside a certification request. This is usually done with a self-signature using that private key, but it can also be done indirectly. See [RFC4210], Section 4.3 ✨
  • Proof of identity (also called "proof of origin"): gives data origin authentication of the certification request. This is usually done with a signature made with the pledge IDevID secret over some data. That data needs to include a sufficiently strong identifier of the pledge, like the device serial number that's typically in the subject of the IDevID certificate 🔐

What comes next is a NON-exhaustive list of solution examples, based on existing technology in IETF documents 🌸

3.1. Solution Options for Proof of Possession

Certificate Signing Request (CSR) objects are data structures that only protect the integrity of the data inside them, and they give proof of possession for a (locally generated) private key. The important types of CSR data structures are 🧚

  • PKCS #10 [RFC2986]: this super common form of CSR is self-signed to protect its integrity and to prove possession of the private key that matches the public key in the request 💖
  • Certificate Request Message Format (CRMF) [RFC4211]: this less common but more general CSR format supports several ways of integrity protection and proof of possession. Usually a self-signature is used, made over (part of) the structure with the private key that matches the included public key. CRMF also supports more proof-of-possession methods for key types that can't sign. For details, see [RFC4211], Section 4 🦋

It's worth noting that CSR integrity protection covers the public key, because the public key is part of the data signed by the matching private key. BUT this signature doesn't give data origin authentication (aka proof of identity of the requester), because the key pair is brand new and doesn't have a confirmed identity attached to it yet 🙈

3.2. Solution Options for Proof of Identity

Binding a Certificate Signing Request (CSR) to an existing authenticated credential (which in the BRSKI context is the IDevID certificate) lets you prove origin, and that in turn supports an authorization decision on the CSR 🔥

The binding of data origin authentication to the CSR is usually handed off to the certificate management protocol. This binding can be done through security options in an underlying transport protocol like TLS, as long as the authorization of the certification request is (sufficiently) done at the next communication hop. Depending on the key type, the binding can also be done in a stronger, transport-independent way by wrapping the CSR with a signature 💅

Existing enrollment protocols handle this requirement in a few different ways, like 🌈

  • EST [RFC7030] and its variant EST-coaps [RFC9148] use PKCS #10 to encode CSRs. A CSR like this wasn't designed to include proof of origin, but there's a limited, indirect way to bind it to the source authentication of the underlying TLS session. This works by putting the "tls-unique" value [RFC5929] from the TLS handshake into the CSR. Since the EST "/simpleenroll" endpoint used in BRSKI optionally supports this, and the TLS handshake in BRSKI includes certificate-based client authentication of the pledge with its IDevID credentials, the proof of pledge identity (as an authenticated TLS client) can be bound to the CSR 🦋

BUT this binding is only valid inside the TLS session with the registrar, which acts as the EST server and typically also as an RA. So even this cryptographic binding of the authenticated pledge identity to the CSR can't be seen or verified by authorization points outside the registrar, like a (second) RA in the backend 😭 What the registrar needs to do is authenticate and pre-authorize the pledge, and then tell the (second) RA about it. It does this by signing the forwarded certification request with its private key and a related certificate that has the id-kp-cmcRA extended key usage attribute 🔏

[RFC7030], Section 2.5 sketches wrapping PKCS #10 formatted CSRs in a Full PKI Request message sent to the /fullcmc endpoint. This would allow source authentication at the message level, so the registrar could forward it to external RAs in a meaningful way. This approach isn't sufficiently described yet and likely hasn't been implemented 🙈

  • The Simple Certificate Enrolment Protocol (SCEP) [RFC8894] supports using a shared secret (passphrase) or an existing certificate to protect CSRs, based on SCEP Secure Message Objects that use Cryptographic Message Syntax (CMS) wrapping [RFC5652]. Wrapping with an existing IDevID in SCEP is called "renewal". This way, SCEP doesn't rely on the security of the underlying message transfer 🍓
  • CMP [RFC4210] [RFC9480] supports using a shared secret (passphrase) or an existing certificate (which can be an IDevID credential) to authenticate certification requests through the PKIProtection structure in a PKIMessage. The certification request is usually encoded with CRMF, though PKCS #10 is supported as an alternative. So CMP doesn't rely on the security of the underlying message transfer 💎
  • Certificate Management over CMS (CMC) [RFC5272] also supports using a shared secret (passphrase) or an existing certificate to protect certification requests, which can be in either a CRMF or PKCS #10 structure. Proof of identity can be provided as part of a Full CMC Request based on CMS [RFC5652] and signed with an existing IDevID secret. So CMC doesn't rely on the security of the underlying message transfer 🌙

To sum up: EST doesn't meet the requirements for authenticated self-contained objects, but SCEP, CMP, and CMC do 👑 This document mainly focuses on CMP, because it has more industry adoption than CMC, and SCEP has issues that aren't detailed here 💜

4. Adaptations to BRSKI ✨

Okay so, bestie, this is where BRSKI gets a glow-up 💖 BRSKI-AE adds some generalizations on top of BRSKI [RFC8995] so that alternative certificate enrollment protocols can join the party. They support end-to-end authentication, asynchronous enrollment, and way more flexible system architectures 🦋 The authenticated self-contained objects from Section 3 above can be used for certificate enrollment, and RA functionality can be deployed freely in the target domain. Some of that RA functionality can even be spread across several nodes 🌸

The enhancements are kept to a minimum, though, because nobody wants to reinvent the wheel 💅 Mostly, the communication follows the BRSKI model and uses the existing BRSKI architecture elements. The pledge still starts things off with the domain registrar, and it still interacts with the MASA as usual for voucher request and response processing 🫶

4.1. Architecture 🎀

The key thing here is that the authorization of a certification request MUST be performed based on an authenticated self-contained object 👑 The certification request is bound in a self-contained way to a proof of origin based on the IDevID credentials. Because of that, the certification request MAY be transferred using any mechanism or protocol 🧚 Authentication and authorization of the certification request can be done by the domain registrar and/or by backend domain components. As mentioned in Section 1.1, these components may be offline or off-site. The registrar and other on-site domain components may have no connectivity to them, or only temporary (intermittent) connectivity 🙈

This leads to some generalizations in where the logical elements sit and how they're enhanced, as shown in Figure 1 💜

                                            +------------------------+
      +--------------Drop-Ship--------------| Vendor Service         |
      |                                     +------------------------+
      |                                     | M anufacturer|         |
      |                                     | A uthorized  |Ownership|
      |                                     | S igning     |Tracker  |
      |                                     | A uthority   |         |
      |                                     +--------------+---------+
      |                                                      ^
      |                                                      |
      V                                                      | BRSKI-
   +--------+     .........................................  | MASA
   |        |     .                                       .  |
   |        |     .  +-------+          +--------------+  .  |
   | Pledge |     .  | Join  |          | Domain       |<----+
   |        |<------>| Proxy |<-------->| Registrar    |  .
   |        |     .  |       |          | w/ LRA or RA |  .
   | IDevID |     .  +-------+          +--------------+  .
   |        |   BRSKI-AE over TLS                ^        .
   +--------+   using, e.g., LCMPP               |        .
                  .                              |        .
                  ...............................|.........
               on-site (local) domain components |
                                                 |
                                                 | e.g., LCMPP
                                                 |
    .............................................|...............
    . Public-Key Infrastructure (PKI)            v              .
    . +---------+     +---------------------------------------+ .
    . |         |<----+   Registration Authority RA           | .
    . |    CA   +---->|   (unless part of Domain Registrar)   | .
    . +---------+     +---------------------------------------+ .
    .............................................................
            backend (central or off-site) domain components

        Figure 1: Architecture Overview Using Backend PKI Components

The architecture overview in Figure 1 has the same logical elements as BRSKI, just with a more flexible placement of the authentication and authorization checks on certification requests. Depending on the application scenario, the registrar MAY still do all of these checks (like in BRSKI) or only do part of them 🌈

Here's the rundown on the on-site components in the pledge's target domain, shown in Figure 1 🍓

  • Join Proxy: This has the same requirements as in [RFC8995] (see [RFC8995], Section 4).
  • Domain Registrar (including LRA or RA functionality): In BRSKI-AE, the domain registrar has mostly the same job as in BRSKI. It's still the gatekeeper of the domain for onboarding new devices, and it still helps pledges talk to their MASA and the domain PKI. But there are some generalizations and specific requirements, bestie:
    1. The registrar MUST support at least one certificate enrollment protocol with authenticated self-contained objects for certification requests. To this end, the URI scheme for addressing endpoints at the registrar is generalized (see Section 4.3).
    2. Rather than having full RA functionality, the registrar MAY act as a Local Registration Authority (LRA) and delegate part of its involvement in certificate enrollment to a backend RA. In such scenarios, the registrar optionally checks certification requests it receives from pledges and forwards them to the backend RA, which performs the remaining parts of the enrollment request validation and authorization. Note that the backend RA may need information about the authorization of pledges from the registrar or from other sources. On the way back, the registrar forwards responses by the PKI to the pledge on the same channel 💅

To support end-to-end authentication of the pledge across the registrar to the backend RA, the certification request signed by the pledge needs to be upheld and forwarded by the registrar. Therefore, for its communication with the PKI, the registrar cannot use an enrollment protocol that is different from the enrollment protocol used between the pledge and the registrar 🔥

  1. The use of a certificate enrollment protocol with authenticated self-contained objects gives freedom in how enrollment messages get transferred between the pledge and an RA. BRSKI demands that the RA accept certification requests for LDevIDs only with the consent of the registrar. BRSKI-AE also guarantees this when the RA is not part of the registrar, even if the message exchange with backend systems is unprotected and involves further transport hops. See Section 7 for details on how this can be achieved 🦋

Despite all these generalizations of the enrollment phase, the final step of BRSKI, the enrollment status telemetry, is kept exactly as it is ✨

Next up are the components provided by the vendor or manufacturer outside the target domain 🌸

  • MASA: This has the functionality described in [RFC8995]. The voucher exchange with the MASA via the domain registrar is performed as described in [RFC8995].
Note: The definition of the interaction with the MASA in Section 5 of [RFC8995] implies that it may be synchronous (using voucher requests with nonces) or asynchronous (using nonceless voucher requests). 🙈
  • Ownership Tracker: This is as defined in [RFC8995].

And then there are the backend target domain components, which may be located on-site or off-site in the target domain 🧚

  • RA: This performs centralized certificate management functions as a PKI for the domain operator. In case these functions are not entirely performed by the domain registrar, it performs the final validation and authorization of certification requests. Otherwise, the RA co-located with the domain registrar connects directly to the CA 💜
  • CA (also called "domain CA"): This generates domain-specific certificates according to certification requests that have been authenticated and authorized by the registrar and/or an extra RA 👑

Based on the diagram in [RFC8995], Section 2.1 and the architectural changes, the original protocol flow gets split into several phases. Some parts match the original approach and some parts are different, like this 🎀

  • Discover: This is mostly as in step (1) of [RFC8995]. For details, see Section 4.2.1.
  • Identify: This is the same as in step (2) of [RFC8995].
  • Voucher exchange: This is the same as in steps (3) and (4) of [RFC8995].
  • Voucher status telemetry: This is the same as directly after step (4) in [RFC8995].
  • Certificate enrollment phase: The use of EST in step (5) is changed to employing a certificate enrollment protocol that uses an authenticated self-contained object for requesting the LDevID certificate.

It is REQUIRED to use the (D)TLS channel established between the pledge and registrar to transport the certificate enrollment request and response messages. To this end, the enrollment protocol, the pledge, and the registrar need to support the use of this existing channel for certificate enrollment. Because of this architecture, the pledge does not need to establish additional connections for certificate enrollment, and the registrar keeps full control over the certificate enrollment traffic 🫶

  • Enrollment status telemetry: This is the final exchange of step (5) of [RFC8995].

4.2. Message Exchange 💖

The behavior of a pledge described in [RFC8995], Section 2.1 is kept, with one major exception. After finishing the Imprint step (4), the Enroll step (5) MUST be performed with an enrollment protocol utilizing authenticated self-contained objects, as explained in Section 3. Section 5 discusses selected suitable enrollment protocols and applicable options 😭

An abstract overview of the BRSKI-AE protocol can be found in the graphics on slide 4 of [BRSKI-AE-overview] ✨

4.2.1. Pledge - Registrar Discovery 🔍

Discovery as specified in [RFC8995], Section 4 does not support discovering registrars with enhanced feature sets. A pledge can't find out this way whether a discovered registrar supports the certificate enrollment protocol it expects, such as CMP 💀

As a more general solution, the BRSKI discovery mechanism can be extended to provide up-front information on the capabilities of registrars. For further discussion, see [BRSKI-discovery] 🌟

In the absence of such a generally applicable solution, BRSKI-AE deployments may use their own particular way of doing discovery. Section 5.1 defines a minimalist approach that MAY be used for CMP 🍓

4.2.2. Pledge - Registrar - MASA Voucher Exchange 🧚

The voucher exchange is performed as specified in [RFC8995] 💅

4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry 🦋

The voucher status telemetry is performed as specified in [RFC8995], Section 5.7 🌸

4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment ✨

okay so this section straight up replaces the EST integration for PKI bootstrapping from [RFC8995], Section 5.9 🎀 (but [RFC8995], Section 5.9.4 is still the final phase, more on that below 👀).

the certificate enrollment phase can involve a bunch of messages 📨. what actually shows up depends on the application scenario, the enrollment protocol in use, and other factors 🧚

The only message exchange REQUIRED is the actual certification request and its response. Further message exchanges MAY be performed as needed 💖

Note: the message exchanges marked OPTIONAL in Figure 2 below cover everything that EST supports in BRSKI. The last OPTIONAL one, certificate confirmation, isn't supported by EST but by CMP and other enrollment protocols 🙈
 +------+                          +---------+              +--------+
 |Pledge|                          |Domain   |              |Operator|
 |      |                          |Registrar|              |RA/CA   |
 |      |                          |(JRC)    |              |(PKI)   |
 +------+                          +---------+              +--------+
  |                                     |                           |
  |[OPTIONAL request of CA certificates]|                           |
  |------- CA Certs Request (1) ------->|                           |
  |                                     | [OPTIONAL forwarding]     |
  |                                     |--- CA Certs Request ----->|
  |                                     |<-- CA Certs Response -----|
  |<------ CA Certs Response (2) -------|                           |
  |                                     |                           |
  |[OPTIONAL request of attributes      |                           |
  | to include in Certification Request]|                           |
  |------- Attribute Request (3) ------>|                           |
  |                                     | [OPTIONAL forwarding]     |
  |                                     |--- Attribute Request ---->|
  |                                     |<-- Attribute Response ----|
  |<------ Attribute Response (4) ------|                           |
  |                                     |                           |
  |[REQUIRED certification request]     |                           |
  |------- Certification Request (5) -->|                           |
  |                                     | [OPTIONAL forwarding]     |
  |                                     |---Certification Request-->|
  |                                     |<--Certification Resp.  ---|
  |<----- Certification Response (6) ---|                           |
  |                                     |                           |
  |[OPTIONAL certificate confirmation]  |                           |
  |------- Certificate Confirm (7) ---->|                           |
  |                                     | [OPTIONAL forwarding]     |
  |                                     |--- Certificate Confirm--->|
  |                                     |<-- PKI Confirm -----------|
  |<------ PKI/Registrar Confirm (8) ---|                           |

Figure 2: Certificate Enrollment Message Flow

okay real talk, the connections between the registrar and the PKI bits of the operator (RA, CA, etc.) might be intermittent or totally offline 📡. messages should be sent as soon as there's enough transfer capacity 🚀

so the [OPTIONAL forwarding] label in Figure 2 means that when the registrar gets a request of that type from a pledge, it MAY answer the request directly 💅. if it does, it MUST authenticate its responses with the same credentials it uses for itself at the TLS level for the voucher exchange 🔐. otherwise it MUST forward the request to the RA and pass whatever response comes back on to the pledge 🫶

whether the registrar forwards or answers directly can depend on all sorts of static and dynamic stuff ✨. think the application scenario, what the registrar can do, what the local RA (maybe co-located with the registrar) can do, the enrollment protocol, and the exact contents of the request 🌸

there are a few ways the registrar could answer CA certificate or certification request attribute requests on its own 🦋. it could cache responses it got from the domain PKI and reuse them for the same data later, or the contents could just be provisioned at the registrar directly 💜

certification requests usually have to be handled by the backend PKI, BUT the registrar can reply directly with an error response if it decides the request should be rejected, like if it isn't properly authenticated or authorized 🙅‍♀️. certificate confirmation messages will usually get forwarded to the backend PKI too, but if the registrar knows they aren't needed or wanted there, it can acknowledge them itself 🎀

here's the abstract breakdown of the flow in Figure 2 🧁

  • CA Certs Request (1): the pledge optionally asks for the latest relevant CA certificates 📜. this makes sure the pledge has the full set of current CA certificates beyond the pinned-domain-cert (which is in the voucher and might just be the domain registrar certificate) 💖
  • CA Certs Response (2): this MUST contain any intermediate CA certificates the pledge might need to validate certificates, and it MAY contain the LDevID trust anchor 🌈
  • Attribute Request (3): usually, the automated bootstrapping happens with zero local admin config on the pledge 🤖. but sometimes the pledge might want to include extra attributes that are specific to the target domain in the Certification Request (5). the attribute request can be used to grab those ahead of time 🍓
  • Attribute Response (4): this MUST contain the attributes requested in (3) so they can be included in the subsequent Certification Request (5). for example, [RFC8994], Section 6.11.7.2 explains how the attribute request signals the 'acp-node-name' field the pledge needs to enroll into an Autonomic Control Plane (ACP) domain 🦋
  • Certification Request (5): this MUST contain the authenticated self-contained object that proves both possession of the matching private key and the identity of the requester 🔑
  • Certification Response (6): on success, this MUST contain the requested certificate, and it MAY include extra info like certificates of intermediate CAs and any additional trust anchors 🎁
  • Certificate Confirm (7): this is an optional confirmation sent after the requested certificate has been received and validated 📬. if it's sent, it MUST contain a positive or negative confirmation from the pledge to the PKI on whether the certificate was enrolled successfully and fits its needs 💅
  • PKI/Registrar Confirm (8): this is the PKI's acknowledgment, and it MUST be sent when Certificate Confirm comes in ✅

the generic messages above can be implemented with any certificate enrollment protocol that supports authenticated self-contained objects for the certification request, as described in Section 3. examples are in Section 5 ✨

Note: the optional certificate confirmation from the pledge to the PKI is totally separate from the mandatory enrollment status telemetry between the pledge and the registrar in the final BRSKI-AE phase, which is up next 👀

4.2.5. Pledge - Registrar Enrollment Status Telemetry 📊

the enrollment status telemetry follows [RFC8995], Section 5.9.4 🫶

in [RFC8995] this is described as part of the certificate enrollment step 🙃. but because this document generalizes the enrollment protocol, it gets treated as its own separate phase here 💜

4.3. Enhancements to the Endpoint Addressing Scheme of BRSKI

okay so BRSKI-AE stretches the addressing scheme from [RFC8995], Section 5 so it can handle alternative enrollment protocols that use authenticated, self-contained objects for certification requests (see Section 5 too) 💅 These extras are built to play nicely with existing Registration Authorities (RAs) and Certification Authorities (CAs) that already support those protocols, so you can use them without any modifications 🫶

The addressing scheme in [RFC8995] for certification requests, related CA certificates, and CSR attributes retrieval functions uses the definition from EST [RFC7030]. For example, simple enrollment is /.well-known/est/simpleenroll. This gets generalized to /.well-known/<enrollment-protocol>/<request>, where <enrollment-protocol> is a certificate enrollment protocol ✨ Note that enrollment here is a message sequence that has at least a certification request and a certification response. To keep things maximally compatible with BRSKI, these conventions apply:

  • <enrollment-protocol>: This MUST reference the protocol being used. Existing values include 'est' [RFC7030] as in [RFC8995] and 'cmp' as in [RFC9483] and Section 5.1 below. Values for other existing protocols such as CMC and SCEP, as well as newly defined protocols, are outside the scope of this document. For use of the <enrollment-protocol> and <request> URI components, they would need to be specified in a suitable RFC and placed into the "Well-Known URIs" registry, just as EST in [RFC7030].
  • <request>: If present, this path component MUST describe the operation requested depending on the enrollment protocol being used. Enrollment protocols are expected to define their request endpoints, as is done by existing protocols (also see Section 5).

Well-known URIs for various endpoints on the domain registrar are already defined as part of the base BRSKI specification or indirectly by EST. In addition, alternative enrollment endpoints MAY be supported by the registrar 🌸

A pledge SHOULD use the endpoints defined for the enrollment protocol(s) it can use. It will recognize whether the protocol it uses and the specific request it wants are understood and supported by the domain registrar. It does this by sending the request to the respective endpoint using the addressing scheme above, then checking the HTTP status code of the response. If the pledge uses endpoints that are not standardized, it risks the registrar not recognizing the request, so it may get rejected even when the registrar supports the intended protocol and operation 😭

The list below is an illustrative example of a domain registrar supporting several EST options and CMP options for use in BRSKI-AE. It shows the supported endpoints a pledge may connect to for bootstrapping, covering both voucher handling and enrollment. The CMP-related enrollment endpoints are defined as well-known URIs in CMP Updates [RFC9480] and the Lightweight CMP Profile [RFC9483] 🦋

  • /.well-known/brski/voucherrequest
  • /.well-known/brski/voucher_status
  • /.well-known/brski/enrollstatus
  • /.well-known/est/cacerts
  • /.well-known/est/csrattrs
  • /.well-known/est/fullcmc
  • /.well-known/cmp/getcacerts
  • /.well-known/cmp/getcertreqtemplate
  • /.well-known/cmp/initialization
  • /.well-known/cmp/pkcs10

5. Instantiation with Existing Enrollment Protocols

This section maps the generic requirements for proof of possession and proof of identity onto selected existing certificate enrollment protocols. It also specifies more details on using those enrollment protocols in BRSKI-AE 🎀

5.1. BRSKI-CMP: BRSKI-AE Instantiated with CMP

In this document, references to CMP follow the Lightweight CMP Profile (LCMPP) from [RFC9483] rather than [RFC4210] and [RFC9480], because the subset of CMP defined in the LCMPP covers the functionality we need 💖

Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP. These specific requirements apply (refer to Figure 2):

  • The validation of server response messages performed by the CMP client within the pledge MUST be based on the trust anchor established beforehand via the BRSKI voucher, i.e., on the pinned-domain-cert.

Note that the integrity and authenticity checks on the RA/CA by the CMP client can be stronger than for EST, because they don't need to happen hop-by-hop and are usually end-to-end 👑

  • CA Certs Request (1) and Response (2): Requesting CA certificates is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.1.
  • Attribute Request (3) and Response (4): Requesting certification request attributes is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.3.

Alternatively, the registrar MAY modify the requested certificate contents as specified in [RFC9483], Section 5.2.3.2.

  • Certification Request (5) and Response (6): Certificates SHALL be requested and provided as specified in the LCMPP from [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483], Section 4.1.4 (based on PKCS #10).

Proof of possession SHALL be provided in a manner suitable for the key type. Proof of identity SHALL be provided by signature-based protection of the certification request message, as outlined in [RFC9483], Section 3.2, using the IDevID secret.

When the registrar forwards a certification request from the pledge to a backend RA/CA, it is RECOMMENDED that the registrar wraps the original certification request in a nested message signed with its own credentials, as described in [RFC9483], Section 5.2.2.1. This approach explicitly conveys the registrar's consent to the RA while keeping the original certification request with the proof of origin provided by the pledge's signature 🔥

If additional trust anchors beyond the pinned-domain-cert need to be conveyed to the pledge, this SHOULD be done in the 'caPubs' field of the certification response rather than through a CA Certs Response.

  • Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit confirmation of new certificates to the RA/CA MAY be used as specified in [RFC9483], Section 4.1.1.
Note: independent of the certificate confirmation within CMP, enrollment status telemetry with the registrar at the BRSKI level will be performed as described in [RFC8995], Section 5.9.4. 🙈
  • If delayed delivery of CMP messages is needed (e.g., to support enrollment over an asynchronous channel), it SHALL be performed as specified in Sections 4.4 and 5.1.2 of [RFC9483].

The mechanisms for exchanging messages between the registrar and backend PKI components (i.e., RA and/or CA) are outside the scope of this document. CMP's independence from the message transfer mechanism gives you flexibility to pick the right exchange method for your scenario 🧚 For the applicable security and privacy considerations, refer to Sections 7 and 8. More guidance is in [RFC9483], Section 6.

BRSKI-AE with CMP can also be combined with Constrained BRSKI [cBRSKI], using CoAP for enrollment message transport as described by CoAP Transfer for CMP [RFC9482]. In those scenarios, the EST-specific parts of [cBRSKI] do not apply.

For BRSKI-AE scenarios where a general solution for discovering registrars with CMP support isn't available (cf. Section 4.2.1), the following minimalist approach MAY be used: perform discovery as defined in [RFC8995], Appendix B, but use the service name "brski-reg-cmp" (as defined in Section 6) instead of "brski-registrar" (as defined in [RFC8995], Section 8.6). Note that this approach does not support join proxies 🥺

5.2. Support of Other Enrollment Protocols

More instantiations of BRSKI-AE can be done, but they're left for future work 🔮

In particular, CMC [RFC5272] (using its in-band source authentication options) and SCEP [RFC8894] (using its 'renewal' option) could be used.

The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might also be used here. For EST-fullCMC, further specification is necessary.

6. IANA Considerations

IANA has registered the following service name in the "Service Name and Transport Protocol Port Number Registry" <https://www.iana.org/assignments/service-names-port-numbers> 📋

Service Name:  brski-reg-cmp
Transport Protocol(s):  tcp
Description:  Bootstrapping Remote Secure Key Infrastructure
   registrar with CMP capabilities according to the Lightweight CMP
   Profile (LCMPP) [RFC9483]
Assignee:  IESG <iesg@ietf.org>
Contact:  IETF <chair@ietf.org>
Reference:  RFC 9733
Note: we chose the suffix "cmp" here rather than some other abbreviation like "lcmpp", mainly because this document defines the normative CMP instantiation of BRSKI-AE, which means adherence to the LCMPP is necessary and sufficient. 💅

7. Security Considerations

The security considerations laid out in [RFC8995], Section 11 apply to the discovery and voucher exchange, as well as to the status exchange information. This is serious, bestie 😭

Even if the registrar delegates part or all of its RA role during certificate enrollment to a separate system, it still must be made sure that the registrar takes part in the decision on accepting or declining a request to join the domain, as required in [RFC8995], Section 5.3. Since this also covers obtaining a valid domain-specific certificate, it must be made sure that a pledge cannot get around the registrar when deciding whether it is granted an LDevID certificate by the CA 💀 There are various ways to fulfill this, including:

  • implicit consent;
  • the registrar signaling its consent to the RA out-of-band before or during the enrollment phase, for instance, by entering the pledge identity in a database;
  • the registrar providing its consent using an extra message that is transferred on the same channel as the enrollment messages, possibly in a TLS tunnel; and
  • the registrar explicitly stating its consent by signing the authenticated self-contained certificate enrollment request message in addition to the pledge.
Note: if EST was used, the registrar could give implicit consent on a certification request by forwarding the request to a PKI entity using a connection authenticated with a certificate containing an id-kp-cmcRA extension.

When CMP is used, the security considerations laid out in the LCMPP from [RFC9483] apply 🔐

8. Privacy Considerations

The privacy considerations laid out in [RFC8995], Section 10 apply as well 🌈

Note that CMP messages themselves are not encrypted. This may give eavesdroppers insight into which devices are bootstrapped into the domain. In turn, this might also be used to selectively block the enrollment of certain devices 🙈

To prevent such issues, the underlying message transport channel can be encrypted. This is already provided by TLS between the pledge and the registrar, and for the onward exchange with backend systems, encryption may need to be added ✨

9. References

9.1. Normative References 📚✨

These are the must-read docs, bestie. You can't really get the rest of this spec without them 🫶

9.2. Informative References 🦋

These ones are the extra-credit reading. Super useful for context, but you don't need them to follow the main spec 💅

Appendix A. Application Examples ✨

This informative annex is the fun part, where we look at real-life places this stuff actually gets used. Some details about application examples, served with a side of vibes 🌈

A.1. Rolling Stock 🚆

Rolling stock (aka railroad cars) is packed with sensors, actuators, and controllers. ✨ These talk to each other inside the railroad car, but they also swap info with other railroad cars on the same train, with track-side equipment, and maybe with backend systems. 🙈 Honestly, these devices are typically unaware of backend system connectivity, which is so relatable. Enrolling certificates may be done during maintenance cycles of the railroad car, but the prep can already happen during operation. 💅 This kind of asynchronous enrollment means generating certification requests, which get collected and later forwarded for processing whenever the railroad car gets connectivity with the backend PKI of the operator. Then the authorization of the certification request is done based on the operator's asset/inventory information in the backend. Iconic organization 👑

UNISIG has included a CMP profile for the enrollment of TLS client and server X.509 certificates of on-board and track-side components in the Subset-137, which specifies the ETRAM/ETCS online key management for train control systems [UNISIG-Subset-137]. 🚂💖

A.2. Building Automation 🏢

In building automation scenarios, a detached building (or the basement of a building) may be equipped with sensors, actuators, and controllers that are connected to each other in a local network, but with only limited or no connectivity to a central building management system. 🥺 This problem may occur during installation time, but also during operation. In that situation, a service technician collects the necessary data and transfers it between the local network and the central building management system, e.g., using a laptop or a mobile phone. 📱 This data may comprise parameters and settings required in the operational phase of the sensors/actuators, like a component certificate issued by the operator to authenticate against other components and services. Main character technician energy 🫡

The collected data may be provided by a domain registrar already existing in the local network. 🧚 In this case, connectivity to the backend PKI may be facilitated by the service technician's laptop. Alternatively, the data can also be collected from the pledges directly and provided to a domain registrar deployed in a different network in preparation for the operational phase. In this case, connectivity to the domain registrar may also be facilitated by the service technician's laptop. 💻🌸

A.3. Substation Automation ⚡

In electrical substation automation scenarios, a control center typically hosts PKI services to issue certificates for Intelligent Electronic Devices (IEDs) operated in a substation. ⚡💜 Communication between the substation and control center is performed through a proxy/gateway/DMZ, which terminates protocol flows. Note that [NERC-CIP-005-5] requires inspection of protocols at the boundary of a security perimeter (in this case, the substation). 🔥 In addition, security management in substation automation assumes central support of several enrollment protocols to support the various capabilities of IEDs from different vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies mandatory support of two enrollment protocols for the infrastructure side, SCEP [RFC8894] and EST [RFC7030], while an IED may support only one of them. 😭 Two protocols on the server side, one on the device side, very efficient, very relatable 🫶

A.4. Electric Vehicle Charging Infrastructure

okay so EV charging is a whole vibe 🔌⚡ there are protocols for the chat between the car and the charging point (like ISO 15118-2 [ISO-IEC-15118-2]) and also between the charging point and the charging point operator (like OCPP [OCPP]) 🦋. depending on the authentication model, it's either unilateral or mutual authentication, and it's giving security check either way 🔐. in both cases the charging point uses an X.509 certificate to prove who it is inside its TLS channels between the car and the charger 💜. how that certificate gets managed depends on a bunch of things, including which backend connectivity protocol you picked 🤔.

now here's the tea 🫖. with OCPP, that protocol is supposed to be the ONLY communication protocol between the charging point and the backend, carrying literally everything: charging control, maintenance, the works 💅. so certificate management has to happen in-band of OCPP, which means you need to be able to wrap the certificate management messages in a transport-independent way 🧚. authenticated self-containment helps with this bc it lets the transport run without a separate enrollment protocol, and the messages get bound to the identity of the endpoints that are talking to each other 🫶. no extra protocol, no drama, slay 👑✨.

A.5. Infrastructure Isolation Policy

ok this one is about any situation where the network infrastructure is normally cut off from the Internet as a matter of policy, usually for security reasons 🔒🌸. in that case, limited access to external PKI services is allowed, but only in carefully controlled short windows (for example, when a batch of new devices is getting deployed) and it's forbidden or blocked at all other times 🙈.

A.6. Sites with Insufficient Levels of Operational Security

bestie, the RA doing (at least part of) the authorization of a certification request is a critical PKI component 🚨. so it needs higher operational security than the components that just use the certificates they were issued for their security features 💖. CAs can also demand stronger security in the registration procedures from RAs, and domain registrars with co-located RAs might not be able to meet that 😭. the CA/Browser Forum is currently raising the security requirements for issuing publicly trusted certificates, meaning certs placed in browser trust stores, which might be used to connect with devices in the domain 🌈. so if the on-site components of the target domain can't be operated securely enough for what an RA needs, this service SHOULD be moved to an off-site backend component with a sufficient level of security 🏃‍♀️💨.

wait, quick note: the SHOULD in that last sentence is the only key word here and it's the real requirement, so that's the part to keep in mind 🫶.

Acknowledgments

we thank Eliot Lear for his contributions as a co-author at an earlier draft stage 🎀.

we thank Brian E. Carpenter, Michael Richardson, and Giorgio Romanenghi for their input and discussion on use cases and call flows 💬.

and we also thank Toerless Eckert (document shepherd), Barry Leiba (SECdir review), Mahesh Jethanandani (IETF area director), Meral Shirazipour (Gen-ART reviewer), Reshad Rahman (YANGDOCTORS reviewer), Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Danyliw, and Éric Vyncke (IESG reviewers), Michael Richardson (ANIMA design team member), and Rajeev Ranjan, Rufus Buschart, Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) for their reviews with suggestions for improvements 🙌💜.

Contributors

Eliot Lear Cisco Systems Richtistrasse 7 CH-8304 Wallisellen Switzerland Phone: +41 44 878 9200 Email: lear@cisco.com

Authors' Addresses

David von Oheimb (editor) Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany Email: david.von.oheimb@siemens.com URI: https://www.siemens.com/

Steffen Fries Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany Email: steffen.fries@siemens.com URI: https://www.siemens.com/

Hendrik Brockhaus Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany Email: hendrik.brockhaus@siemens.com URI: https://www.siemens.com/

that's the whole RFC, bestie 🌈✨ you did it 😭💖

📦 where this page comes from