<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-anima-brski-ae-13" number="9733" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" updates="" obsoletes="" xml:lang="en">
<front>
<title abbrev="BRSKI-AE">BRSKI with Alternative Enrollment (BRSKI-AE) Protocol</title> (BRSKI-AE)</title>
<seriesInfo name="RFC" value="9733"/>
<author initials="D." surname="von Oheimb" fullname="David von Oheimb" role="editor">
<organization abbrev="Siemens">Siemens AG</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<code>81739</code>
<country>Germany</country>
</postal>
<email>david.von.oheimb@siemens.com</email>
<uri>https://www.siemens.com/</uri>
</address>
</author>
<author initials="S." surname="Fries" fullname="Steffen Fries">
<organization abbrev="Siemens">Siemens AG</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<code>81739</code>
<country>Germany</country>
</postal>
<email>steffen.fries@siemens.com</email>
<uri>https://www.siemens.com/</uri>
</address>
</author>
<author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
<organization abbrev="Siemens">Siemens AG</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<code>81739</code>
<country>Germany</country>
</postal>
<email>hendrik.brockhaus@siemens.com</email>
<uri>https://www.siemens.com/</uri>
</address>
</author>
<date year="2025" month="February"/>
<area>OPS</area>
<workgroup>anima</workgroup>
<keyword>BRSKI</keyword>
<keyword>IoT</keyword>
<keyword>zero-touch onboarding</keyword>
<keyword>alternative enrollment protocols</keyword>
<keyword>CMP</keyword>
<keyword>self-contained signed objects</keyword>
<keyword>end-to-end proof of origin</keyword>
<keyword>auditable source authentication</keyword>
<abstract>
<t>This document defines enhancements to the Bootstrapping Remote Secure
Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative
Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate
enrollment mechanisms instead of the originally specified use of
Enrollment over Secure Transport (EST). It supports certificate
enrollment protocols such as the Certificate Management Protocol (CMP)
that use authenticated self-contained signed objects for certification
messages, allowing for flexibility in network device onboarding
scenarios. The enhancements address use cases where the existing
enrollment mechanism may not be feasible or optimal, providing a
framework for integrating suitable alternative enrollment protocols.
This document also updates the BRSKI reference architecture to
accommodate these alternative methods, ensuring secure and scalable
deployment across a range of network environments.</t>
</abstract>
</front>
<middle>
<section anchor="introduction">
<name>Introduction</name>
<t>Bootstrapping Remote Secure Key Infrastructure (BRSKI) <xref target="RFC8995"/> is typically used with Enrollment over Secure
Transport (EST) <xref target="RFC7030"/> as the enrollment protocol for
operator-specific device certificates, employing HTTP over TLS for
secure message transfer. BRSKI-AE is a variant using alternative
enrollment protocols with authenticated self-contained objects for the
device certificate enrollment.
</t>
<t>This approach offers several distinct advantages. It allows for the
authentication of the origin of requests and responses independently of
message transfer mechanisms. This capability facilitates end-to-end
authentication (i.e., end-to-end proof of origin) across multiple
transport hops and supports the asynchronous operation of certificate
enrollment. Consequently, this provides architectural flexibility in
determining the location and timing for the ultimate authentication and
authorization of certification requests while ensuring that the
integrity and authenticity of the enrollment messages are maintained with
full cryptographic strength.</t>
<t>This specification carries over the main characteristics of BRSKI,
namely:</t>
<ul spacing="normal">
<li>
<t>The pledge is assumed to have received its Initial Device
IDentifier (IDevID) <xref target="IEEE_802.1AR-2018"/> credentials
during its manufacturing. It uses them to authenticate itself to
the Manufacturer Authorized Signing Authority (MASA) <xref
target="RFC8995"/>, to the registrar (which is the access point
of the target domain), and to possibly further components of the
domain where it will be operated.</t>
</li>
<li>
<t>The pledge first obtains via the voucher <xref target="RFC8366"/> exchange a trust anchor for authenticating entities in the
domain such as the domain registrar.</t>
</li>
<li>
<t>The pledge then obtains its Locally Significant Device IDentifier
(LDevID) <xref target="IEEE_802.1AR-2018"/>. To this end, the
pledge generates a private key, called an "LDevID secret". Then, it
requests via the domain registrar from the PKI of its new domain a
domain-specific device certificate, called an "LDevID certificate".
On success, it receives the LDevID certificate along with its
certificate chain.</t>
</li>
</ul>
<t>The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID
certificate enrollment through the use of an alternative protocol to EST
that:</t>
<ul spacing="normal">
<li>
<t>supports end-to-end authentication over multiple transport hops and</t>
</li>
<li>
<t>facilitates secure message exchanges over any type of transfer
mechanism, including asynchronous delivery.</t>
</li>
</ul>
<t>It may be observed that the BRSKI voucher exchange between the
pledge, registrar, and MASA involves the use of authenticated
self-contained objects, which inherently possess these properties.</t>
<t>The existing well-known URI structure used for BRSKI and EST messages
is extended by introducing an additional path element that specifies the
enrollment protocol being employed.</t>
<t>This specification allows the registrar to offer multiple enrollment
protocols, enabling pledges and their developers to select the most
appropriate one based on the defined overall approach and specific
endpoints.</t>
<t>It may be important to note that <xref target="RFC8995"/>
specifies the use of HTTP over TLS, but variations such as Constrained
BRSKI <xref target="I-D.ietf-anima-constrained-voucher"/>, which uses
the Constrained Application Protocol (CoAP) over DTLS, are possible as well. In this context, "HTTP" and "TLS"
are used as references to the most common implementation, though
variants using CoAP and/or DTLS are implied where applicable, as the
distinctions are not pertinent here.</t>
<t>This specification, together with its referenced documents, is
sufficient to support BRSKI with the Certificate Management Protocol
(CMP) <xref target="RFC9480"/> as profiled in the Lightweight CMP
Profile (LCMPP) <xref target="RFC9483"/>. Integrating BRSKI with an
enrollment protocol or profile other than the LCMPP will necessitate
additional IANA registrations, as detailed in this document.
Furthermore, additional specifications may be required for the details
of the protocol or profile, which fall outside the scope of this
document.</t>
<section anchor="sup-env">
<name>Supported Scenarios</name>
<t>BRSKI-AE is designed for use in scenarios such as the following:</t>
<ul spacing="normal">
<li>
<t>When pledges and/or the target domain leverage an existing
certificate enrollment protocol other than EST, such as CMP.</t>
</li>
<li>
<t>When the application context precludes the use of EST for
certificate enrollment due to factors such as when:</t>
<ul spacing="normal">
<li>
<t>The Registration Authority (RA) is not co-located with the
registrar and requires end-to-end authentication of
requesters, which EST does not support over multiple transport
hops.</t>
</li>
<li>
<t>The RA or Certification Authority (CA) operator mandates
auditable proof of origin for Certificate Signing Requests
(CSRs), which cannot be provided by TLS as it only offers
transient source authentication.</t>
</li>
<li>
<t>Certificates are requested for key types, such as Key
Encapsulation Mechanism (KEM) keys, that do not support
signing or other single-shot proof-of-possession methods as
those described in <xref target="RFC6955"/>. EST, which
relies on CSRs in PKCS #10 format <xref target="RFC2986"/>,
does not accommodate these key types because it necessitates
proof-of-possession methods that operate within a single
message, whereas proof of possession for KEM keys requires
prior receipt of a fresh challenge value.</t>
</li>
<li>
<t>The pledge implementation employs security libraries that
do not support EST or uses a TLS library lacking support for
the "tls-unique" value <xref target="RFC5929"/>, which EST
requires for the strong binding of source authentication.</t>
</li>
</ul>
</li>
<li>
<t>When full RA functionality is not available on-site within the
target domain, and connectivity to an off-site RA may be
intermittent or entirely offline.
</t>
</li>
<li>
<t>When authoritative actions by a local RA at the registrar are
insufficient for fully and reliably authorizing pledge
certification requests, potentially due to a lack of access to
necessary data or inadequate security measures, such as the local
storage of private keys.
</t>
</li>
</ul>
<t>Bootstrapping may be managed in various ways depending on the
application domain. <xref target="app-examples"/> provides
illustrative examples from different industrial control system
environments and operational contexts that motivate the support of
alternative enrollment protocols.</t>
</section>
</section>
<section anchor="terminology-and-abbreviations">
<name>Terminology and Abbreviations</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>This document relies on the terminology defined in <xref
target="RFC8995"/>, <xref target="RFC5280"/>, and <xref
target="IEEE_802.1AR-2018"/>, which is partly repeated here. Several
further terms are also described here.</t>
<t>To be independent of the terminology of a specific enrollment
protocol, this document utilizes generic terminology regarding PKI
management operations.</t>
<t>The following terminology is used in this document:</t>
<dl newline="false" spacing="normal">
<dt>asynchronous:</dt>
<dd>the time-wise interrupted delivery of messages, here, between a
pledge and some backend system (e.g., an RA).</dd>
<dt>attribute request:</dt>
<dd>a message requesting content to be included in the certification request.</dd>
<dt>attribute response:</dt>
<dd>a message providing the answer to the attribute request.</dd>
<dt>authenticated self-contained object:</dt>
<dd>a data structure that is cryptographically bound to the identity
of its originator by an attached digital signature on the actual
object, using a private key of the originator such as the IDevID
secret.</dd>
<dt>backend:</dt>
<dd>the placement of a domain component separately from the domain
registrar; it may be on-site or off-site.</dd>
<dt>CA certs request:</dt>
<dd>a message requesting CA certificates.</dd>
<dt>CA certs response:</dt>
<dd>a message providing the answer to a CA certs request.</dd>
<dt>certificate confirm:</dt>
<dd>a message stating to the backend PKI that the requester of a
certificate received the new certificate and accepted it.</dd>
<dt>certification request:</dt>
<dd>a message requesting a certificate with proof of identity.</dd>
<dt>certification response:</dt>
<dd>a message providing the answer to a certification request.</dd>
<dt>local RA:</dt>
<dd>the same as LRA.</dd>
<dt>off-site:</dt>
<dd>the locality of a component, service, or functionality (such as RA
or CA) that is not at the site of the registrar. This may be a
central site or a cloud service, to which connection may be
intermittent.</dd>
<dt>on-site:</dt>
<dd>the locality of a component, service, or functionality at the site of
the registrar.</dd>
<dt>PKI/registrar confirm:</dt>
<dd>an acknowledgment of the PKI on the certificate confirm.</dd>
<dt>pledge:</dt>
<dd>a device that is to be bootstrapped into a target domain. It
requests an LDevID using IDevID credentials installed by its
manufacturer.</dd>
<dt>registrar:</dt>
<dd>short for domain registrar.</dd>
<dt>site:</dt>
<dd>the locality where an entity such as a pledge, registrar, or PKI
component is deployed. The target domain may have multiple sites.</dd>
<dt>synchronous:</dt>
<dd>the time-wise uninterrupted delivery of messages, here, between a
pledge and a registrar or backend system (e.g., the MASA).</dd>
<dt>target domain:</dt>
<dd>the domain that a pledge is going to be bootstrapped into.</dd>
</dl>
<t>The following abbreviations are used in this document:</t>
<dl newline="false" spacing="normal">
<dt>BRSKI:</dt>
<dd>Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995"/></dd>
<dt>BRSKI-AE:</dt>
<dd>BRSKI with Alternative Enrollment. Refers to a
variation of BRSKI <xref target="RFC8995"/> in which BRSKI-EST, the
enrollment protocol between the pledge and the registrar, is replaced
by enrollment protocols that support end-to-end authentication of the
pledge to the RA, such as CMP.</dd>
<dt>CA:</dt>
<dd>Certification Authority</dd>
<dt>CMC:</dt>
<dd>Certificate Management over CMS</dd>
<dt>CMP:</dt>
<dd>Certificate Management Protocol <xref target="RFC4210"/> <xref target="RFC9480"/></dd>
<dt>CMS:</dt>
<dd>Cryptographic Message Syntax</dd>
<dt>CRMF:</dt>
<dd>Certificate Request Message Format</dd>
<dt>CSR:</dt>
<dd>Certificate Signing Request</dd>
<dt>EST:</dt>
<dd>Enrollment over Secure Transport <xref target="RFC7030"/></dd>
<dt>IDevID:</dt>
<dd>Initial Device IDentifier (of a pledge, provided by
the manufacturer and comprising of a private key and the related X.509
certificate with its chain).</dd>
<dt>LCMPP:</dt>
<dd>Lightweight CMP Profile <xref target="RFC9483"/></dd>
<dt>LDevID:</dt>
<dd>Locally Significant Device IDentifier (of a pledge, provided by
its target domain and comprising of a private key and the related X.509
certificate with its chain).</dd>
<dt>LRA:</dt>
<dd>Local Registration Authority. A subordinate RA that is close to
entities being enrolled and separate from a subsequent RA. In
BRSKI-AE, it is needed if a backend RA is used; in this case, the LRA
is co-located with the registrar.</dd>
<dt>MASA:</dt>
<dd>Manufacturer Authorized Signing Authority. Provides vouchers.</dd>
<dt>RA:</dt>
<dd>Registration Authority. The PKI component to which a CA typically
delegates certificate management functions such as authenticating
pledges and performing authorization checks on certification
requests.</dd>
<dt>SCEP:</dt>
<dd>Simple Certificate Enrolment Protocol</dd>
</dl>
</section>
<section anchor="req-sol">
<name>Basic Requirements and Mapping to Solutions</name>
<t>Based on the intended target scenarios described in <xref
target="sup-env"/> and the application examples described in <xref
target="app-examples"/>, the following requirements are derived to
support authenticated self-contained objects as containers carrying
certification requests.</t>
<t>The following properties are required for a certification request:</t>
<ul spacing="normal">
<li>
<t>Proof of possession: demonstrates access to the private key
corresponding to the public key contained in a certification
request. This is typically achieved by a self-signature using the
corresponding private key but can also be achieved indirectly; see
<xref section="4.3" sectionFormat="comma" target="RFC4210"/>.</t>
</li>
<li>
<t>Proof of identity (also called "proof of origin"): provides data
origin authentication of the certification request. Typically, this
is achieved by a signature using the pledge IDevID secret over some
data, which needs to include a sufficiently strong identifier of the
pledge, such as the device serial number typically included in the
subject of the IDevID certificate.</t>
</li>
</ul>
<t>The remainder of this section gives a non-exhaustive list of solution
examples, based on existing technology described in IETF documents.</t>
<section anchor="solutions-PoP">
<name>Solution Options for Proof of Possession</name>
<t>Certificate Signing Request (CSR) objects are data structures
protecting only the integrity of the contained data and providing
proof of possession for a (locally generated) private key. Important
types of CSR data structures are:</t>
<ul spacing="normal">
<li>PKCS #10 <xref target="RFC2986"/>: This very common form of
CSR is self-signed to protect its integrity and to prove
possession of the private key that corresponds to the public key
included in the request.</li>
<li>Certificate Request Message Format (CRMF) <xref
target="RFC4211"/>: This less common but more general CSR format
supports several ways of integrity protection and proof of
possession. Typically a self-signature is used, which is
generated over (part of) the structure with the private key
corresponding to the included public key. CRMF also supports
further proof-of-possession methods for types of keys that do not
have signing capability. For details, see <xref section="4"
sectionFormat="comma" target="RFC4211"/>.</li>
</ul>
<t>It should be noted that the integrity protection of CSRs includes
the public key because it is part of the data signed by the
corresponding private key. Yet, this signature does not provide data
origin authentication, (i.e., proof of identity of the requester)
because the key pair involved is new and therefore does not yet have a
confirmed identity associated with it.
</t>
</section>
<section anchor="solutions-PoI">
<name>Solution Options for Proof of Identity</name>
<t>Binding a Certificate Signing Request (CSR) to an existing
authenticated credential (which in the BRSKI context is the IDevID certificate)
enables proof of origin, which in turn supports an authorization
decision on the CSR.</t>
<t>The binding of data origin authentication to the CSR is typically
delegated to the protocol used for certificate management. This
binding may be achieved through security options in an underlying
transport protocol such as TLS if 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.</t>
<t>This requirement is addressed by existing enrollment protocols in
various ways, such as:</t>
<ul spacing="normal">
<li>
<t>EST <xref target="RFC7030"/> and its variant EST-coaps <xref
target="RFC9148"/> utilize PKCS #10 to encode CSRs. While such
a CSR has not been designed to include proof of origin, there is a
limited, indirect way of binding it to the source authentication
of the underlying TLS session. This is achieved by including in
the CSR the "tls-unique" value <xref target="RFC5929"/> resulting
from the TLS handshake. As this is optionally supported by the
EST <tt>"/simpleenroll"</tt> endpoint used in BRSKI, and the TLS
handshake employed in BRSKI includes certificate-based client
authentication of the pledge with its IDevID credentials, the
proof of pledge identity being an authenticated TLS client can be
bound to the CSR.</t>
<t>Yet, this binding is only valid in the context of the TLS
session established with the registrar acting as the EST server
and typically also as an RA. So even such a cryptographic binding
of the authenticated pledge identity to the CSR is not visible nor
verifiable to authorization points outside the registrar, such as
a (second) RA in the backend. What the registrar needs to do is
authenticate and pre-authorize the pledge and indicate this to the
(second) RA. This is done by signing the forwarded certification
request with its private key and a related certificate that has
the id-kp-cmcRA extended key usage attribute.</t>
<t><xref section="2.5" sectionFormat="comma" target="RFC7030"/>
sketches wrapping CSRs formatted per PKCS #10 with a Full PKI Request
message sent to the <tt>"/fullcmc"</tt> endpoint. This would
allow for source authentication at the message level, such that
the registrar could forward it to external RAs in a meaningful
way. This approach is so far not sufficiently described and
likely has not been implemented.</t>
</li>
<li>
<t>The Simple Certificate Enrolment Protocol (SCEP) <xref
target="RFC8894"/> supports using a shared secret (passphrase) or
an existing certificate to protect CSRs based on SCEP Secure
Message Objects using Cryptographic Message Syntax (CMS) wrapping <xref target="RFC5652"/>. Note
that the wrapping using an existing IDevID in SCEP is referred to
as "renewal". This way, SCEP does not rely on the security of the
underlying message transfer.</t>
</li>
<li>
<t>CMP <xref target="RFC4210"/> <xref target="RFC9480"/> supports
using a shared secret (passphrase) or an existing certificate,
which may be an IDevID credential, to authenticate certification
requests via the PKIProtection structure in a PKIMessage. The
certification request is typically encoded utilizing CRMF, while
PKCS #10 is supported as an alternative. Thus, CMP does not rely
on the security of the underlying message transfer.</t>
</li>
<li>
<t>Certificate Management over CMS (CMC) <xref target="RFC5272"/>
also supports utilizing a shared secret (passphrase) or an
existing certificate to protect certification requests, which can
be either in a CRMF or PKCS #10 structure. The proof of identity
can be provided as part of a Full CMC Request based on CMS <xref
target="RFC5652"/> and signed with an existing IDevID secret.
Thus, CMC does not rely on the security of the underlying message
transfer.</t>
</li>
</ul>
<t>To sum up, EST does not meet the requirements for authenticated
self-contained objects, but SCEP, CMP, and CMC do. This document
primarily focuses on CMP as it has more industry adoption than CMC and
SCEP has issues not detailed here.</t>
</section>
</section>
<section anchor="uc1">
<name>Adaptations to BRSKI</name>
<t>To enable using alternative certificate enrollment protocols
supporting end-to-end authentication, asynchronous enrollment, and more
general system architectures, BRSKI-AE provides some generalizations on
BRSKI <xref target="RFC8995"/>. This way, authenticated self-contained
objects such as those described in <xref target="req-sol"/> above can be
used for certificate enrollment, and RA functionality can be deployed
freely in the target domain. Parts of the RA functionality can even be
distributed over several nodes.</t>
<t>The enhancements are kept to a minimum to ensure the reuse of already
defined architecture elements and interactions. In general, the
communication follows the BRSKI model and utilizes the existing BRSKI
architecture elements. In particular, the pledge initiates
communication with the domain registrar and interacts with the MASA as
usual for voucher request and response processing.</t>
<section anchor="architecture">
<name>Architecture</name>
<t>The key element of BRSKI-AE is that the authorization of a
certification request <bcp14>MUST</bcp14> 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. Consequently, the certification request
<bcp14>MAY</bcp14> 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 <xref target="sup-env"/>, these
components may be offline or off-site. The registrar and other
on-site domain components may have no or only temporary (intermittent)
connectivity to them.</t>
<t>This leads to generalizations in the placement and enhancements of
the logical elements as shown in <xref target="uc1figure"/>.</t>
<figure anchor="uc1figure">
<name>Architecture Overview Using Backend PKI Components</name>
<artset>
<artwork type="svg" align="left"><svg align="left">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="576" height="544" width="544" viewBox="0 0 544 576" 544" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,208 8,192 L 8,336" 8,320" fill="none" stroke="black"/>
<path d="M 32,48 32,32 L 32,200" 32,184" fill="none" stroke="black"/>
<path d="M 32,480 32,448 L 32,528" 32,496" fill="none" stroke="black"/>
<path d="M 80,208 80,192 L 80,336" 80,320" fill="none" stroke="black"/>
<path d="M 112,480 112,448 L 112,528" 112,496" fill="none" stroke="black"/>
<path d="M 152,240 152,224 L 152,304" 152,288" fill="none" stroke="black"/>
<path d="M 160,480 160,448 L 160,528" 160,496" fill="none" stroke="black"/>
<path d="M 216,240 216,224 L 216,304" 216,288" fill="none" stroke="black"/>
<path d="M 304,240 304,224 L 304,304" 304,288" fill="none" stroke="black"/>
<path d="M 336,32 336,16 L 336,144" 336,128" fill="none" stroke="black"/>
<path d="M 376,312 376,296 L 376,472" 376,440" fill="none" stroke="black"/>
<path d="M 424,240 424,224 L 424,304" 424,288" fill="none" stroke="black"/>
<path d="M 456,72 456,56 L 456,144" 456,128" fill="none" stroke="black"/>
<path d="M 472,152 472,136 L 472,256" 472,240" fill="none" stroke="black"/>
<path d="M 480,480 504,448 L 480,528" 504,496" fill="none" stroke="black"/>
<path d="M 536,32 536,16 L 536,144" 536,128" fill="none" stroke="black"/>
<path d="M 336,32 336,16 L 536,32" 536,16" fill="none" stroke="black"/>
<path d="M 32,48 32,32 L 144,48" 144,32" fill="none" stroke="black"/>
<path d="M 224,48 224,32 L 328,48" 328,32" fill="none" stroke="black"/>
<path d="M 336,64 336,48 L 536,64" 536,48" fill="none" stroke="black"/>
<path d="M 336,144 336,128 L 536,144" 536,128" fill="none" stroke="black"/>
<path d="M 8,208 8,192 L 80,208" 80,192" fill="none" stroke="black"/>
<path d="M 152,240 152,224 L 216,240" 216,224" fill="none" stroke="black"/>
<path d="M 304,240 304,224 L 424,240" 424,224" fill="none" stroke="black"/>
<path d="M 432,256 432,240 L 472,256" 472,240" fill="none" stroke="black"/>
<path d="M 88,272 88,256 L 144,272" 144,256" fill="none" stroke="black"/>
<path d="M 224,272 224,256 L 296,272" 296,256" fill="none" stroke="black"/>
<path d="M 152,304 152,288 L 216,304" 216,288" fill="none" stroke="black"/>
<path d="M 304,304 304,288 L 424,304" 424,288" fill="none" stroke="black"/>
<path d="M 8,336 8,320 L 80,336" 80,320" fill="none" stroke="black"/>
<path d="M 32,480 32,448 L 112,480" 112,448" fill="none" stroke="black"/>
<path d="M 160,480 160,448 L 480,480" 504,448" fill="none" stroke="black"/>
<path d="M 120,496 120,464 L 160,496" 160,464" fill="none" stroke="black"/>
<path d="M 112,512 112,480 L 152,512" 152,480" fill="none" stroke="black"/>
<path d="M 32,528 32,496 L 112,528" 112,496" fill="none" stroke="black"/>
<path d="M 160,528 160,496 L 480,528" 504,496" fill="none" stroke="black"/>
<polygon class="arrowhead" points="480,152 468,146.4 468,157.6" points="480,136 468,130.4 468,141.6" fill="black" transform="rotate(270,472,152)"/> transform="rotate(270,472,136)"/>
<polygon class="arrowhead" points="440,256 428,250.4 428,261.6" points="440,240 428,234.4 428,245.6" fill="black" transform="rotate(180,432,256)"/> transform="rotate(180,432,240)"/>
<polygon class="arrowhead" points="384,472 372,466.4 372,477.6" points="384,440 372,434.4 372,445.6" fill="black" transform="rotate(90,376,472)"/> transform="rotate(90,376,440)"/>
<polygon class="arrowhead" points="384,312 372,306.4 372,317.6" points="384,296 372,290.4 372,301.6" fill="black" transform="rotate(270,376,312)"/> transform="rotate(270,376,296)"/>
<polygon class="arrowhead" points="304,272 292,266.4 292,277.6" points="304,256 292,250.4 292,261.6" fill="black" transform="rotate(0,296,272)"/> transform="rotate(0,296,256)"/>
<polygon class="arrowhead" points="232,272 220,266.4 220,277.6" points="232,256 220,250.4 220,261.6" fill="black" transform="rotate(180,224,272)"/> transform="rotate(180,224,256)"/>
<polygon class="arrowhead" points="160,512 148,506.4 148,517.6" points="160,480 148,474.4 148,485.6" fill="black" transform="rotate(0,152,512)"/> transform="rotate(0,152,480)"/>
<polygon class="arrowhead" points="152,272 140,266.4 140,277.6" points="152,256 140,250.4 140,261.6" fill="black" transform="rotate(0,144,272)"/> transform="rotate(0,144,256)"/>
<polygon class="arrowhead" points="128,496 116,490.4 116,501.6" points="128,464 116,458.4 116,469.6" fill="black" transform="rotate(180,120,496)"/> transform="rotate(180,120,464)"/>
<polygon class="arrowhead" points="96,272 84,266.4 84,277.6" points="96,256 84,250.4 84,261.6" fill="black" transform="rotate(180,88,272)"/> transform="rotate(180,88,256)"/>
<polygon class="arrowhead" points="40,200 28,194.4 28,205.6" points="40,184 28,178.4 28,189.6" fill="black" transform="rotate(90,32,200)"/> transform="rotate(90,32,184)"/>
<g class="text">
<text x="184" y="52">Drop-Ship</text>
<text x="372" y="52">Vendor</text>
<text x="432" y="52">Service</text>
<text x="352" y="84">M</text> y="36">Drop-Ship</text>
<text x="408" y="84">anufacturer</text>
<text x="352" y="100">A</text> x="404" y="36">Vendor Service</text>
<text x="400" y="100">uthorized</text> y="68">M anufacturer</text>
<text x="496" y="100">Ownership</text> x="392" y="84">A uthorized</text>
<text x="352" y="116">S</text> x="496" y="84">Ownership</text>
<text x="388" y="116">igning</text> x="380" y="100">S igning</text>
<text x="488" y="116">Tracker</text> y="100">Tracker</text>
<text x="352" y="132">A</text> x="388" y="116">A uthority</text>
<text x="396" y="132">uthority</text> x="288" y="196">.........................................</text>
<text x="508" y="196">BRSKI-</text> x="128" y="212">.</text>
<text x="288" y="212">.........................................</text> x="448" y="212">.</text>
<text x="500" y="212">MASA</text> x="508" y="212">BRSKI-</text>
<text x="128" y="228">.</text>
<text x="448" y="228">.</text>
<text x="128" y="244">.</text>
<text x="448" y="244">.</text> x="500" y="228">MASA</text>
<text x="44" y="260">Pledge</text> y="244">Pledge</text>
<text x="128" y="260">.</text> y="244">.</text>
<text x="180" y="260">Join</text> y="244">Join</text>
<text x="340" y="260">Domain</text> y="244">Domain</text>
<text x="184" y="276">Proxy</text> y="260">Proxy</text>
<text x="352" y="276">Registrar</text> x="364" y="260">Registrar w/</text>
<text x="448" y="276">.</text> y="260">.</text>
<text x="128" y="292">.</text> y="276">.</text>
<text x="324" y="292">w/</text> x="184" y="276">.......</text>
<text x="352" y="292">LRA</text>
<text x="380" y="292">or</text>
<text x="404" y="292">RA</text> y="276">LRA or RA</text>
<text x="448" y="292">.</text> y="276">.</text>
<text x="44" y="308">IDevID</text> y="292">IDevID</text>
<text x="128" y="308">.</text> y="292">.</text>
<text x="448" y="308">.</text>
<text x="140" y="324">BRSKI-AE</text>
<text x="196" y="324">over</text> y="292">.</text>
<text x="232" y="324">TLS</text> x="176" y="308">BRSKI-AE over TLS</text>
<text x="448" y="324">.</text>
<text x="132" y="340">using,</text>
<text x="184" y="340">e.g.,</text> y="308">.</text>
<text x="232" y="340">LCMPP</text> x="180" y="324">using, e.g., LCMPP</text>
<text x="448" y="340">.</text> y="324">.</text>
<text x="128" y="356">.</text> y="340">.</text>
<text x="448" y="356">.</text> y="340">.</text>
<text x="248" y="372">...............................</text> y="356">...............................</text>
<text x="416" y="372">.........</text> y="356">.........</text>
<text x="128" y="388">on-site</text> x="232" y="372">on-site (local) domain components</text>
<text x="192" y="388">(local)</text> x="432" y="388">e.g., LCMPP</text>
<text x="252" y="388">domain</text> x="192" y="420">.............................................</text>
<text x="324" y="388">components</text> x="452" y="420">..................</text>
<text x="408" y="420">e.g.,</text> x="144" y="436">. Public-Key Infrastructure (PKI)</text>
<text x="456" y="420">LCMPP</text> x="520" y="436">.</text>
<text x="192" y="452">.............................................</text> x="16" y="452">.</text>
<text x="440" y="452">...............</text> x="520" y="452">.</text>
<text x="16" y="468">.</text>
<text x="68" y="468">Public-Key</text>
<text x="172" y="468">Infrastructure</text> x="276" y="468">Registration Authority</text>
<text x="496" x="520" y="468">.</text>
<text x="16" y="484">.</text>
<text x="496" x="76" y="484">CA</text>
<text x="332" y="484">RA (unless part of Domain Registrar)</text>
<text x="520" y="484">.</text>
<text x="16" y="500">.</text>
<text x="236" y="500">Registration</text>
<text x="328" y="500">Authority</text>
<text x="380" y="500">RA</text>
<text x="496" x="520" y="500">.</text>
<text x="16" y="516">.</text>
<text x="76" y="516">CA</text>
<text x="216" y="516">(unless</text>
<text x="268" y="516">part</text>
<text x="300" y="516">of</text>
<text x="340" y="516">Domain</text>
<text x="412" y="516">Registrar)</text>
<text x="496" y="516">.</text>
<text x="16" y="532">.</text>
<text x="496" y="532">.</text>
<text x="256" y="548">.............................................................</text>
<text x="104" y="564">backend</text>
<text x="172" y="564">(central</text> y="516">................................................................</text>
<text x="220" y="564">or</text>
<text x="272" y="564">off-site)</text>
<text x="340" y="564">domain</text>
<text x="412" y="564">components</text> x="264" y="532">backend (central or off-site) domain components</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art" align="left"><![CDATA[
+------------------------+
+--------------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
]]></artwork>
</artset>
</figure>
<t>The architecture overview in <xref target="uc1figure"/> has the
same logical elements as BRSKI but with a more flexible placement of
the authentication and authorization checks on certification requests.
Depending on the application scenario, the registrar
<bcp14>MAY</bcp14> still do all of these checks (as is the case in
BRSKI) or only do part of them.</t>
<t>The following list describes the on-site components in the target
domain of the pledge shown in <xref target="uc1figure"/>.</t>
<ul spacing="normal">
<li>
<t>Join Proxy: This has the same requirements as in <xref target="RFC8995"/> (see
<xref section="4" sectionFormat="comma" target="RFC8995"/>).</t>
</li>
<li>
<t>Domain Registrar (including LRA or RA functionality): In
BRSKI-AE, the domain registrar has mostly the same functionality
as in BRSKI, namely to act as the gatekeeper of the domain for
onboarding new devices and to facilitate the communication of
pledges with their MASA and the domain PKI. Yet, there are some
generalizations and specific requirements:</t>
<ol spacing="normal" type="1"><li>
<t>The registrar <bcp14>MUST</bcp14> 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
<xref target="addressing"/>).</t>
</li>
<li>
<t>Rather than having full RA functionality, the registrar
<bcp14>MAY</bcp14> 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 to this end, the backend RA may need information
regarding 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.</t>
<t>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.</t>
</li>
<li>
<t>The use of a certificate enrollment protocol with
authenticated self-contained objects gives freedom with how to
transfer enrollment messages 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 in the case that the RA is not part of the
registrar, even if the message exchange with backend systems
is unprotected and involves further transport hops. See <xref
target="sec-consider"/> for details on how this can be
achieved.</t>
</li>
</ol>
</li>
</ul>
<t>Despite the above generalizations of the enrollment phase, the final
step of BRSKI, namely the enrollment status telemetry, is kept as it
is.</t>
<t>The following list describes the components provided by the vendor
or manufacturer outside the target domain.</t>
<ul spacing="normal">
<li>
<t>MASA: This has the functionality as described in <xref target="RFC8995"/>. The voucher exchange with the MASA via the
domain registrar is performed as described in <xref target="RFC8995"/>.</t>
</li>
</ul>
<aside>
<t>Note: The definition of the interaction with the MASA in <xref
section="5" sectionFormat="of" target="RFC8995"/> implies that it
may be synchronous (using voucher requests with nonces) or
asynchronous (using nonceless voucher requests).</t>
</aside>
<ul spacing="normal">
<li>
<t>Ownership Tracker: This is as defined in <xref target="RFC8995"/>.</t>
</li>
</ul>
<t>The following list describes backend target domain components,
which may be located on-site or off-site in the target domain.</t>
<ul spacing="normal">
<li>
<t>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 directly connects to the CA.</t>
</li>
<li>
<t>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.</t>
</li>
</ul>
<t>Based on the diagram in <xref section="2.1" sectionFormat="comma"
target="RFC8995"/> and the architectural changes, the original
protocol flow is divided into several phases showing commonalities and
differences with the original approach as follows.</t>
<ul spacing="normal">
<li>
<t>Discover: This is mostly as in step (1) of <xref target="RFC8995"/>. For details, see
<xref target="discovery"/>.</t>
</li>
<li>
<t>Identify: This is the same as in step (2) of <xref target="RFC8995"/>.</t>
</li>
<li>
<t>Voucher exchange: This is the same as in steps (3) and (4) of <xref target="RFC8995"/>.</t>
</li>
<li>
<t>Voucher status telemetry: This is the same as directly after step (4) in <xref target="RFC8995"/>.</t>
</li>
<li>
<t>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.</t>
<t>It is <bcp14>REQUIRED</bcp14> 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. Due to this architecture, the pledge does not need to
establish additional connections for certificate enrollment and
the registrar retains full control over the certificate enrollment
traffic.</t>
</li>
<li>
<t>Enrollment status telemetry: This is the final exchange of step (5) of <xref target="RFC8995"/>.</t>
</li>
</ul>
</section>
<section anchor="message_ex">
<name>Message Exchange</name>
<t>The behavior of a pledge described in <xref section="2.1"
sectionFormat="comma" target="RFC8995"/> is kept, with one major
exception. After finishing the Imprint step (4), the Enroll step (5)
<bcp14>MUST</bcp14> be performed with an enrollment protocol utilizing
authenticated self-contained objects, as explained in <xref
target="req-sol"/>.
<xref target="exist_prot"/> discusses selected suitable enrollment
protocols and applicable options.</t>
<t>An abstract overview of the BRSKI-AE protocol can be found in the
graphics on slide 4 of <xref target="BRSKI-AE-overview"/>.</t>
<section anchor="discovery">
<name>Pledge - Registrar Discovery</name>
<t>Discovery as specified in <xref section="4" sectionFormat="comma"
target="RFC8995"/> does not support the discovery of registrars with
enhanced feature sets. A pledge cannot find out in this way whether
discovered registrars support the certificate enrollment protocol it
expects, such as CMP.</t>
<t>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 <xref
target="I-D.ietf-anima-brski-discovery"/>.</t>
<t>In the absence of such a generally applicable solution, BRSKI-AE
deployments may use their particular way of doing discovery. <xref
target="brski-cmp-instance"/> defines a minimalist approach that
<bcp14>MAY</bcp14> be used for CMP.</t>
</section>
<section anchor="pledge-registrar-masa-voucher-exchange">
<name>Pledge - Registrar - MASA Voucher Exchange</name>
<t>The voucher exchange is performed as specified in <xref
target="RFC8995"/>.</t>
</section>
<section anchor="pledge-registrar-masa-voucher-status-telemetry">
<name>Pledge - Registrar - MASA Voucher Status Telemetry</name>
<t>The voucher status telemetry is performed as specified in <xref
section="5.7" sectionFormat="comma" target="RFC8995"/>.</t>
</section>
<section anchor="pledge-registrar-raca-certificate-enrollment">
<name>Pledge - Registrar - RA/CA Certificate Enrollment</name>
<t>The specification in this section replaces the EST integration
for PKI bootstrapping described in <xref section="5.9"
sectionFormat="comma" target="RFC8995"/> (while <xref
section="5.9.4" sectionFormat="comma" target="RFC8995"/> remains as
the final phase; see below).</t>
<t>The certificate enrollment phase may involve the transmission of
several messages. Details can depend on the application scenario,
the employed enrollment protocol, and other factors.
</t>
<t>The only message exchange <bcp14>REQUIRED</bcp14> is for the
actual certification request and response. Further message
exchanges <bcp14>MAY</bcp14> be performed as needed.</t>
<aside>
<t>Note: The message exchanges marked <bcp14>OPTIONAL</bcp14> in
<xref target="enrollfigure"/> below cover all those supported by
the use of EST in BRSKI. The last <bcp14>OPTIONAL</bcp14> one,
namely certificate confirmation, is not supported by EST but by
CMP and other enrollment protocols.</t>
</aside>
<figure anchor="enrollfigure">
<name>Certificate Enrollment Message Flow</name>
<artset>
<artwork type="svg" align="left">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="576" width="560" viewBox="0 0 560 576" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,32 L 8,96" fill="none" stroke="black"/>
<path d="M 16,104 L 16,560" fill="none" stroke="black"/>
<path d="M 64,32 L 64,96" fill="none" stroke="black"/>
<path d="M 280,32 L 280,96" fill="none" stroke="black"/>
<path d="M 320,104 L 320,560" fill="none" stroke="black"/>
<path d="M 360,32 L 360,96" fill="none" stroke="black"/>
<path d="M 480,32 L 480,96" fill="none" stroke="black"/>
<path d="M 544,104 L 544,560" fill="none" stroke="black"/>
<path d="M 552,32 L 552,96" fill="none" stroke="black"/>
<path d="M 8,32 L 64,32" fill="none" stroke="black"/>
<path d="M 280,32 L 360,32" fill="none" stroke="black"/>
<path d="M 480,32 L 552,32" fill="none" stroke="black"/>
<path d="M 8,96 L 64,96" fill="none" stroke="black"/>
<path d="M 280,96 L 360,96" fill="none" stroke="black"/>
<path d="M 480,96 L 552,96" fill="none" stroke="black"/>
<path d="M 24,144 L 72,144" fill="none" stroke="black"/>
<path d="M 256,144 L 312,144" fill="none" stroke="black"/>
<path d="M 328,176 L 344,176" fill="none" stroke="black"/>
<path d="M 496,176 L 536,176" fill="none" stroke="black"/>
<path d="M 328,192 L 344,192" fill="none" stroke="black"/>
<path d="M 504,192 L 536,192" fill="none" stroke="black"/>
<path d="M 24,208 L 72,208" fill="none" stroke="black"/>
<path d="M 264,208 L 312,208" fill="none" stroke="black"/>
<path d="M 24,272 L 72,272" fill="none" stroke="black"/>
<path d="M 264,272 L 312,272" fill="none" stroke="black"/>
<path d="M 328,304 L 344,304" fill="none" stroke="black"/>
<path d="M 504,304 L 536,304" fill="none" stroke="black"/>
<path d="M 328,320 L 344,320" fill="none" stroke="black"/>
<path d="M 512,320 L 536,320" fill="none" stroke="black"/>
<path d="M 24,336 L 72,336" fill="none" stroke="black"/>
<path d="M 272,336 L 312,336" fill="none" stroke="black"/>
<path d="M 24,384 L 72,384" fill="none" stroke="black"/>
<path d="M 296,384 L 312,384" fill="none" stroke="black"/>
<path d="M 328,416 L 344,416" fill="none" stroke="black"/>
<path d="M 520,416 L 536,416" fill="none" stroke="black"/>
<path d="M 328,432 L 344,432" fill="none" stroke="black"/>
<path d="M 520,432 L 536,432" fill="none" stroke="black"/>
<path d="M 24,448 L 64,448" fill="none" stroke="black"/>
<path d="M 296,448 L 312,448" fill="none" stroke="black"/>
<path d="M 24,496 L 72,496" fill="none" stroke="black"/>
<path d="M 280,496 L 312,496" fill="none" stroke="black"/>
<path d="M 328,528 L 344,528" fill="none" stroke="black"/>
<path d="M 512,528 L 536,528" fill="none" stroke="black"/>
<path d="M 328,544 L 344,544" fill="none" stroke="black"/>
<path d="M 456,544 L 536,544" fill="none" stroke="black"/>
<path d="M 24,560 L 72,560" fill="none" stroke="black"/>
<path d="M 296,560 L 312,560" fill="none" stroke="black"/>
<polygon class="arrowhead" points="544,528 532,522.4 532,533.6" fill="black" transform="rotate(0,536,528)"/>
<polygon class="arrowhead" points="544,416 532,410.4 532,421.6" fill="black" transform="rotate(0,536,416)"/>
<polygon class="arrowhead" points="544,304 532,298.4 532,309.6" fill="black" transform="rotate(0,536,304)"/>
<polygon class="arrowhead" points="544,176 532,170.4 532,181.6" fill="black" transform="rotate(0,536,176)"/>
<polygon class="arrowhead" points="336,544 324,538.4 324,549.6" fill="black" transform="rotate(180,328,544)"/>
<polygon class="arrowhead" points="336,432 324,426.4 324,437.6" fill="black" transform="rotate(180,328,432)"/>
<polygon class="arrowhead" points="336,320 324,314.4 324,325.6" fill="black" transform="rotate(180,328,320)"/>
<polygon class="arrowhead" points="336,192 324,186.4 324,197.6" fill="black" transform="rotate(180,328,192)"/>
<polygon class="arrowhead" points="320,496 308,490.4 308,501.6" fill="black" transform="rotate(0,312,496)"/>
<polygon class="arrowhead" points="320,384 308,378.4 308,389.6" fill="black" transform="rotate(0,312,384)"/>
<polygon class="arrowhead" points="320,272 308,266.4 308,277.6" fill="black" transform="rotate(0,312,272)"/>
<polygon class="arrowhead" points="320,144 308,138.4 308,149.6" fill="black" transform="rotate(0,312,144)"/>
<polygon class="arrowhead" points="32,560 20,554.4 20,565.6" fill="black" transform="rotate(180,24,560)"/>
<polygon class="arrowhead" points="32,448 20,442.4 20,453.6" fill="black" transform="rotate(180,24,448)"/>
<polygon class="arrowhead" points="32,336 20,330.4 20,341.6" fill="black" transform="rotate(180,24,336)"/>
<polygon class="arrowhead" points="32,208 20,202.4 20,213.6" fill="black" transform="rotate(180,24,208)"/>
<g class="text">
<text x="36" y="52">Pledge</text>
<text x="308" y="52">Domain</text>
<text x="516" y="52">Operator</text>
<text x="320" y="68">Registrar</text>
<text x="504" y="68">RA/CA</text>
<text x="304" y="84">(JRC)</text>
<text x="504" y="84">(PKI)</text>
<text x="56" y="132">[OPTIONAL</text>
<text x="128" y="132">request</text>
<text x="172" y="132">of</text>
<text x="196" y="132">CA</text>
<text x="264" y="132">certificates]</text>
<text x="92" y="148">CA</text>
<text x="128" y="148">Certs</text>
<text x="184" y="148">Request</text>
<text x="232" y="148">(1)</text>
<text x="368" y="164">[OPTIONAL</text>
<text x="456" y="164">forwarding]</text>
<text x="364" y="180">CA</text>
<text x="400" y="180">Certs</text>
<text x="456" y="180">Request</text>
<text x="364" y="196">CA</text>
<text x="400" y="196">Certs</text>
<text x="460" y="196">Response</text>
<text x="92" y="212">CA</text>
<text x="128" y="212">Certs</text>
<text x="188" y="212">Response</text>
<text x="240" y="212">(2)</text>
<text x="56" y="244">[OPTIONAL</text>
<text x="128" y="244">request</text>
<text x="172" y="244">of</text>
<text x="228" y="244">attributes</text>
<text x="36" y="260">to</text>
<text x="80" y="260">include</text>
<text x="124" y="260">in</text>
<text x="192" y="260">Certification</text>
<text x="284" y="260">Request]</text>
<text x="120" y="276">Attribute</text>
<text x="192" y="276">Request</text>
<text x="240" y="276">(3)</text>
<text x="368" y="292">[OPTIONAL</text>
<text x="456" y="292">forwarding]</text>
<text x="392" y="308">Attribute</text>
<text x="464" y="308">Request</text>
<text x="392" y="324">Attribute</text>
<text x="468" y="324">Response</text>
<text x="120" y="340">Attribute</text>
<text x="196" y="340">Response</text>
<text x="248" y="340">(4)</text>
<text x="56" y="372">[REQUIRED</text>
<text x="152" y="372">certification</text>
<text x="244" y="372">request]</text>
<text x="136" y="388">Certification</text>
<text x="224" y="388">Request</text>
<text x="272" y="388">(5)</text>
<text x="368" y="404">[OPTIONAL</text>
<text x="456" y="404">forwarding]</text>
<text x="400" y="420">Certification</text>
<text x="488" y="420">Request</text>
<text x="400" y="436">Certification</text>
<text x="480" y="436">Resp.</text>
<text x="128" y="452">Certification</text>
<text x="220" y="452">Response</text>
<text x="272" y="452">(6)</text>
<text x="56" y="484">[OPTIONAL</text>
<text x="144" y="484">certificate</text>
<text x="248" y="484">confirmation]</text>
<text x="128" y="500">Certificate</text>
<text x="208" y="500">Confirm</text>
<text x="256" y="500">(7)</text>
<text x="368" y="516">[OPTIONAL</text>
<text x="456" y="516">forwarding]</text>
<text x="400" y="532">Certificate</text>
<text x="480" y="532">Confirm</text>
<text x="368" y="548">PKI</text>
<text x="416" y="548">Confirm</text>
<text x="136" y="564">PKI/Registrar</text>
<text x="224" y="564">Confirm</text>
<text x="272" y="564">(8)</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art" align="left"><![CDATA[
+------+ +---------+ +--------+
|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) ---| |
]]></artwork>
</artset>
</figure>
<t>It may be noted that connections between the registrar and the
PKI components of the operator (RA, CA, etc.) may be intermittent or
offline. Messages should be sent as soon as sufficient transfer
capacity is available.</t>
<t>The label '<tt>[OPTIONAL forwarding]</tt>' in <xref
target="enrollfigure"/> means that on receiving a request message of
the given type from a pledge, the registrar <bcp14>MAY</bcp14>
answer the request directly. In this case, it <bcp14>MUST</bcp14>
authenticate its responses with the same credentials as used for
authenticating itself at the TLS level for the voucher exchange.
Otherwise, the registrar <bcp14>MUST</bcp14> forward the request to
the RA and forward any resulting response back to the pledge.</t>
<t>The decision of whether to forward a request or to answer it
directly can depend on various static and dynamic factors. They
include the application scenario, the capabilities of the registrar,
the capabilities of the local RA possibly co-located with the
registrar, the enrollment protocol being used, and the specific
contents of the request.</t>
<t>Note that there are several options for how the registrar could be able to
directly answer requests for CA certificates or for certification request
attributes. It could cache responses obtained from the domain PKI and later
use their contents for responding to requests asking for the same data. The
contents could also be explicitly provisioned at the registrar.</t>
<t>Further note that certification requests typically need to be
handled by the backend PKI, but the registrar can answer them
directly with an error response in case it determines that such a
request should be rejected, for instance, because it is not properly
authenticated or authorized. Also, certificate confirmation
messages will usually be forwarded to the backend PKI, but if the
registrar knows that they are not needed or wanted there, it can
acknowledge such messages directly.</t>
<t>The following list provides an abstract description of the flow
depicted in <xref target="enrollfigure"/>.</t>
<ul spacing="normal">
<li>
<t>CA Certs Request (1): The pledge optionally requests the latest relevant
CA certificates. This ensures that the pledge has the
complete set of current CA certificates beyond the
pinned-domain-cert (which is contained in the voucher
and which may be just the domain registrar certificate).</t>
</li>
<li>
<t>CA Certs Response (2): This <bcp14>MUST</bcp14> contain any intermediate CA certificates
that the pledge may need to validate certificates
and <bcp14>MAY</bcp14> contain the LDevID trust anchor.</t>
</li>
<li>
<t>Attribute Request (3): Typically, the automated bootstrapping
occurs without local administrative configuration of the pledge.
Nevertheless, there are cases in which the pledge may also
include additional attributes
that are specific to the target domain in the Certification Request (5). To get these attributes
in advance, the attribute request may be used.</t>
</li>
<li>
<t>Attribute Response (4): This <bcp14>MUST</bcp14> contain the
attributes requested in (3) to be included in the subsequent
Certification Request (5).</t>
<t>For example, <xref section="6.11.7.2" sectionFormat="comma"
target="RFC8994"/> specifies how the attribute request is used
to signal to the pledge the 'acp-node-name' '<tt>acp-node-name</tt>' field required for
enrollment into an Autonomic Control Plane (ACP) domain.</t>
</li>
<li>
<t>Certification Request (5): This <bcp14>MUST</bcp14> contain
the authenticated self-contained object ensuring both the proof
of possession of the corresponding private key and the proof of
identity of the requester.</t>
</li>
<li>
<t>Certification Response (6): On success, this <bcp14>MUST</bcp14> contain
the requested certificate and <bcp14>MAY</bcp14>
include further information, like certificates of intermediate
CAs and any additional trust anchors.</t>
</li>
<li>
<t>Certificate Confirm (7): This is an optional confirmation that is sent after
the requested certificate has been received and validated. If
sent, it <bcp14>MUST</bcp14> contain a positive or negative
confirmation by the pledge to the PKI whether the certificate
was successfully enrolled and fits its needs.</t>
</li>
<li>
<t>PKI/Registrar Confirm (8): This is an acknowledgment by the PKI that
<bcp14>MUST</bcp14> be sent on reception of the Certificate
Confirm.</t>
</li>
</ul>
<t>The generic messages described above may be implemented using any
certificate enrollment protocol that supports authenticated
self-contained objects for the certification request as described in
<xref target="req-sol"/>. Examples are available in <xref
target="exist_prot"/>.</t>
<aside>
<t>Note that the optional certificate confirmation by the pledge
to the PKI described above is independent of the mandatory
enrollment status telemetry done between the pledge and the
registrar in the final phase of BRSKI-AE, which is described
next.</t>
</aside>
</section>
<section anchor="pledge-registrar-enrollment-status-telemetry">
<name>Pledge - Registrar Enrollment Status Telemetry</name>
<t>The enrollment status telemetry is performed as specified in
<xref section="5.9.4" sectionFormat="comma" target="RFC8995"/>.</t>
<t>In <xref target="RFC8995"/>, this is described as part of the certificate enrollment
step, but due to the generalization of the enrollment protocol
described in this document, it is regarded as a separate phase
here.</t>
</section>
</section>
<section anchor="addressing">
<name>Enhancements to the Endpoint Addressing Scheme of BRSKI</name>
<t>BRSKI-AE extends the addressing scheme outlined in <xref
section="5" sectionFormat="comma" target="RFC8995"/> to support
alternative enrollment protocols that utilize authenticated,
self-contained objects for certification requests (also see <xref
target="exist_prot"/>). These extensions are designed to be
compatible with existing Registration Authorities (RAs) and
Certification Authorities (CAs) that already support such enrollment
protocols, enabling their use without requiring any modifications.</t>
<t>The addressing scheme in <xref target="RFC8995"/> for certification requests,
related CA certificates, and CSR attributes retrieval functions uses the
definition from EST <xref target="RFC7030"/>. An example of
simple enrollment is: <tt>"/.well-known/est/simpleenroll"</tt>. This
approach is generalized to the following notation:
<tt>"/.well-known/<enrollment-protocol>/<request>"</tt> in
which "<tt><enrollment-protocol></tt>" refers to a certificate
enrollment protocol. Note that here, enrollment is considered a
message sequence that contains at least a certification request and a
certification response. The following conventions are used to provide
maximal compatibility with BRSKI:</t>
<ul spacing="normal">
<li>
<t>"<tt><enrollment-protocol></tt>": This <bcp14>MUST</bcp14>
reference the protocol being used. Existing values include
'<tt>est</tt>' <xref target="RFC7030"/> as in <xref target="RFC8995"/> and
'<tt>cmp</tt>' as in <xref target="RFC9483"/> and <xref
target="brski-cmp-instance"/> 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
"<tt><enrollment-protocol></tt>" and "<tt><request></tt>"
URI components, they would need to be specified in a suitable RFC
and placed into the "Well-Known URIs" registry, just as EST in <xref
target="RFC7030"/>.</t>
</li>
<li>
<t>"<tt><request></tt>": If present, this path component
<bcp14>MUST</bcp14> 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 <xref target="exist_prot"/>).</t>
</li>
</ul>
<t>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
<bcp14>MAY</bcp14> be supported by the registrar.</t>
<t>A pledge <bcp14>SHOULD</bcp14> use the endpoints defined for the
enrollment protocol(s) that it can use. It will recognize whether the
protocol it uses and the specific request it wants to perform are
understood and supported by the domain registrar. This is done by
sending the request to the respective endpoint according to the above
addressing scheme and then evaluating the HTTP status code of the
response. If the pledge uses endpoints that are not standardized, it
risks that the registrar does not recognize a request and thus may
reject it even if the registrar supports the intended protocol and
operation.</t>
<t>The following list of endpoints provides an illustrative example of
a domain registrar supporting several options for EST as well as for
CMP to be used in BRSKI-AE. The listing contains the supported
endpoints to which the pledge may connect for bootstrapping. This
includes the voucher handling as well as the enrollment endpoints.
The CMP-related enrollment endpoints are defined as well-known URIs in
CMP Updates <xref target="RFC9480"/> and the Lightweight CMP Profile
<xref target="RFC9483"/>.</t>
<ul spacing="normal">
<li>/.well-known/brski/voucherrequest</li>
<li>/.well-known/brski/voucher_status</li>
<li>/.well-known/brski/enrollstatus</li>
<li>/.well-known/est/cacerts</li>
<li>/.well-known/est/csrattrs</li>
<li>/.well-known/est/fullcmc</li>
<li>/.well-known/cmp/getcacerts</li>
<li>/.well-known/cmp/getcertreqtemplate</li>
<li>/.well-known/cmp/initialization</li>
<li>/.well-known/cmp/pkcs10</li>
</ul>
</section>
</section>
<section anchor="exist_prot">
<name>Instantiation with Existing Enrollment Protocols</name>
<t>This section maps the generic requirements to support proof of
possession and proof of identity to selected existing certificate
enrollment protocols and specifies further aspects of using such
enrollment protocols in BRSKI-AE.</t>
<section anchor="brski-cmp-instance">
<name>BRSKI-CMP: BRSKI-AE Instantiated with CMP</name>
<t>In this document, references to CMP follow the Lightweight CMP
Profile (LCMPP) from <xref target="RFC9483"/> rather than <xref
target="RFC4210"/> and <xref target="RFC9480"/>, as the subset of CMP
defined in the LCMPP sufficiently meets the required functionality.</t>
<t>Adherence to the LCMPP <xref target="RFC9483"/> is
<bcp14>REQUIRED</bcp14> when using CMP. The following specific
requirements apply (refer to <xref target="enrollfigure"/>):</t>
<ul spacing="normal">
<li>
<t>The validation of server response messages performed by the CMP
client within the pledge <bcp14>MUST</bcp14> be based on the trust
anchor established beforehand via the BRSKI voucher, i.e., on the
pinned-domain-cert.</t>
<t>Note that the integrity and authenticity checks on the RA/CA by
the CMP client can be stronger than for EST because they do not
need to be performed hop-by-hop but are usually end-to-end.</t>
</li>
<li>
<t>CA Certs Request (1) and Response (2): Requesting CA
certificates is <bcp14>OPTIONAL</bcp14>. If supported, it
<bcp14>SHALL</bcp14> be implemented as specified in <xref
section="4.3.1" sectionFormat="comma" target="RFC9483"/>.</t>
</li>
<li>
<t>Attribute Request (3) and Response (4): Requesting
certification request attributes is <bcp14>OPTIONAL</bcp14>. If
supported, it <bcp14>SHALL</bcp14> be implemented as specified in
<xref section="4.3.3" sectionFormat="comma" target="RFC9483"/>.</t>
<t>Alternatively, the registrar <bcp14>MAY</bcp14> modify the
requested certificate contents as specified in <xref
section="5.2.3.2" sectionFormat="comma" target="RFC9483"/>.</t>
</li>
<li>
<t>Certification Request (5) and Response (6): Certificates
<bcp14>SHALL</bcp14> be requested and provided as specified in the
LCMPP from <xref section="4.1.1" sectionFormat="comma"
target="RFC9483"/> (based on CRMF) or <xref section="4.1.4"
sectionFormat="comma" target="RFC9483"/> (based on PKCS #10).
</t>
<t>
Proof of possession <bcp14>SHALL</bcp14> be provided in a manner
suitable for the key type. Proof of identity
<bcp14>SHALL</bcp14> be provided by signature-based protection
of the certification request message as outlined in <xref
section="3.2" sectionFormat="comma" target="RFC9483"/> using
the IDevID secret.</t>
<t>
When the registrar forwards a certification request from the
pledge to a backend RA/CA, it is <bcp14>RECOMMENDED</bcp14> that
the registrar wraps the original certification request in a
nested message signed with its own credentials, as described in
<xref section="5.2.2.1" sectionFormat="comma"
target="RFC9483"/>. This approach explicitly conveys the
registrar's consent to the RA while retaining the original
certification request with the proof of origin provided by the
pledge's signature. </t>
<t>
If additional trust anchors beyond the pinned-domain-cert need
to be conveyed to the pledge, this <bcp14>SHOULD</bcp14> be done
in the '<tt>caPubs</tt>' field of the certification response
rather than through a CA Certs Response.</t>
</li>
<li>
<t>Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit
confirmation of new certificates to the RA/CA <bcp14>MAY</bcp14>
be used as specified in <xref section="4.1.1"
sectionFormat="comma" target="RFC9483"/>.</t>
</li>
</ul>
<aside>
<t>Note that independent of the certificate confirmation within CMP,
enrollment status telemetry with the registrar at the BRSKI level
will be performed as described in <xref section="5.9.4"
sectionFormat="comma" target="RFC8995"/>.</t>
</aside>
<ul spacing="normal">
<li>
<t>If delayed delivery of CMP messages is needed (e.g., to support
enrollment over an asynchronous channel), it <bcp14>SHALL</bcp14>
be performed as specified in Sections <xref target="RFC9483"
section="4.4" sectionFormat="bare"/> and <xref
target="RFC9483" section="5.1.2" sectionFormat="bare"/> of <xref
target="RFC9483"/>.</t>
</li>
</ul>
<t>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
allows for flexibility in choosing the appropriate exchange method
based on the application scenario. For the applicable security and
privacy considerations, refer to Sections <xref target="sec-consider" format="counter"/> and
<xref target="priv-consider" format="counter"/>. Further guidance can be found in
<xref section="6" sectionFormat="comma" target="RFC9483"/>.</t>
<t>BRSKI-AE with CMP can also be combined with Constrained BRSKI <xref
target="I-D.ietf-anima-constrained-voucher"/>, using CoAP for
enrollment message transport as described by CoAP Transfer for CMP <xref target="RFC9482"/>. In such scenarios, the EST-specific parts
of <xref target="I-D.ietf-anima-constrained-voucher"/> do not
apply.</t>
<t>For BRSKI-AE scenarios where a general solution for discovering
registrars with CMP support is not available (cf. <xref
target="discovery"/>), the following minimalist approach
<bcp14>MAY</bcp14> be used: Perform discovery as defined in <xref
target="RFC8995" sectionFormat="comma" section="B"/>, but use the service
name <tt>"brski-reg-cmp"</tt> (as defined in <xref
target="iana-consider"/>) instead of <tt>"brski-registrar"</tt> (as
defined in <xref section="8.6" sectionFormat="comma"
target="RFC8995"/>). Note that this approach does not support join
proxies.</t>
</section>
<section anchor="support-of-other-enrollment-protocols">
<name>Support of Other Enrollment Protocols</name>
<t>Further instantiations of BRSKI-AE can be done. They are left for
future work.</t>
<t>In particular, CMC <xref target="RFC5272"/> (using its in-band
source authentication options) and SCEP <xref target="RFC8894"/>
(using its 'renewal' option) could be used.</t>
<t>The fullCMC variant of EST sketched in <xref section="2.5"
sectionFormat="comma" target="RFC7030"/> might also be used here. For
EST-fullCMC, further specification is necessary.
</t>
</section>
</section>
<section anchor="iana-consider">
<name>IANA Considerations</name>
<t>IANA has registered the following service name in the <eref
target="https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml" brackets="angle">"Service
Name and Transport Protocol Port Number Registry"</eref>.</t>
<dl spacing="compact" newline="false">
<dt>Service Name:</dt><dd>brski-reg-cmp</dd>
<dt>Transport Protocol(s):</dt><dd>tcp</dd>
<dt>Description:</dt><dd>Bootstrapping Remote Secure Key
Infrastructure registrar with CMP capabilities according to the
Lightweight CMP Profile (LCMPP) <xref target="RFC9483"/></dd>
<dt>Assignee:</dt><dd>IESG <eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref></dd>
<dt>Contact:</dt><dd>IETF <eref target="mailto:chair@ietf.org">chair@ietf.org</eref></dd>
<dt>Reference:</dt><dd>RFC 9733</dd>
</dl>
<aside>
<t>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 implies adherence to
the LCMPP is necessary and sufficient.</t>
</aside>
</section>
<section anchor="sec-consider">
<name>Security Considerations</name>
<t>The security considerations laid out in <xref section="11"
sectionFormat="comma" target="RFC8995"/> apply to the discovery and
voucher exchange as well as for the status exchange information.</t>
<t>In particular, 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 <xref
section="5.3" sectionFormat="comma" target="RFC8995"/>. As this also
pertains to obtaining a valid domain-specific certificate, it must
be made sure that a pledge cannot circumvent the registrar in the
decision of whether it is granted an LDevID certificate by the CA.
There are various ways to fulfill this, including:</t>
<ul spacing="normal">
<li>
<t>implicit consent;</t>
</li>
<li>
<t>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;</t>
</li>
<li>
<t>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</t>
</li>
<li>
<t>the registrar explicitly stating its consent by signing the
authenticated self-contained certificate enrollment request message
in addition to the pledge.</t>
</li>
</ul>
<aside>
<t>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.</t>
</aside>
<t>When CMP is used, the security considerations laid out in the LCMPP from <xref target="RFC9483"/> apply.</t>
</section>
<section anchor="priv-consider">
<name>Privacy Considerations</name>
<t>The privacy considerations laid out in <xref section="10"
sectionFormat="comma" target="RFC8995"/> apply as well.</t>
<t>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.</t>
<t>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.</t>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-anima-brski-discovery" to="BRSKI-discovery"/>
<displayreference target="I-D.ietf-anima-constrained-voucher" to="cBRSKI"/>
<references>
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9483.xml"/>
<!-- [IEEE_802.1AR-2018] -->
<reference anchor="IEEE_802.1AR-2018" target="https://ieeexplore.ieee.org/document/8423794">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2018" month="August"/>
</front>
<seriesInfo name="IEEE" value="802.1AR-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<!-- [I-D.ietf-anima-constrained-voucher] IESG State: I-D Exists as of 10/28/2024; WG State: In WG Last Call as of 10/28/2024 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml"/>
<reference anchor="BRSKI-AE-overview" target="https://datatracker.ietf.org/meeting/116/materials/slides-116-anima-update-on-brski-ae-alternative-enrollment-protocols-in-brski-00">
<front>
<title>Update on BRSKI-AE: Alternative Enrollment Protocols in BRSKI</title>
<author initials="D." surname="von Oheimb" fullname="David von Oheimb" role="editor">
<organization/>
</author>
<author initials="S." surname="Fries" fullname="Steffen Fries">
<organization/>
</author>
<author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
<organization/>
</author>
<date year="2023" month="March"/>
</front>
<refcontent>IETF 116 - ANIMA Working Group Presentation</refcontent>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5929.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6955.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8366.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8894.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9148.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9482.xml"/>
<reference anchor="IEC-62351-9" target="https://webstore.iec.ch/en/publication/66864">
<front>
<title>Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment</title>
<author>
<organization>International Electrotechnical Commission</organization>
</author>
<date year="2023" month="June"/>
</front>
<seriesInfo name="IEC" value="62351-9:2023"/>
</reference>
<reference anchor="NERC-CIP-005-5" target="">
<front>
<title>Cyber Security - Electronic Security Perimeter</title>
<author>
<organization>North American Electric Reliability Council</organization>
</author>
<date year="2013" month="December"/>
</front>
<seriesInfo name="CIP" value="005-5"/>
</reference>
<reference anchor="ISO-IEC-15118-2" target="https://www.iso.org/standard/55366.html">
<front>
<title>Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network and application protocol requirements</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date year="2014" month="April"/>
</front>
<seriesInfo name="ISO" value="15118-2:2014"/>
</reference>
<reference anchor="UNISIG-Subset-137" target="https://www.era.europa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf">
<front>
<title>ERTMS/ETCS On-line Key Management FFFIS</title>
<author>
<organization>UNISIG</organization>
</author>
<date year="2015" month="December"/>
</front>
<refcontent>Subset-137, Version 1.0.0</refcontent>
</reference>
<reference anchor="OCPP">
<front>
<title>Open Charge Point Protocol 2.0.1 (Draft)</title>
<author>
<organization>Open Charge Alliance</organization>
</author>
<date year="2019" month="December"/>
</front>
</reference>
<!-- [I-D.ietf-anima-brski-discovery] IESG State: I-D Exists as of 10/28/2024 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-anima-brski-discovery.xml"/>
</references>
</references>
<section anchor="app-examples">
<name>Application Examples</name>
<t>This informative annex provides some details about application examples.</t>
<section anchor="rolling-stock">
<name>Rolling Stock</name>
<t>Rolling stock or railroad cars contain a variety of sensors,
actuators, and controllers. These communicate within the railroad car
but also exchange information with other railroad cars of the same train and
with track-side equipment and/or possibly with backend systems.
These devices are typically unaware of backend system connectivity.
Enrolling certificates may be done during maintenance cycles of the
railroad car but can already be prepared during operation. Such
asynchronous enrollment will include generating certification
requests, which are collected and later forwarded for processing
whenever the railroad car gets connectivity with the backend PKI of
the operator. The authorization of the certification request is then
done based on the operator's asset/inventory information in the
backend.</t>
<t>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 <xref
target="UNISIG-Subset-137"/>.</t>
</section>
<section anchor="building-automation">
<name>Building Automation</name>
<t>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 such a 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.</t>
<t>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.</t>
</section>
<section anchor="substation-automation">
<name>Substation Automation</name>
<t>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
<xref target="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 <xref target="IEC-62351-9"/> specifies mandatory support of
two enrollment protocols for the infrastructure side, SCEP <xref
target="RFC8894"/> and EST <xref target="RFC7030"/>, while an
IED may support only one of them.</t>
</section>
<section anchor="electric-vehicle-charging-infrastructure">
<name>Electric Vehicle Charging Infrastructure</name>
<t>For electric vehicle charging infrastructure, protocols have been
defined for the interaction between the electric vehicle and the
charging point (e.g., ISO 15118-2 <xref target="ISO-IEC-15118-2"/>) as
well as between the charging point and the charging point operator
(e.g., OCPP <xref target="OCPP"/>). Depending on the authentication
model, unilateral or mutual authentication is required. In both cases,
the charging point uses an X.509 certificate to authenticate itself in
TLS channels between the electric vehicle and the charging point. The
management of this certificate depends, among other things, on the selected
backend connectivity protocol. In the case of OCPP, this protocol is
meant to be the only communication protocol between the charging point
and the backend, carrying all information to control the charging
operations and maintain the charging point itself. This means that the
certificate management needs to be handled in-band of OCPP. This
requires the ability to encapsulate the certificate management
messages in a transport-independent way. Authenticated
self-containment will support this by allowing the transport without a
separate enrollment protocol, binding the messages to the identity of
the communicating endpoints.</t>
</section>
<section anchor="infrastructure-isolation">
<name>Infrastructure Isolation Policy</name>
<t>The approach described in this section refers to any case in which
network infrastructure is normally isolated from the Internet as a
matter of policy, most likely for security reasons. In such a case,
limited access to external PKI services will be allowed in carefully
controlled short periods of time (for example, when a batch of new
devices is deployed) and forbidden or prevented at other times.</t>
</section>
<section anchor="sites-with-insufficient-level-of-operational-security">
<name>Sites with Insufficient Levels of Operational Security</name>
<t>The RA performing (at least part of) the authorization of a
certification request is a critical PKI component and therefore
requires higher operational security than components utilizing the
issued certificates for their security features. CAs may also demand
higher security in the registration procedures from RAs, which domain
registrars with co-located RAs may not be able to fulfill. In
particular, the CA/Browser forum currently increases the security
requirements in the certificate issuance procedures for publicly
trusted certificates, i.e., those placed in trust stores of browsers,
which may be used to connect with devices in the domain. In case the
on-site components of the target domain cannot be operated securely
enough for the needs of an RA, this service should be transferred to
an off-site backend component that has a sufficient level of
security.</t>
</section>
</section>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>We thank <contact fullname="Eliot Lear"/> for his contributions as a
co-author at an earlier draft stage.</t>
<t>We thank <contact fullname="Brian E. Carpenter"/>, <contact
fullname="Michael Richardson"/>, and <contact fullname="Giorgio
Romanenghi"/> for their input and discussion on use cases and call
flows.</t>
<t>Moreover, we thank <contact fullname="Toerless Eckert"/> (document
shepherd); <contact fullname="Barry Leiba"/> (SECdir review); <contact
fullname="Mahesh Jethanandani"/> (IETF area director); <contact
fullname="Meral Shirazipour"/> (Gen-ART reviewer); <contact
fullname="Reshad Rahman"/> (YANGDOCTORS reviewer); <contact
fullname="Deb Cooley"/>, <contact fullname="Gunter Van de Velde"/>,
<contact fullname="John Scudder"/>, <contact fullname="Murray
Kucherawy"/>, <contact fullname="Roman Danyliw"/>, and <contact
fullname="Éric Vyncke"/> (IESG reviewers); <contact fullname="Michael
Richardson"/> (ANIMA design team member); and <contact
fullname="Rajeev Ranjan"/>, <contact fullname="Rufus Buschart"/>,
<contact fullname="Andreas Reiter"/>, and <contact fullname="Szofia
Fazekas-Zisch"/> (Siemens colleagues) for their reviews with suggestions
for improvements.</t>
</section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
<name>Contributors</name>
<contact initials="E." surname="Lear" fullname="Eliot Lear">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Richtistrasse 7</street>
<city>Wallisellen</city>
<code>8304</code>
<country>Switzerland</country>
</postal>
<phone>+41 44 878 9200</phone>
<email>lear@cisco.com</email>
</address>
</contact>
</section>
</back>
<!-- [rfced] Formatting and XML:
c.) We note the following different uses regarding this document's use of <tt>
styling and quotation marks. In the HTML and PDF outputs, the text enclosed in
<tt> is output in fixed-width font. In the txt output, there are no changes to
the font. Please review carefully and let us know if any updates should be made
for consistency:
the <tt>caPubs</tt> field
the acp-node-name field (no quotes or <tt> styling)
-->
<!-- [rfced] Abbreviations:
b.) We note the following expanded forms of "PKI" are used after the
abbreviation is introduced. May we update these instances below to the
abbreviation?
Public-Key Infrastructure
-->
</rfc>