rfc9733v1.txt   rfc9733.txt 
Internet Engineering Task Force (IETF) D. von Oheimb, Ed. Internet Engineering Task Force (IETF) D. von Oheimb, Ed.
Request for Comments: 9733 S. Fries Request for Comments: 9733 S. Fries
Category: Standards Track H. Brockhaus Category: Standards Track H. Brockhaus
ISSN: 2070-1721 Siemens ISSN: 2070-1721 Siemens
February 2025 February 2025
BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with BRSKI with Alternative Enrollment (BRSKI-AE) Protocol
Alternative Enrollment
Abstract Abstract
This document defines enhancements to the Bootstrapping Remote Secure This document defines enhancements to the Bootstrapping Remote Secure
Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative
Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate
enrollment mechanisms instead of the originally specified use of enrollment mechanisms instead of the originally specified use of
Enrollment over Secure Transport (EST). It supports certificate Enrollment over Secure Transport (EST). It supports certificate
enrollment protocols such as the Certificate Management Protocol enrollment protocols such as the Certificate Management Protocol
(CMP) that use authenticated self-contained signed objects for (CMP) that use authenticated self-contained signed objects for
skipping to change at line 119 skipping to change at line 118
enrollment. Consequently, this provides architectural flexibility in enrollment. Consequently, this provides architectural flexibility in
determining the location and timing for the ultimate authentication determining the location and timing for the ultimate authentication
and authorization of certification requests while ensuring that the and authorization of certification requests while ensuring that the
integrity and authenticity of the enrollment messages are maintained integrity and authenticity of the enrollment messages are maintained
with full cryptographic strength. with full cryptographic strength.
This specification carries over the main characteristics of BRSKI, This specification carries over the main characteristics of BRSKI,
namely: namely:
* The pledge is assumed to have received its Initial Device * The pledge is assumed to have received its Initial Device
Identifier (IDevID) [IEEE_802.1AR-2018] credentials during its IDentifier (IDevID) [IEEE_802.1AR-2018] credentials during its
manufacturing. It uses them to authenticate itself to the manufacturing. It uses them to authenticate itself to the
Manufacturer Authorized Signing Authority (MASA) [RFC8995] and the Manufacturer Authorized Signing Authority (MASA) [RFC8995], to the
registrar (which is the access point of the target domain) and to registrar (which is the access point of the target domain), and to
possibly further components of the domain where it will be possibly further components of the domain where it will be
operated. operated.
* The pledge first obtains via the voucher exchange [RFC8366] a * The pledge first obtains via the voucher [RFC8366] exchange a
trust anchor for authenticating entities in the domain such as the trust anchor for authenticating entities in the domain such as the
domain registrar. domain registrar.
* The pledge then obtains its Local Device Identifier (LDevID) * The pledge then obtains its Locally Significant Device IDentifier
[IEEE_802.1AR-2018]. To this end, the pledge generates a private (LDevID) [IEEE_802.1AR-2018]. To this end, the pledge generates a
key, called an "LDevID secret". Then, it requests via the domain private key, called an "LDevID secret". Then, it requests via the
registrar from the PKI of its new domain a domain-specific device domain registrar from the PKI of its new domain a domain-specific
certificate, called an "LDevID certificate". On success, it device certificate, called an "LDevID certificate". On success,
receives the LDevID certificate along with its certificate chain. it receives the LDevID certificate along with its certificate
chain.
The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID
certificate enrollment through the use of an alternative protocol to certificate enrollment through the use of an alternative protocol to
EST that: EST that:
* supports end-to-end authentication over multiple transport hops * supports end-to-end authentication over multiple transport hops
and and
* facilitates secure message exchanges over any type of transfer * facilitates secure message exchanges over any type of transfer
mechanism, including asynchronous delivery. mechanism, including asynchronous delivery.
skipping to change at line 160 skipping to change at line 160
The existing well-known URI structure used for BRSKI and EST messages The existing well-known URI structure used for BRSKI and EST messages
is extended by introducing an additional path element that specifies is extended by introducing an additional path element that specifies
the enrollment protocol being employed. the enrollment protocol being employed.
This specification allows the registrar to offer multiple enrollment This specification allows the registrar to offer multiple enrollment
protocols, enabling pledges and their developers to select the most protocols, enabling pledges and their developers to select the most
appropriate one based on the defined overall approach and specific appropriate one based on the defined overall approach and specific
endpoints. endpoints.
It may be important to note that BRSKI [RFC8995] specifies the use of It may be important to note that [RFC8995] specifies the use of HTTP
HTTP over TLS, but variations such as Constrained BRSKI [cBRSKI], over TLS, but variations such as Constrained BRSKI [cBRSKI], which
which uses the Constrained Application Protocol (CoAP) over DTLS, are uses the Constrained Application Protocol (CoAP) over DTLS, are
possible as well. In this context, "HTTP" and "TLS" are used as possible as well. In this context, "HTTP" and "TLS" are used as
references to the most common implementation, though variants using references to the most common implementation, though variants using
CoAP and/or DTLS are implied where applicable, as the distinctions CoAP and/or DTLS are implied where applicable, as the distinctions
are not pertinent here. are not pertinent here.
This specification, together with its referenced documents, is This specification, together with its referenced documents, is
sufficient to support BRSKI with the Certificate Management Protocol sufficient to support BRSKI with the Certificate Management Protocol
(CMP) [RFC9480] as profiled in the Lightweight CMP Profile (LCMPP) (CMP) [RFC9480] as profiled in the Lightweight CMP Profile (LCMPP)
[RFC9483]. Integrating BRSKI with an enrollment protocol or profile [RFC9483]. Integrating BRSKI with an enrollment protocol or profile
other than LCMPP will necessitate additional IANA registrations, as other than the LCMPP will necessitate additional IANA registrations,
detailed in this document. Furthermore, additional specifications as detailed in this document. Furthermore, additional specifications
may be required for the details of the protocol or profile, which may be required for the details of the protocol or profile, which
fall outside the scope of this document. fall outside the scope of this document.
1.1. Supported Scenarios 1.1. Supported Scenarios
BRSKI-AE is designed for use in scenarios such as the following: BRSKI-AE is designed for use in scenarios such as the following:
* When pledges and/or the target domain leverage an existing * When pledges and/or the target domain leverage an existing
certificate enrollment protocol other than EST, such as CMP. certificate enrollment protocol other than EST, such as CMP.
skipping to change at line 242 skipping to change at line 242
capitals, as shown here. capitals, as shown here.
This document relies on the terminology defined in [RFC8995], This document relies on the terminology defined in [RFC8995],
[RFC5280], and [IEEE_802.1AR-2018], which is partly repeated here. [RFC5280], and [IEEE_802.1AR-2018], which is partly repeated here.
Several further terms are also described here. Several further terms are also described here.
To be independent of the terminology of a specific enrollment To be independent of the terminology of a specific enrollment
protocol, this document utilizes generic terminology regarding PKI protocol, this document utilizes generic terminology regarding PKI
management operations. management operations.
The following terminology is used in this document:
asynchronous: the time-wise interrupted delivery of messages, here, asynchronous: the time-wise interrupted delivery of messages, here,
between a pledge and some backend system (e.g., an RA). between a pledge and some backend system (e.g., an RA).
attribute request: a message requesting content to be included in attribute request: a message requesting content to be included in
the certification request. the certification request.
attribute response: a message providing the answer to the attribute attribute response: a message providing the answer to the attribute
request. request.
authenticated self-contained object: a data structure that is authenticated self-contained object: a data structure that is
cryptographically bound to the identity of its originator by an cryptographically bound to the identity of its originator by an
attached digital signature on the actual object, using a private attached digital signature on the actual object, using a private
key of the originator such as the IDevID secret. key of the originator such as the IDevID secret.
backend: the placement of a domain component separately from the backend: the placement of a domain component separately from the
domain registrar; it may be on-site or off-site. domain registrar; it may be on-site or off-site.
BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995]
BRSKI-AE: BRSKI with Alternative Enrollment. Refers to a variation
of BRSKI [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 Lightweight CMP (see LCMPP).
CA: Certification Authority
CA certs request: a message requesting CA certificates. CA certs request: a message requesting CA certificates.
CA certs response: a message providing the answer to a CA certs CA certs response: a message providing the answer to a CA certs
request. request.
certificate confirm: a message stating to the backend PKI that the certificate confirm: a message stating to the backend PKI that the
requester of a certificate received the new certificate and requester of a certificate received the new certificate and
accepted it. accepted it.
certification request: a message requesting a certificate with proof certification request: a message requesting a certificate with proof
of identity. of identity.
certification response: a message providing the answer to a certification response: a message providing the answer to a
certification request. certification request.
CMP: Certificate Management Protocol [RFC4210] [RFC9480] local RA: the same as LRA.
CSR: Certificate Signing Request
EST: Enrollment over Secure Transport [RFC7030]
IDevID: 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).
LCMPP: Lightweight CMP Profile [RFC9483]
LDevID: Local 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).
LRA: 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.
MASA: Manufacturer Authorized Signing Authority. Provides vouchers.
off-site: the locality of a component, service, or functionality off-site: the locality of a component, service, or functionality
(such as RA or CA) that is not at the site of the registrar. This (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 may be a central site or a cloud service, to which connection may
be intermittent. be intermittent.
on-site: the locality of a component, service, or functionality at on-site: the locality of a component, service, or functionality at
the site of the registrar. the site of the registrar.
PKI/registrar confirm: an acknowledgment of the PKI on the PKI/registrar confirm: an acknowledgment of the PKI on the
certificate confirm. certificate confirm.
pledge: a device that is to be bootstrapped into a target domain. pledge: a device that is to be bootstrapped into a target domain.
It requests an LDevID using IDevID credentials installed by its It requests an LDevID using IDevID credentials installed by its
manufacturer. manufacturer.
RA: 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.
registrar: short for domain registrar. registrar: short for domain registrar.
site: the locality where an entity such as a pledge, registrar, or site: the locality where an entity such as a pledge, registrar, or
PKI component is deployed. The target domain may have multiple PKI component is deployed. The target domain may have multiple
sites. sites.
synchronous: the time-wise uninterrupted delivery of messages, here, synchronous: the time-wise uninterrupted delivery of messages, here,
between a pledge and a registrar or backend system (e.g., the between a pledge and a registrar or backend system (e.g., the
MASA). MASA).
target domain: the domain that a pledge is going to be bootstrapped target domain: the domain that a pledge is going to be bootstrapped
into. into.
The following abbreviations are used in this document:
BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995]
BRSKI-AE: BRSKI with Alternative Enrollment. Refers to a variation
of BRSKI [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.
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 comprising 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 comprising of a private key and the
related X.509 certificate with its chain).
LRA: 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.
MASA: Manufacturer Authorized Signing Authority. Provides vouchers.
RA: 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.
SCEP: Simple Certificate Enrolment Protocol
3. Basic Requirements and Mapping to Solutions 3. Basic Requirements and Mapping to Solutions
Based on the intended target scenarios described in Section 1.1 and Based on the intended target scenarios described in Section 1.1 and
the application examples described in Appendix A, the following the application examples described in Appendix A, the following
requirements are derived to support authenticated self-contained requirements are derived to support authenticated self-contained
objects as containers carrying certification requests. objects as containers carrying certification requests.
The following properties are required for a certification request: The following properties are required for a certification request:
* Proof of possession: demonstrates access to the private key * Proof of possession: demonstrates access to the private key
skipping to change at line 395 skipping to change at line 409
It should be noted that the integrity protection of CSRs includes the 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 public key because it is part of the data signed by the corresponding
private key. Yet, this signature does not provide data origin private key. Yet, this signature does not provide data origin
authentication, (i.e., proof of identity of the requester) because authentication, (i.e., proof of identity of the requester) because
the key pair involved is new and therefore does not yet have a the key pair involved is new and therefore does not yet have a
confirmed identity associated with it. confirmed identity associated with it.
3.2. Solution Options for Proof of Identity 3.2. Solution Options for Proof of Identity
Binding a Certificate Signing Request (CSR) to an existing Binding a Certificate Signing Request (CSR) to an existing
authenticated credential (the BRSKI context, the IDevID certificate) authenticated credential (which in the BRSKI context is the IDevID
enables proof of origin, which in turn supports an authorization certificate) enables proof of origin, which in turn supports an
decision on the CSR. authorization decision on the CSR.
The binding of data origin authentication to the CSR is typically The binding of data origin authentication to the CSR is typically
delegated to the protocol used for certificate management. This delegated to the protocol used for certificate management. This
binding may be achieved through security options in an underlying binding may be achieved through security options in an underlying
transport protocol such as TLS if the authorization of the transport protocol such as TLS if the authorization of the
certification request is (sufficiently) done at the next certification request is (sufficiently) done at the next
communication hop. Depending on the key type, the binding can also communication hop. Depending on the key type, the binding can also
be done in a stronger, transport-independent way by wrapping the CSR be done in a stronger, transport-independent way by wrapping the CSR
with a signature. with a signature.
This requirement is addressed by existing enrollment protocols in This requirement is addressed by existing enrollment protocols in
various ways, such as: various ways, such as:
* EST [RFC7030] and its variant EST-coaps [RFC9148] utilize PKCS #10 * EST [RFC7030] and its variant EST-coaps [RFC9148] utilize PKCS #10
to encode CSRs. While such a CSR has not been designed to include 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 proof of origin, there is a limited, indirect way of binding it to
the source authentication of the underlying TLS session. This is the source authentication of the underlying TLS session. This is
achieved by including in the CSR the tls-unique value [RFC5929] achieved by including in the CSR the "tls-unique" value [RFC5929]
resulting from the TLS handshake. As this is optionally supported resulting from the TLS handshake. As this is optionally supported
by the EST "/simpleenroll" endpoint used in BRSKI, and the TLS by the EST "/simpleenroll" endpoint used in BRSKI, and the TLS
handshake employed in BRSKI includes certificate-based client handshake employed in BRSKI includes certificate-based client
authentication of the pledge with its IDevID credentials, the authentication of the pledge with its IDevID credentials, the
proof of pledge identity being an authenticated TLS client can be proof of pledge identity being an authenticated TLS client can be
bound to the CSR. bound to the CSR.
Yet, this binding is only valid in the context of the TLS session Yet, this binding is only valid in the context of the TLS session
established with the registrar acting as the EST server and established with the registrar acting as the EST server and
typically also as an RA. So even such a cryptographic binding of typically also as an RA. So even such a cryptographic binding of
the authenticated pledge identity to the CSR is not visible nor the authenticated pledge identity to the CSR is not visible nor
verifiable to authorization points outside the registrar, such as verifiable to authorization points outside the registrar, such as
a (second) RA in the backend. What the registrar needs to do is a (second) RA in the backend. What the registrar needs to do is
authenticate and pre-authorize the pledge and indicate this to the authenticate and pre-authorize the pledge and indicate this to the
(second) RA. This is done by signing the forwarded certification (second) RA. This is done by signing the forwarded certification
request with its private key and a related certificate that has request with its private key and a related certificate that has
the id-kp-cmcRA extended key usage attribute. the id-kp-cmcRA extended key usage attribute.
[RFC7030], Section 2.5 sketches wrapping PKCS #10-formatted CSRs [RFC7030], Section 2.5 sketches wrapping CSRs formatted per PKCS
with a Full PKI Request message sent to the "/fullcmc" endpoint. #10 with a Full PKI Request message sent to the "/fullcmc"
This would allow for source authentication at the message level, endpoint. This would allow for source authentication at the
such that the registrar could forward it to external RAs in a message level, such that the registrar could forward it to
meaningful way. This approach is so far not sufficiently external RAs in a meaningful way. This approach is so far not
described and likely has not been implemented. sufficiently described and likely has not been implemented.
* The Simple Certificate Enrolment Protocol (SCEP) [RFC8894] * The Simple Certificate Enrolment Protocol (SCEP) [RFC8894]
supports using a shared secret (passphrase) or an existing supports using a shared secret (passphrase) or an existing
certificate to protect CSRs based on SCEP Secure Message Objects certificate to protect CSRs based on SCEP Secure Message Objects
using Cryptographic Message Syntax (CMS) wrapping [RFC5652]. Note using Cryptographic Message Syntax (CMS) wrapping [RFC5652]. Note
that the wrapping using an existing IDevID in SCEP is referred to 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 as "renewal". This way, SCEP does not rely on the security of the
underlying message transfer. underlying message transfer.
* CMP [RFC4210] [RFC9480] supports using a shared secret * CMP [RFC4210] [RFC9480] supports using a shared secret
skipping to change at line 461 skipping to change at line 475
credential, to authenticate certification requests via the credential, to authenticate certification requests via the
PKIProtection structure in a PKIMessage. The certification PKIProtection structure in a PKIMessage. The certification
request is typically encoded utilizing CRMF, while PKCS #10 is request is typically encoded utilizing CRMF, while PKCS #10 is
supported as an alternative. Thus, CMP does not rely on the supported as an alternative. Thus, CMP does not rely on the
security of the underlying message transfer. security of the underlying message transfer.
* Certificate Management over CMS (CMC) [RFC5272] also supports * Certificate Management over CMS (CMC) [RFC5272] also supports
utilizing a shared secret (passphrase) or an existing certificate utilizing a shared secret (passphrase) or an existing certificate
to protect certification requests, which can be either in a CRMF to protect certification requests, which can be either in a CRMF
or PKCS #10 structure. The proof of identity can be provided as or PKCS #10 structure. The proof of identity can be provided as
part of a FullCMCRequest based on CMS [RFC5652] and signed with an part of a Full CMC Request based on CMS [RFC5652] and signed with
existing IDevID secret. Thus, CMC does not rely on the security an existing IDevID secret. Thus, CMC does not rely on the
of the underlying message transfer. security of the underlying message transfer.
To sum up, EST does not meet the requirements for authenticated self- To sum up, EST does not meet the requirements for authenticated self-
contained objects, but SCEP, CMP, and CMC do. This document contained objects, but SCEP, CMP, and CMC do. This document
primarily focuses on CMP as it has more industry adoption than CMC primarily focuses on CMP as it has more industry adoption than CMC
and SCEP has issues not detailed here. and SCEP has issues not detailed here.
4. Adaptations to BRSKI 4. Adaptations to BRSKI
To enable using alternative certificate enrollment protocols To enable using alternative certificate enrollment protocols
supporting end-to-end authentication, asynchronous enrollment, and supporting end-to-end authentication, asynchronous enrollment, and
skipping to change at line 532 skipping to change at line 546
| IDevID | . +-------+ +--------------+ . | IDevID | . +-------+ +--------------+ .
| | BRSKI-AE over TLS ^ . | | BRSKI-AE over TLS ^ .
+--------+ using, e.g., LCMPP | . +--------+ using, e.g., LCMPP | .
. | . . | .
...............................|......... ...............................|.........
on-site (local) domain components | on-site (local) domain components |
| |
| e.g., LCMPP | e.g., LCMPP
| |
.............................................|............... .............................................|...............
. Public-Key Infrastructure v . . Public-Key Infrastructure (PKI) v .
. +---------+ +---------------------------------------+ . . +---------+ +---------------------------------------+ .
. | |<----+ Registration Authority RA | . . | |<----+ Registration Authority RA | .
. | CA +---->| (unless part of Domain Registrar) | . . | CA +---->| (unless part of Domain Registrar) | .
. +---------+ +---------------------------------------+ . . +---------+ +---------------------------------------+ .
............................................................. .............................................................
backend (central or off-site) domain components backend (central or off-site) domain components
Figure 1: Architecture Overview Using Backend PKI Components Figure 1: Architecture Overview Using Backend PKI Components
The architecture overview in Figure 1 has the same logical elements The architecture overview in Figure 1 has the same logical elements
as BRSKI but with a more flexible placement of the authentication and as BRSKI but with a more flexible placement of the authentication and
authorization checks on certification requests. Depending on the authorization checks on certification requests. Depending on the
application scenario, the registrar MAY still do all of these checks application scenario, the registrar MAY still do all of these checks
(as is the case in BRSKI) or only do part of them. (as is the case in BRSKI) or only do part of them.
The following list describes the on-site components in the target The following list describes the on-site components in the target
domain of the pledge shown in Figure 1. domain of the pledge shown in Figure 1.
* Join Proxy: This has the same requirements as in BRSKI (see * Join Proxy: This has the same requirements as in [RFC8995] (see
[RFC8995], Section 4). [RFC8995], Section 4).
* Domain Registrar (including LRA or RA functionality): In BRSKI-AE, * Domain Registrar (including LRA or RA functionality): In BRSKI-AE,
the domain registrar has mostly the same functionality as in the domain registrar has mostly the same functionality as in
BRSKI, namely to act as the gatekeeper of the domain for BRSKI, namely to act as the gatekeeper of the domain for
onboarding new devices and to facilitate the communication of onboarding new devices and to facilitate the communication of
pledges with their MASA and the domain PKI. Yet, there are some pledges with their MASA and the domain PKI. Yet, there are some
generalizations and specific requirements: generalizations and specific requirements:
1. The registrar MUST support at least one certificate enrollment 1. The registrar MUST support at least one certificate enrollment
skipping to change at line 604 skipping to change at line 618
is unprotected and involves further transport hops. See is unprotected and involves further transport hops. See
Section 7 for details on how this can be achieved. Section 7 for details on how this can be achieved.
Despite the above generalizations of the enrollment phase, the final Despite the above generalizations of the enrollment phase, the final
step of BRSKI, namely the enrollment status telemetry, is kept as it step of BRSKI, namely the enrollment status telemetry, is kept as it
is. is.
The following list describes the components provided by the vendor or The following list describes the components provided by the vendor or
manufacturer outside the target domain. manufacturer outside the target domain.
* MASA: This has the functionality as described in BRSKI [RFC8995]. * MASA: This has the functionality as described in [RFC8995]. The
The voucher exchange with the MASA via the domain registrar is voucher exchange with the MASA via the domain registrar is
performed as described in BRSKI. performed as described in [RFC8995].
Note: From the definition of the interaction with the MASA in | Note: The definition of the interaction with the MASA in
[RFC8995], Section 5 follows that it may be synchronous (using | Section 5 of [RFC8995] implies that it may be synchronous
voucher requests with nonces) or asynchronous (using nonceless | (using voucher requests with nonces) or asynchronous (using
voucher requests). | nonceless voucher requests).
* Ownership Tracker: This is as defined in BRSKI. * Ownership Tracker: This is as defined in [RFC8995].
The following list describes backend target domain components, which The following list describes backend target domain components, which
may be located on-site or off-site in the target domain. may be located on-site or off-site in the target domain.
* RA: This performs centralized certificate management functions as * RA: This performs centralized certificate management functions as
a public-key infrastructure for the domain operator. As far as a PKI for the domain operator. In case these functions are not
not already done by the domain registrar, it performs the final entirely performed by the domain registrar, it performs the final
validation and authorization of certification requests. validation and authorization of certification requests.
Otherwise, the RA co-located with the domain registrar directly Otherwise, the RA co-located with the domain registrar directly
connects to the CA. connects to the CA.
* CA (also called "domain CA"): This generates domain-specific * CA (also called "domain CA"): This generates domain-specific
certificates according to certification requests that have been certificates according to certification requests that have been
authenticated and authorized by the registrar and/or an extra RA. authenticated and authorized by the registrar and/or an extra RA.
Based on the diagram in BRSKI [RFC8995], Section 2.1 and the Based on the diagram in [RFC8995], Section 2.1 and the architectural
architectural changes, the original protocol flow is divided into changes, the original protocol flow is divided into several phases
several phases showing commonalities and differences with the showing commonalities and differences with the original approach as
original approach as follows. follows.
* Discovery phase: This is mostly as in step (1) of [RFC8995]. For * Discover: This is mostly as in step (1) of [RFC8995]. For
details, see Section 4.2.1. details, see Section 4.2.1.
* Identification phase: This is the same as in step (2) of * Identify: This is the same as in step (2) of [RFC8995].
[RFC8995].
* Voucher exchange phase: This is the same as in steps (3) and (4) * Voucher exchange: This is the same as in steps (3) and (4) of
of [RFC8995]. [RFC8995].
* Voucher status telemetry: This is the same as directly after step * Voucher status telemetry: This is the same as directly after step
(4) in [RFC8995]. (4) in [RFC8995].
* Certificate enrollment phase: The use of EST in step (5) is * Certificate enrollment phase: The use of EST in step (5) is
changed to employing a certificate enrollment protocol that uses changed to employing a certificate enrollment protocol that uses
an authenticated self-contained object for requesting the LDevID an authenticated self-contained object for requesting the LDevID
certificate. certificate.
For transporting the certificate enrollment request and response It is REQUIRED to use the (D)TLS channel established between the
messages, the (D)TLS channel established between pledge and pledge and registrar to transport the certificate enrollment
registrar is REQUIRED to use. To this end, the enrollment request and response messages. To this end, the enrollment
protocol, the pledge, and the registrar need to support the use of protocol, the pledge, and the registrar need to support the use of
this existing channel for certificate enrollment. Due to this this existing channel for certificate enrollment. Due to this
architecture, the pledge does not need to establish additional architecture, the pledge does not need to establish additional
connections for certificate enrollment and the registrar retains connections for certificate enrollment and the registrar retains
full control over the certificate enrollment traffic. full control over the certificate enrollment traffic.
* Enrollment status telemetry: This is the final exchange of step * Enrollment status telemetry: This is the final exchange of step
(5) of [RFC8995]. (5) of [RFC8995].
4.2. Message Exchange 4.2. Message Exchange
The behavior of a pledge described in BRSKI [RFC8995], Section 2.1 is The behavior of a pledge described in [RFC8995], Section 2.1 is kept,
kept, with one major exception. After finishing the Imprint step with one major exception. After finishing the Imprint step (4), the
(4), the Enroll step (5) MUST be performed with an enrollment Enroll step (5) MUST be performed with an enrollment protocol
protocol utilizing authenticated self-contained objects, as explained utilizing authenticated self-contained objects, as explained in
in Section 3. Section 5 discusses selected suitable enrollment Section 3. Section 5 discusses selected suitable enrollment
protocols and options applicable. protocols and applicable options.
An abstract overview of the BRSKI-AE protocol can be found at An abstract overview of the BRSKI-AE protocol can be found in the
[BRSKI-AE-OVERVIEW]. graphics on slide 4 of [BRSKI-AE-overview].
4.2.1. Pledge - Registrar Discovery 4.2.1. Pledge - Registrar Discovery
Discovery as specified in BRSKI [RFC8995], Section 4 does not support Discovery as specified in [RFC8995], Section 4 does not support the
the discovery of registrars with enhanced feature sets. A pledge discovery of registrars with enhanced feature sets. A pledge cannot
cannot find out in this way whether discovered registrars support the find out in this way whether discovered registrars support the
certificate enrollment protocol it expects, such as CMP. certificate enrollment protocol it expects, such as CMP.
As a more general solution, the BRSKI discovery mechanism can be As a more general solution, the BRSKI discovery mechanism can be
extended to provide up-front information on the capabilities of extended to provide up-front information on the capabilities of
registrars. For further discussion, see [BRSKI-DISCOVERY]. registrars. For further discussion, see [BRSKI-discovery].
In the absence of such a generally applicable solution, BRSKI-AE In the absence of such a generally applicable solution, BRSKI-AE
deployments may use their particular way of doing discovery. deployments may use their particular way of doing discovery.
Section 5.1 defines a minimalist approach that MAY be used for CMP. Section 5.1 defines a minimalist approach that MAY be used for CMP.
4.2.2. Pledge - Registrar - MASA Voucher Exchange 4.2.2. Pledge - Registrar - MASA Voucher Exchange
The voucher exchange is performed as specified in [RFC8995]. The voucher exchange is performed as specified in [RFC8995].
4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry 4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry
The voucher status telemetry is performed as specified in [RFC8995], The voucher status telemetry is performed as specified in [RFC8995],
Section 5.7. Section 5.7.
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment 4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
This replaces the EST integration for PKI bootstrapping described in The specification in this section replaces the EST integration for
[RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the PKI bootstrapping described in [RFC8995], Section 5.9 (while
final phase; see below). [RFC8995], Section 5.9.4 remains as the final phase; see below).
The certificate enrollment phase may involve the transmission of The certificate enrollment phase may involve the transmission of
several messages. Details can depend on the application scenario, several messages. Details can depend on the application scenario,
the employed enrollment protocol, and other factors. the employed enrollment protocol, and other factors.
The only message exchange REQUIRED is for the actual certification The only message exchange REQUIRED is for the actual certification
request and response. Further message exchanges MAY be performed as request and response. Further message exchanges MAY be performed as
needed. needed.
Note: The message exchanges marked OPTIONAL in Figure 2 below cover | Note: The message exchanges marked OPTIONAL in Figure 2 below
all those supported by the use of EST in BRSKI. The last OPTIONAL | cover all those supported by the use of EST in BRSKI. The last
one, namely certificate confirmation, is not supported by EST but by | OPTIONAL one, namely certificate confirmation, is not supported
CMP and other enrollment protocols. | by EST but by CMP and other enrollment protocols.
+------+ +---------+ +--------+ +------+ +---------+ +--------+
|Pledge| |Domain | |Operator| |Pledge| |Domain | |Operator|
| | |Registrar| |RA/CA | | | |Registrar| |RA/CA |
| | |(JRC) | |(PKI) | | | |(JRC) | |(PKI) |
+------+ +---------+ +--------+ +------+ +---------+ +--------+
| | | | | |
|[OPTIONAL request of CA certificates]| | |[OPTIONAL request of CA certificates]| |
|------- CA Certs Request (1) ------->| | |------- CA Certs Request (1) ------->| |
| | [OPTIONAL forwarding] | | | [OPTIONAL forwarding] |
skipping to change at line 760 skipping to change at line 773
| |<-- PKI Confirm -----------| | |<-- PKI Confirm -----------|
|<------ PKI/Registrar Confirm (8) ---| | |<------ PKI/Registrar Confirm (8) ---| |
Figure 2: Certificate Enrollment Message Flow Figure 2: Certificate Enrollment Message Flow
It may be noted that connections between the registrar and the PKI It may be noted that connections between the registrar and the PKI
components of the operator (RA, CA, etc.) may be intermittent or components of the operator (RA, CA, etc.) may be intermittent or
offline. Messages should be sent as soon as sufficient transfer offline. Messages should be sent as soon as sufficient transfer
capacity is available. capacity is available.
The label [OPTIONAL forwarding] in Figure 2 means that on receiving a The label '[OPTIONAL forwarding]' in Figure 2 means that on receiving
request message of the given type from a pledge, the registrar MAY a request message of the given type from a pledge, the registrar MAY
answer the request directly. In this case, it MUST authenticate its answer the request directly. In this case, it MUST authenticate its
responses with the same credentials as used for authenticating itself responses with the same credentials as used for authenticating itself
at the TLS level for the voucher exchange. Otherwise, the registrar at the TLS level for the voucher exchange. Otherwise, the registrar
MUST forward the request to the RA and forward any resulting response MUST forward the request to the RA and forward any resulting response
back to the pledge. back to the pledge.
The decision of whether to forward a request or to answer it directly The decision of whether to forward a request or to answer it directly
can depend on various static and dynamic factors. They include the can depend on various static and dynamic factors. They include the
application scenario, the capabilities of the registrar and of the application scenario, the capabilities of the registrar, the
local RA possibly co-located with the registrar, the enrollment capabilities of the local RA possibly co-located with the registrar,
protocol being used, and the specific contents of the request. the enrollment protocol being used, and the specific contents of the
request.
Note that there are several options for how the registrar could be Note that there are several options for how the registrar could be
able to directly answer requests for CA certificates or for able to directly answer requests for CA certificates or for
certification request attributes. It could cache responses obtained certification request attributes. It could cache responses obtained
from the domain PKI and later use their contents for responding to from the domain PKI and later use their contents for responding to
requests asking for the same data. The contents could also be requests asking for the same data. The contents could also be
explicitly provisioned at the registrar. explicitly provisioned at the registrar.
Further note that certification requests typically need to be handled Further note that certification requests typically need to be handled
by the backend PKI, but the registrar can answer them directly with by the backend PKI, but the registrar can answer them directly with
skipping to change at line 814 skipping to change at line 828
occurs without local administrative configuration of the pledge. occurs without local administrative configuration of the pledge.
Nevertheless, there are cases in which the pledge may also include Nevertheless, there are cases in which the pledge may also include
additional attributes that are specific to the target domain in additional attributes that are specific to the target domain in
the Certification Request (5). To get these attributes in the Certification Request (5). To get these attributes in
advance, the attribute request may be used. advance, the attribute request may be used.
* Attribute Response (4): This MUST contain the attributes requested * Attribute Response (4): This MUST contain the attributes requested
in (3) to be included in the subsequent Certification Request (5). in (3) to be included in the subsequent Certification Request (5).
For example, [RFC8994], Section 6.11.7.2 specifies how the For example, [RFC8994], Section 6.11.7.2 specifies how the
attribute request is used to signal to the pledge the acp-node- attribute request is used to signal to the pledge the 'acp-node-
name field required for enrollment into an Autonomic Control Plane name' field required for enrollment into an Autonomic Control
(ACP) domain. Plane (ACP) domain.
* Certification Request (5): This MUST contain the authenticated * Certification Request (5): This MUST contain the authenticated
self-contained object ensuring both the proof of possession of the self-contained object ensuring both the proof of possession of the
corresponding private key and the proof of identity of the corresponding private key and the proof of identity of the
requester. requester.
* Certification Response (6): On success, this MUST contain the * Certification Response (6): On success, this MUST contain the
requested certificate and MAY include further information, like requested certificate and MAY include further information, like
certificates of intermediate CAs and any additional trust anchors. certificates of intermediate CAs and any additional trust anchors.
skipping to change at line 841 skipping to change at line 855
successfully enrolled and fits its needs. successfully enrolled and fits its needs.
* PKI/Registrar Confirm (8): This is an acknowledgment by the PKI * PKI/Registrar Confirm (8): This is an acknowledgment by the PKI
that MUST be sent on reception of the Certificate Confirm. that MUST be sent on reception of the Certificate Confirm.
The generic messages described above may be implemented using any The generic messages described above may be implemented using any
certificate enrollment protocol that supports authenticated self- certificate enrollment protocol that supports authenticated self-
contained objects for the certification request as described in contained objects for the certification request as described in
Section 3. Examples are available in Section 5. Section 3. Examples are available in Section 5.
Note that the optional certificate confirmation by the pledge to the | Note that the optional certificate confirmation by the pledge
PKI described above is independent of the mandatory enrollment status | to the PKI described above is independent of the mandatory
telemetry done between the pledge and the registrar in the final | enrollment status telemetry done between the pledge and the
phase of BRSKI-AE, which is described next. | registrar in the final phase of BRSKI-AE, which is described
| next.
4.2.5. Pledge - Registrar Enrollment Status Telemetry 4.2.5. Pledge - Registrar Enrollment Status Telemetry
The enrollment status telemetry is performed as specified in The enrollment status telemetry is performed as specified in
[RFC8995], Section 5.9.4. [RFC8995], Section 5.9.4.
In BRSKI, this is described as part of the certificate enrollment In [RFC8995], this is described as part of the certificate enrollment
step, but due to the generalization of the enrollment protocol step, but due to the generalization of the enrollment protocol
described in this document, it is regarded as a separate phase here. described in this document, it is regarded as a separate phase here.
4.3. Enhancements to the Endpoint Addressing Scheme of BRSKI 4.3. Enhancements to the Endpoint Addressing Scheme of BRSKI
BRSKI-AE extends the addressing scheme outlined in [RFC8995], BRSKI-AE extends the addressing scheme outlined in [RFC8995],
Section 5 to support alternative enrollment protocols that utilize Section 5 to support alternative enrollment protocols that utilize
authenticated, self-contained objects for certification requests authenticated, self-contained objects for certification requests
(also see Section 5). These extensions are designed to be compatible (also see Section 5). These extensions are designed to be compatible
with existing Registration Authorities (RAs) and Certification with existing Registration Authorities (RAs) and Certification
Authorities (CAs) that already support such enrollment protocols, Authorities (CAs) that already support such enrollment protocols,
enabling their use without requiring any modifications. enabling their use without requiring any modifications.
The addressing scheme in BRSKI for certification requests, related CA The addressing scheme in [RFC8995] for certification requests,
certificates, and CSR attributes retrieval functions uses the related CA certificates, and CSR attributes retrieval functions uses
definition from EST [RFC7030]. An example of simple enrollment is: the definition from EST [RFC7030]. An example of simple enrollment
"/.well-known/est/simpleenroll". This approach is generalized to the is: "/.well-known/est/simpleenroll". This approach is generalized to
following notation: "/.well-known/<enrollment-protocol>/<request>" in the following notation: "/.well-known/<enrollment-
which <enrollment-protocol> refers to a certificate enrollment protocol>/<request>" in which "<enrollment-protocol>" refers to a
protocol. Note that here, enrollment is considered a message certificate enrollment protocol. Note that here, enrollment is
sequence that contains at least a certification request and a considered a message sequence that contains at least a certification
certification response. The following conventions are used to request and a certification response. The following conventions are
provide maximal compatibility with BRSKI: used to provide maximal compatibility with BRSKI:
* <enrollment-protocol>: This MUST reference the protocol being * "<enrollment-protocol>": This MUST reference the protocol being
used. Existing values include 'est' [RFC7030] as in BRSKI and used. Existing values include 'est' [RFC7030] as in [RFC8995] and
'cmp' as in [RFC9483] and Section 5.1 below. Values for other 'cmp' as in [RFC9483] and Section 5.1 below. Values for other
existing protocols such as CMC and SCEP, as well as newly defined existing protocols such as CMC and SCEP, as well as newly defined
protocols, are outside the scope of this document. For use of the protocols, are outside the scope of this document. For use of the
<enrollment-protocol> and <request> URI components, they would "<enrollment-protocol>" and "<request>" URI components, they would
need to be specified in a suitable RFC and placed into the "Well- need to be specified in a suitable RFC and placed into the "Well-
Known URIs" registry, just as EST in [RFC7030]. Known URIs" registry, just as EST in [RFC7030].
* <request>: If present, this path component MUST describe the * "<request>": If present, this path component MUST describe the
operation requested depending on the enrollment protocol being operation requested depending on the enrollment protocol being
used. Enrollment protocols are expected to define their request used. Enrollment protocols are expected to define their request
endpoints, as is done by existing protocols (also see Section 5). endpoints, as is done by existing protocols (also see Section 5).
Well-known URIs for various endpoints on the domain registrar are Well-known URIs for various endpoints on the domain registrar are
already defined as part of the base BRSKI specification or indirectly already defined as part of the base BRSKI specification or indirectly
by EST. In addition, alternative enrollment endpoints MAY be by EST. In addition, alternative enrollment endpoints MAY be
supported by the registrar. supported by the registrar.
A pledge SHOULD use the endpoints defined for the enrollment A pledge SHOULD use the endpoints defined for the enrollment
skipping to change at line 913 skipping to change at line 928
even if the registrar supports the intended protocol and operation. even if the registrar supports the intended protocol and operation.
The following list of endpoints provides an illustrative example of a The following list of endpoints provides an illustrative example of a
domain registrar supporting several options for EST as well as for domain registrar supporting several options for EST as well as for
CMP to be used in BRSKI-AE. The listing contains the supported CMP to be used in BRSKI-AE. The listing contains the supported
endpoints to which the pledge may connect for bootstrapping. This endpoints to which the pledge may connect for bootstrapping. This
includes the voucher handling as well as the enrollment endpoints. includes the voucher handling as well as the enrollment endpoints.
The CMP-related enrollment endpoints are defined as well-known URIs The CMP-related enrollment endpoints are defined as well-known URIs
in CMP Updates [RFC9480] and the Lightweight CMP Profile [RFC9483]. in CMP Updates [RFC9480] and the Lightweight CMP Profile [RFC9483].
/.well-known/brski/voucherrequest * /.well-known/brski/voucherrequest
/.well-known/brski/voucher_status
/.well-known/brski/enrollstatus * /.well-known/brski/voucher_status
/.well-known/est/cacerts
/.well-known/est/csrattrs * /.well-known/brski/enrollstatus
/.well-known/est/fullcmc
/.well-known/cmp/getcacerts * /.well-known/est/cacerts
/.well-known/cmp/getcertreqtemplate
/.well-known/cmp/initialization * /.well-known/est/csrattrs
/.well-known/cmp/pkcs10
* /.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 5. Instantiation with Existing Enrollment Protocols
This section maps the generic requirements to support proof of This section maps the generic requirements to support proof of
possession and proof of identity to selected existing certificate possession and proof of identity to selected existing certificate
enrollment protocols and specifies further aspects of using such enrollment protocols and specifies further aspects of using such
enrollment protocols in BRSKI-AE. enrollment protocols in BRSKI-AE.
5.1. BRSKI-CMP: BRSKI-AE Instantiated with CMP 5.1. BRSKI-CMP: BRSKI-AE Instantiated with CMP
In this document, references to CMP follow the Lightweight CMP In this document, references to CMP follow the Lightweight CMP
Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the Profile (LCMPP) from [RFC9483] rather than [RFC4210] and [RFC9480],
subset of CMP defined in LCMPP sufficiently meets the required as the subset of CMP defined in the LCMPP sufficiently meets the
functionality. required functionality.
Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP. The Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP. The
following specific requirements apply (refer to Figure 2): following specific requirements apply (refer to Figure 2):
* The validation of server response messages performed by the CMP * The validation of server response messages performed by the CMP
client within the pledge MUST be based on the trust anchor client within the pledge MUST be based on the trust anchor
established beforehand via the BRSKI voucher, i.e., on the pinned- established beforehand via the BRSKI voucher, i.e., on the pinned-
domain-cert. domain-cert.
Note that the integrity and authenticity checks on the RA/CA by Note that the integrity and authenticity checks on the RA/CA by
skipping to change at line 962 skipping to change at line 986
in [RFC9483], Section 4.3.1. in [RFC9483], Section 4.3.1.
* Attribute Request (3) and Response (4): Requesting certification * Attribute Request (3) and Response (4): Requesting certification
request attributes is OPTIONAL. If supported, it SHALL be request attributes is OPTIONAL. If supported, it SHALL be
implemented as specified in [RFC9483], Section 4.3.3. implemented as specified in [RFC9483], Section 4.3.3.
Alternatively, the registrar MAY modify the requested certificate Alternatively, the registrar MAY modify the requested certificate
contents as specified in [RFC9483], Section 5.2.3.2. contents as specified in [RFC9483], Section 5.2.3.2.
* Certification Request (5) and Response (6): Certificates SHALL be * Certification Request (5) and Response (6): Certificates SHALL be
requested and provided as specified in LCMPP [RFC9483], requested and provided as specified in the LCMPP from [RFC9483],
Section 4.1.1 (based on CRMF) or [RFC9483], Section 4.1.4 (based Section 4.1.1 (based on CRMF) or [RFC9483], Section 4.1.4 (based
on PKCS #10). on PKCS #10).
Proof of possession SHALL be provided in a manner suitable for the Proof of possession SHALL be provided in a manner suitable for the
key type. Proof of identity SHALL be provided by signature-based key type. Proof of identity SHALL be provided by signature-based
protection of the certification request message as outlined in protection of the certification request message as outlined in
[RFC9483], Section 3.2 using the IDevID secret. [RFC9483], Section 3.2 using the IDevID secret.
When the registrar forwards a certification request from the When the registrar forwards a certification request from the
pledge to a backend RA/CA, it is RECOMMENDED that the registrar pledge to a backend RA/CA, it is RECOMMENDED that the registrar
wraps the original certification request in a nested message wraps the original certification request in a nested message
signed with its own credentials, as described in [RFC9483], signed with its own credentials, as described in [RFC9483],
Section 5.2.2.1. This approach explicitly conveys the registrar's Section 5.2.2.1. This approach explicitly conveys the registrar's
consent to the RA while retaining the original certification consent to the RA while retaining the original certification
request with the proof of origin provided by the pledge's request with the proof of origin provided by the pledge's
signature. signature.
If additional trust anchors beyond the pinned-domain-cert need to If additional trust anchors beyond the pinned-domain-cert need to
be conveyed to the pledge, this SHOULD be done in the caPubs field be conveyed to the pledge, this SHOULD be done in the 'caPubs'
of the certification response rather than through a CA Certs field of the certification response rather than through a CA Certs
Response. Response.
* Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit * Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit
confirmation of new certificates to the RA/CA MAY be used as confirmation of new certificates to the RA/CA MAY be used as
specified in [RFC9483], Section 4.1.1. specified in [RFC9483], Section 4.1.1.
Note that independent of the certificate confirmation within CMP, | Note that independent of the certificate confirmation within
enrollment status telemetry with the registrar at the BRSKI level | CMP, enrollment status telemetry with the registrar at the
will be performed as described in [RFC8995], Section 5.9.4. | 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 * If delayed delivery of CMP messages is needed (e.g., to support
enrollment over an asynchronous channel), it SHALL be performed as enrollment over an asynchronous channel), it SHALL be performed as
specified in Sections 4.4 and 5.1.2 of [RFC9483]. specified in Sections 4.4 and 5.1.2 of [RFC9483].
The mechanisms for exchanging messages between the registrar and The mechanisms for exchanging messages between the registrar and
backend PKI components (i.e., RA and/or CA) are outside the scope of backend PKI components (i.e., RA and/or CA) are outside the scope of
this document. CMP's independence from the message transfer this document. CMP's independence from the message transfer
mechanism allows for flexibility in choosing the appropriate exchange mechanism allows for flexibility in choosing the appropriate exchange
method based on the application scenario. For the applicable method based on the application scenario. For the applicable
skipping to change at line 1013 skipping to change at line 1038
Further guidance can be found in [RFC9483], Section 6. Further guidance can be found in [RFC9483], Section 6.
BRSKI-AE with CMP can also be combined with Constrained BRSKI BRSKI-AE with CMP can also be combined with Constrained BRSKI
[cBRSKI], using CoAP for enrollment message transport as described by [cBRSKI], using CoAP for enrollment message transport as described by
CoAP Transfer for CMP [RFC9482]. In such scenarios, the EST-specific CoAP Transfer for CMP [RFC9482]. In such scenarios, the EST-specific
parts of [cBRSKI] do not apply. parts of [cBRSKI] do not apply.
For BRSKI-AE scenarios where a general solution for discovering For BRSKI-AE scenarios where a general solution for discovering
registrars with CMP support is not available (cf. Section 4.2.1), the registrars with CMP support is not available (cf. Section 4.2.1), the
following minimalist approach MAY be used: Perform discovery as following minimalist approach MAY be used: Perform discovery as
defined in BRSKI [RFC8995], Appendix B, but use the service name defined in [RFC8995], Appendix B, but use the service name "brski-
"brski-reg-cmp" (as defined in Section 6) instead of "brski- reg-cmp" (as defined in Section 6) instead of "brski-registrar" (as
registrar" (as defined in [RFC8995], Section 8.6). Note that this defined in [RFC8995], Section 8.6). Note that this approach does not
approach does not support join proxies. support join proxies.
5.2. Support of Other Enrollment Protocols 5.2. Support of Other Enrollment Protocols
Further instantiations of BRSKI-AE can be done. They are left for Further instantiations of BRSKI-AE can be done. They are left for
future work. future work.
In particular, CMC [RFC5272] (using its in-band source authentication In particular, CMC [RFC5272] (using its in-band source authentication
options) and SCEP [RFC8894] (using its 'renewal' option) could be options) and SCEP [RFC8894] (using its 'renewal' option) could be
used. used.
skipping to change at line 1047 skipping to change at line 1072
Service Name: brski-reg-cmp Service Name: brski-reg-cmp
Transport Protocol(s): tcp Transport Protocol(s): tcp
Description: Bootstrapping Remote Secure Key Infrastructure Description: Bootstrapping Remote Secure Key Infrastructure
registrar with CMP capabilities according to the Lightweight CMP registrar with CMP capabilities according to the Lightweight CMP
Profile (LCMPP) [RFC9483] Profile (LCMPP) [RFC9483]
Assignee: IESG iesg@ietf.org (mailto:iesg@ietf.org) Assignee: IESG iesg@ietf.org (mailto:iesg@ietf.org)
Contact: IETF chair@ietf.org (mailto:chair@ietf.org) Contact: IETF chair@ietf.org (mailto:chair@ietf.org)
Reference: RFC 9733 Reference: RFC 9733
Note: We chose the suffix "cmp" here rather than some other | Note: We chose the suffix "cmp" here rather than some other
abbreviation like "lcmpp" mainly because this document defines the | abbreviation like "lcmpp" mainly because this document defines
normative CMP instantiation of BRSKI-AE, which implies adherence to | the normative CMP instantiation of BRSKI-AE, which implies
LCMPP is necessary and sufficient. | adherence to the LCMPP is necessary and sufficient.
7. Security Considerations 7. Security Considerations
The security considerations laid out in BRSKI [RFC8995], Section 11 The security considerations laid out in [RFC8995], Section 11 apply
apply to the discovery and voucher exchange as well as for the status to the discovery and voucher exchange as well as for the status
exchange information. exchange information.
In particular, even if the registrar delegates part or all of its RA In particular, even if the registrar delegates part or all of its RA
role during certificate enrollment to a separate system, it still role during certificate enrollment to a separate system, it still
must be made sure that the registrar takes part in the decision on 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 accepting or declining a request to join the domain, as required in
[RFC8995], Section 5.3. As this also pertains to obtaining a valid [RFC8995], Section 5.3. As this also pertains to obtaining a valid
domain-specific certificate, it must be made sure that a pledge domain-specific certificate, it must be made sure that a pledge
cannot circumvent the registrar in the decision of whether it is cannot circumvent the registrar in the decision of whether it is
granted an LDevID certificate by the CA. There are various ways to granted an LDevID certificate by the CA. There are various ways to
skipping to change at line 1082 skipping to change at line 1107
pledge identity in a database; pledge identity in a database;
* the registrar providing its consent using an extra message that is * the registrar providing its consent using an extra message that is
transferred on the same channel as the enrollment messages, transferred on the same channel as the enrollment messages,
possibly in a TLS tunnel; and possibly in a TLS tunnel; and
* the registrar explicitly stating its consent by signing the * the registrar explicitly stating its consent by signing the
authenticated self-contained certificate enrollment request authenticated self-contained certificate enrollment request
message in addition to the pledge. message in addition to the pledge.
Note: If EST was used, the registrar could give implicit consent on a | Note: If EST was used, the registrar could give implicit
certification request by forwarding the request to a PKI entity using | consent on a certification request by forwarding the request to
a connection authenticated with a certificate containing an id-kp- | a PKI entity using a connection authenticated with a
cmcRA extension. | certificate containing an id-kp-cmcRA extension.
When CMP is used, the security considerations laid out in LCMPP When CMP is used, the security considerations laid out in the LCMPP
[RFC9483] apply. from [RFC9483] apply.
8. Privacy Considerations 8. Privacy Considerations
The privacy considerations laid out in BRSKI [RFC8995], Section 10 The privacy considerations laid out in [RFC8995], Section 10 apply as
apply as well. well.
Note that CMP messages themselves are not encrypted. This may give Note that CMP messages themselves are not encrypted. This may give
eavesdroppers insight into which devices are bootstrapped into the eavesdroppers insight into which devices are bootstrapped into the
domain. In turn, this might also be used to selectively block the domain. In turn, this might also be used to selectively block the
enrollment of certain devices. enrollment of certain devices.
To prevent such issues, the underlying message transport channel can To prevent such issues, the underlying message transport channel can
be encrypted. This is already provided by TLS between the pledge and be encrypted. This is already provided by TLS between the pledge and
the registrar, and for the onward exchange with backend systems, the registrar, and for the onward exchange with backend systems,
encryption may need to be added. encryption may need to be added.
skipping to change at line 1142 skipping to change at line 1167
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>. May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight [RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", RFC 9483, Certificate Management Protocol (CMP) Profile", RFC 9483,
DOI 10.17487/RFC9483, November 2023, DOI 10.17487/RFC9483, November 2023,
<https://www.rfc-editor.org/info/rfc9483>. <https://www.rfc-editor.org/info/rfc9483>.
9.2. Informative References 9.2. Informative References
[BRSKI-AE-OVERVIEW] [BRSKI-AE-overview]
von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "Update von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "Update
on BRSKI-AE: Alternative Enrollment Protocols in BRSKI", on BRSKI-AE: Alternative Enrollment Protocols in BRSKI",
IETF 116 - ANIMA Working Group Presentation, March 2023, IETF 116 - ANIMA Working Group Presentation, March 2023,
<https://datatracker.ietf.org/meeting/116/materials/ <https://datatracker.ietf.org/meeting/116/materials/
slides-116-anima-update-on-brski-ae-alternative- slides-116-anima-update-on-brski-ae-alternative-
enrollment-protocols-in-brski-00>. enrollment-protocols-in-brski-00>.
[BRSKI-DISCOVERY] [BRSKI-discovery]
Eckert, T. T. and E. Dijk, "BRSKI discovery and Eckert, T. T. and E. Dijk, "BRSKI discovery and
variations", Work in Progress, Internet-Draft, draft-ietf- variations", Work in Progress, Internet-Draft, draft-ietf-
anima-brski-discovery-05, 21 October 2024, anima-brski-discovery-05, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima- <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
brski-discovery-05>. brski-discovery-05>.
[cBRSKI] Richardson, M., Van der Stok, P., Kampanakis, P., and E. [cBRSKI] Richardson, M., Van der Stok, P., Kampanakis, P., and E.
Dijk, "Constrained Bootstrapping Remote Secure Key Dijk, "Constrained Bootstrapping Remote Secure Key
Infrastructure (cBRSKI)", Work in Progress, Internet- Infrastructure (cBRSKI)", Work in Progress, Internet-
Draft, draft-ietf-anima-constrained-voucher-26, 8 January Draft, draft-ietf-anima-constrained-voucher-26, 8 January
2025, <https://datatracker.ietf.org/doc/html/draft-ietf- 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
anima-constrained-voucher-26>. anima-constrained-voucher-26>.
[IEC-62351-9] [IEC-62351-9]
International Electrotechnical Commission, "Power systems International Electrotechnical Commission, "Power systems
management and associated information exchange - Data and management and associated information exchange - Data and
communications security - Part 9: Cyber security key communications security - Part 9: Cyber security key
management for power system equipment", IEC 62351-9:2017, management for power system equipment", IEC 62351-9:2023,
May 2017, <https://webstore.iec.ch/en/publication/30287>. June 2023, <https://webstore.iec.ch/en/publication/66864>.
[ISO-IEC-15118-2] [ISO-IEC-15118-2]
International Organization for Standardization, "Road International Organization for Standardization, "Road
vehicles - Vehicle-to-Grid Communication Interface - Part vehicles - Vehicle-to-Grid Communication Interface - Part
2: Network and application protocol requirements", 2: Network and application protocol requirements",
ISO 15118-2:2014, April 2014, ISO 15118-2:2014, April 2014,
<https://www.iso.org/standard/55366.html>. <https://www.iso.org/standard/55366.html>.
[NERC-CIP-005-5] [NERC-CIP-005-5]
North American Electric Reliability Council, "Cyber North American Electric Reliability Council, "Cyber
skipping to change at line 1256 skipping to change at line 1281
<https://www.rfc-editor.org/info/rfc9480>. <https://www.rfc-editor.org/info/rfc9480>.
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained [RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
Application Protocol (CoAP) Transfer for the Certificate Application Protocol (CoAP) Transfer for the Certificate
Management Protocol", RFC 9482, DOI 10.17487/RFC9482, Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
November 2023, <https://www.rfc-editor.org/info/rfc9482>. November 2023, <https://www.rfc-editor.org/info/rfc9482>.
[UNISIG-Subset-137] [UNISIG-Subset-137]
UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset- UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
137, Version 1.0.0, December 2015, 137, Version 1.0.0, December 2015,
<https://www.era.europa.eu/sites/default/files/filesystem/ <https://www.era.europa.eu/system/files/2023-01/
ertms/ccs_tsi_annex_a_-_mandatory_specifications/ sos3_index083_-_subset-137_v100.pdf>.
set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
_subset-137_v100.pdf>.
Appendix A. Application Examples Appendix A. Application Examples
This informative annex provides some details about application This informative annex provides some details about application
examples. examples.
A.1. Rolling Stock A.1. Rolling Stock
Rolling stock or railroad cars contain a variety of sensors, Rolling stock or railroad cars contain a variety of sensors,
actuators, and controllers. These communicate within the railroad actuators, and controllers. These communicate within the railroad
car but also exchange information between railroad cars, forming a car but also exchange information with other railroad cars of the
train with track-side equipment and/or possibly with backend systems. same train and with track-side equipment and/or possibly with backend
These devices are typically unaware of backend system connectivity. systems. These devices are typically unaware of backend system
Enrolling certificates may be done during maintenance cycles of the connectivity. Enrolling certificates may be done during maintenance
railroad car but can already be prepared during operation. Such cycles of the railroad car but can already be prepared during
asynchronous enrollment will include generating certification operation. Such asynchronous enrollment will include generating
requests, which are collected and later forwarded for processing certification requests, which are collected and later forwarded for
whenever the railroad car gets connectivity with the backend PKI of processing whenever the railroad car gets connectivity with the
the operator. The authorization of the certification request is then backend PKI of the operator. The authorization of the certification
done based on the operator's asset/inventory information in the request is then done based on the operator's asset/inventory
backend. information in the backend.
UNISIG has included a CMP profile for the enrollment of TLS client UNISIG has included a CMP profile for the enrollment of TLS client
and server X.509 certificates of on-board and track-side components and server X.509 certificates of on-board and track-side components
in the Subset-137, which specifies the ETRAM/ETCS online key in the Subset-137, which specifies the ETRAM/ETCS online key
management for train control systems [UNISIG-Subset-137]. management for train control systems [UNISIG-Subset-137].
A.2. Building Automation A.2. Building Automation
In building automation scenarios, a detached building or the basement In building automation scenarios, a detached building or the basement
of a building may be equipped with sensors, actuators, and of a building may be equipped with sensors, actuators, and
skipping to change at line 1351 skipping to change at line 1374
charging operations and maintain the charging point itself. This charging operations and maintain the charging point itself. This
means that the certificate management needs to be handled in-band of means that the certificate management needs to be handled in-band of
OCPP. This requires the ability to encapsulate the certificate OCPP. This requires the ability to encapsulate the certificate
management messages in a transport-independent way. Authenticated management messages in a transport-independent way. Authenticated
self-containment will support this by allowing the transport without self-containment will support this by allowing the transport without
a separate enrollment protocol, binding the messages to the identity a separate enrollment protocol, binding the messages to the identity
of the communicating endpoints. of the communicating endpoints.
A.5. Infrastructure Isolation Policy A.5. Infrastructure Isolation Policy
This refers to any case in which network infrastructure is normally The approach described in this section refers to any case in which
isolated from the Internet as a matter of policy, most likely for network infrastructure is normally isolated from the Internet as a
security reasons. In such a case, limited access to external PKI matter of policy, most likely for security reasons. In such a case,
services will be allowed in carefully controlled short periods of limited access to external PKI services will be allowed in carefully
time (for example, when a batch of new devices is deployed) and controlled short periods of time (for example, when a batch of new
forbidden or prevented at other times. devices is deployed) and forbidden or prevented at other times.
A.6. Sites with Insufficient Levels of Operational Security A.6. Sites with Insufficient Levels of Operational Security
The RA performing (at least part of) the authorization of a The RA performing (at least part of) the authorization of a
certification request is a critical PKI component and therefore certification request is a critical PKI component and therefore
requires higher operational security than components utilizing the requires higher operational security than components utilizing the
issued certificates for their security features. CAs may also demand issued certificates for their security features. CAs may also demand
higher security in the registration procedures from RAs, which domain higher security in the registration procedures from RAs, which domain
registrars with co-located RAs may not be able to fulfill. In registrars with co-located RAs may not be able to fulfill. In
particular, the CA/Browser forum currently increases the security particular, the CA/Browser forum currently increases the security
 End of changes. 59 change blocks. 
199 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.48.