| RFC 9733 | BRSKI-AE | February 2025 |
| von Oheimb, et al. | Standards Track | [Page] |
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.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9733.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] is typically used with Enrollment over Secure Transport (EST) [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.¶
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.¶
This specification carries over the main characteristics of BRSKI, namely:¶
The pledge is assumed to have received its Initial Device Identifier (IDevID) [IEEE_802.1AR-2018] credentials during its manufacturing. It uses them to authenticate itself to the Manufacturer Authorized Signing Authority (MASA) [RFC8995] and the registrar (which is the access point of the target domain) and to possibly further components of the domain where it will be operated.¶
The pledge first obtains via the voucher exchange [RFC8366] a trust anchor for authenticating entities in the domain such as the domain registrar.¶
The pledge then obtains its Local Device Identifier (LDevID) [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.¶
The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID certificate enrollment through the use of an alternative protocol to EST that:¶
supports end-to-end authentication over multiple transport hops and¶
facilitates secure message exchanges over any type of transfer mechanism, including asynchronous delivery.¶
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.¶
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.¶
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.¶
It may be important to note that BRSKI [RFC8995] specifies the use of HTTP over TLS, but variations such as Constrained BRSKI [cBRSKI], 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.¶
This specification, together with its referenced documents, is sufficient to support BRSKI with the Certificate Management Protocol (CMP) [RFC9480] as profiled in the Lightweight CMP Profile (LCMPP) [RFC9483]. Integrating BRSKI with an enrollment protocol or profile other than 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.¶
BRSKI-AE is designed for use in scenarios such as the following:¶
When pledges and/or the target domain leverage an existing certificate enrollment protocol other than EST, such as CMP.¶
When the application context precludes the use of EST for certificate enrollment due to factors such as when:¶
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.¶
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.¶
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 [RFC6955]. EST, which relies on CSRs in PKCS #10 format [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.¶
The pledge implementation employs security libraries that do not support EST or uses a TLS library lacking support for the "tls-unique" value [RFC5929], which EST requires for the strong binding of source authentication.¶
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.¶
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.¶
Bootstrapping may be managed in various ways depending on the application domain. Appendix A provides illustrative examples from different industrial control system environments and operational contexts that motivate the support of alternative enrollment protocols.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document relies on the terminology defined in [RFC8995], [RFC5280], and [IEEE_802.1AR-2018], which is partly repeated here. Several further terms are also described here.¶
To be independent of the terminology of a specific enrollment protocol, this document utilizes generic terminology regarding PKI management operations.¶
Based on the intended target scenarios described in Section 1.1 and the application examples described in Appendix A, the following requirements are derived to support authenticated self-contained objects as containers carrying certification requests.¶
The following properties are required for a certification request:¶
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 [RFC4210], Section 4.3.¶
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.¶
The remainder of this section gives a non-exhaustive list of solution examples, based on existing technology described in IETF documents.¶
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:¶
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.¶
Binding a Certificate Signing Request (CSR) to an existing authenticated credential (the BRSKI context, the IDevID certificate) enables proof of origin, which in turn supports an authorization decision on the CSR.¶
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.¶
This requirement is addressed by existing enrollment protocols in various ways, such as:¶
EST [RFC7030] and its variant EST-coaps [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 [RFC5929] resulting
from the TLS handshake. As this is optionally supported by the
EST "/simpleenroll" 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.¶
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.¶
[RFC7030], Section 2.5
sketches wrapping PKCS #10-formatted CSRs with a Full PKI Request
message sent to the "/fullcmc" 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.¶
The Simple Certificate Enrolment Protocol (SCEP) [RFC8894] supports using a shared secret (passphrase) or an existing certificate to protect CSRs based on SCEP Secure Message Objects using Cryptographic Message Syntax (CMS) wrapping [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.¶
CMP [RFC4210] [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.¶
Certificate Management over CMS (CMC) [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 FullCMCRequest based on CMS [RFC5652] and signed with an existing IDevID secret. Thus, CMC does not rely on the security of the underlying message transfer.¶
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.¶
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 [RFC8995]. This way, authenticated self-contained objects such as those described in Section 3 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.¶
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.¶
The key element of BRSKI-AE is that the authorization of a certification request MUST be performed based on an authenticated self-contained object. The certification request is bound in a self-contained way to a proof of origin based on the IDevID credentials. Consequently, the certification request MAY be transferred using any mechanism or protocol. Authentication and authorization of the certification request can be done by the domain registrar and/or by backend domain components. As mentioned in Section 1.1, these components may be offline or off-site. The registrar and other on-site domain components may have no or only temporary (intermittent) connectivity to them.¶
This leads to generalizations in the placement and enhancements of the logical elements as shown in Figure 1.¶
The architecture overview in Figure 1 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 MAY still do all of these checks (as is the case in BRSKI) or only do part of them.¶
The following list describes the on-site components in the target domain of the pledge shown in Figure 1.¶
Join Proxy: This has the same requirements as in BRSKI (see [RFC8995], Section 4).¶
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:¶
The registrar MUST support at least one certificate enrollment protocol with authenticated self-contained objects for certification requests. To this end, the URI scheme for addressing endpoints at the registrar is generalized (see Section 4.3).¶
Rather than having full RA functionality, the registrar MAY act as a Local Registration Authority (LRA) and delegate part of its involvement in certificate enrollment to a backend RA. In such scenarios, the registrar optionally checks certification requests it receives from pledges and forwards them to the backend RA, which performs the remaining parts of the enrollment request validation and authorization. Note that 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.¶
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.¶
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 Section 7 for details on how this can be achieved.¶
Despite the above generalizations of the enrollment phase, the final step of BRSKI, namely the enrollment status telemetry, is kept as it is.¶
The following list describes the components provided by the vendor or manufacturer outside the target domain.¶
MASA: This has the functionality as described in BRSKI [RFC8995]. The voucher exchange with the MASA via the domain registrar is performed as described in BRSKI.¶
Note: From the definition of the interaction with the MASA in [RFC8995], Section 5 follows that it may be synchronous (using voucher requests with nonces) or asynchronous (using nonceless voucher requests).¶
Ownership Tracker: This is as defined in BRSKI.¶
The following list describes backend target domain components, which may be located on-site or off-site in the target domain.¶
RA: This performs centralized certificate management functions as a public-key infrastructure for the domain operator. As far as not already done 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.¶
CA (also called "domain CA"): This generates domain-specific certificates according to certification requests that have been authenticated and authorized by the registrar and/or an extra RA.¶
Based on the diagram in BRSKI [RFC8995], Section 2.1 and the architectural changes, the original protocol flow is divided into several phases showing commonalities and differences with the original approach as follows.¶
Discovery phase: This is mostly as in step (1) of [RFC8995]. For details, see Section 4.2.1.¶
Identification phase: This is the same as in step (2) of [RFC8995].¶
Voucher exchange phase: This is the same as in steps (3) and (4) of [RFC8995].¶
Voucher status telemetry: This is the same as directly after step (4) in [RFC8995].¶
Certificate enrollment phase: The use of EST in step (5) is changed to employing a certificate enrollment protocol that uses an authenticated self-contained object for requesting the LDevID certificate.¶
For transporting the certificate enrollment request and response messages, the (D)TLS channel established between pledge and registrar is REQUIRED to use. 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.¶
Enrollment status telemetry: This is the final exchange of step (5) of [RFC8995].¶
The behavior of a pledge described in BRSKI [RFC8995], Section 2.1 is kept, with one major exception. After finishing the Imprint step (4), the Enroll step (5) MUST be performed with an enrollment protocol utilizing authenticated self-contained objects, as explained in Section 3. Section 5 discusses selected suitable enrollment protocols and options applicable.¶
An abstract overview of the BRSKI-AE protocol can be found at [BRSKI-AE-OVERVIEW].¶
Discovery as specified in BRSKI [RFC8995], Section 4 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.¶
As a more general solution, the BRSKI discovery mechanism can be extended to provide up-front information on the capabilities of registrars. For further discussion, see [BRSKI-DISCOVERY].¶
In the absence of such a generally applicable solution, BRSKI-AE deployments may use their particular way of doing discovery. Section 5.1 defines a minimalist approach that MAY be used for CMP.¶
The voucher exchange is performed as specified in [RFC8995].¶
The voucher status telemetry is performed as specified in [RFC8995], Section 5.7.¶
This replaces the EST integration for PKI bootstrapping described in [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the final phase; see below).¶
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.¶
The only message exchange REQUIRED is for the actual certification request and response. Further message exchanges MAY be performed as needed.¶
Note: The message exchanges marked OPTIONAL in Figure 2 below cover all those supported by the use of EST in BRSKI. The last OPTIONAL one, namely certificate confirmation, is not supported by EST but by CMP and other enrollment protocols.¶
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.¶
The label [OPTIONAL forwarding] in Figure 2
means that on receiving a request message of the given type from a pledge,
the registrar MAY answer the request directly.
In this case, it MUST authenticate its responses with the same credentials
as used for authenticating itself at the TLS level for the voucher exchange.
Otherwise, the registrar MUST forward the request to the RA
and forward any resulting response back to the pledge.¶
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 and of the local RA possibly co-located with the registrar, the enrollment protocol being used, and the specific contents of the request.¶
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.¶
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.¶
The following list provides an abstract description of the flow depicted in Figure 2.¶
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).¶
CA Certs Response (2): This MUST contain any intermediate CA certificates that the pledge may need to validate certificates and MAY contain the LDevID trust anchor.¶
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.¶
Attribute Response (4): This MUST contain the attributes requested in (3) to be included in the subsequent Certification Request (5).¶
For example, [RFC8994], Section 6.11.7.2 specifies how the attribute request is used to signal to the pledge the acp-node-name field required for enrollment into an Autonomic Control Plane (ACP) domain.¶
Certification Request (5): This MUST 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.¶
Certification Response (6): On success, this MUST contain the requested certificate and MAY include further information, like certificates of intermediate CAs and any additional trust anchors.¶
Certificate Confirm (7): This is an optional confirmation that is sent after the requested certificate has been received and validated. If sent, it MUST contain a positive or negative confirmation by the pledge to the PKI whether the certificate was successfully enrolled and fits its needs.¶
PKI/Registrar Confirm (8): This is an acknowledgment by the PKI that MUST be sent on reception of the Certificate Confirm.¶
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 Section 3. Examples are available in Section 5.¶
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.¶
The enrollment status telemetry is performed as specified in [RFC8995], Section 5.9.4.¶
In BRSKI, 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.¶
BRSKI-AE extends the addressing scheme outlined in [RFC8995], Section 5 to support alternative enrollment protocols that utilize authenticated, self-contained objects for certification requests (also see Section 5). 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.¶
The addressing scheme in BRSKI for certification requests,
related CA certificates, and CSR attributes retrieval functions uses the
definition from EST [RFC7030]. An example of
simple enrollment is: "/.well-known/est/simpleenroll". This
approach is generalized to the following notation:
"/.well-known/<enrollment-protocol>/<request>" in
which <enrollment-protocol> 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:¶
<enrollment-protocol>: This MUST
reference the protocol being used. Existing values include
'est' [RFC7030] as in BRSKI and
'cmp' as in [RFC9483] and Section 5.1 below. Values for other existing
protocols such as CMC and SCEP, as well as newly defined
protocols, are outside the scope of this document. For use of the
<enrollment-protocol> and <request>
URI components, they would need to be specified in a suitable RFC
and placed into the "Well-Known URIs" registry, just as EST in [RFC7030].¶
<request>: If present, this path component
MUST describe the operation requested depending on
the enrollment protocol being used. Enrollment protocols are
expected to define their request endpoints, as is done by existing
protocols (also see Section 5).¶
Well-known URIs for various endpoints on the domain registrar are already defined as part of the base BRSKI specification or indirectly by EST. In addition, alternative enrollment endpoints MAY be supported by the registrar.¶
A pledge SHOULD use the endpoints defined for the enrollment protocol(s) 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.¶
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 [RFC9480] and the Lightweight CMP Profile [RFC9483].¶
/.well-known/brski/voucherrequest /.well-known/brski/voucher_status /.well-known/brski/enrollstatus /.well-known/est/cacerts /.well-known/est/csrattrs /.well-known/est/fullcmc /.well-known/cmp/getcacerts /.well-known/cmp/getcertreqtemplate /.well-known/cmp/initialization /.well-known/cmp/pkcs10¶
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.¶
In this document, references to CMP follow the Lightweight CMP Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the subset of CMP defined in LCMPP sufficiently meets the required functionality.¶
Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP. The following specific requirements apply (refer to Figure 2):¶
The validation of server response messages performed by the CMP client within the pledge MUST be based on the trust anchor established beforehand via the BRSKI voucher, i.e., on the pinned-domain-cert.¶
Note that the integrity and authenticity checks on the RA/CA by the CMP client can be stronger than for EST because they do not need to be performed hop-by-hop but are usually end-to-end.¶
CA Certs Request (1) and Response (2): Requesting CA certificates is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.1.¶
Attribute Request (3) and Response (4): Requesting certification request attributes is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.3.¶
Alternatively, the registrar MAY modify the requested certificate contents as specified in [RFC9483], Section 5.2.3.2.¶
Certification Request (5) and Response (6): Certificates SHALL be requested and provided as specified in LCMPP [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483], Section 4.1.4 (based on PKCS #10).¶
Proof of possession SHALL be provided in a manner suitable for the key type. Proof of identity SHALL be provided by signature-based protection of the certification request message as outlined in [RFC9483], Section 3.2 using the IDevID secret.¶
When the registrar forwards a certification request from the pledge to a backend RA/CA, it is RECOMMENDED that the registrar wraps the original certification request in a nested message signed with its own credentials, as described in [RFC9483], Section 5.2.2.1. This approach explicitly conveys the registrar's consent to the RA while retaining the original certification request with the proof of origin provided by the pledge's signature.¶
If additional trust anchors beyond the pinned-domain-cert need
to be conveyed to the pledge, this SHOULD be done
in the caPubs field of the certification response
rather than through a CA Certs Response.¶
Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit confirmation of new certificates to the RA/CA MAY be used as specified in [RFC9483], Section 4.1.1.¶
Note that independent of the certificate confirmation within CMP, enrollment status telemetry with the registrar at the BRSKI level will be performed as described in [RFC8995], Section 5.9.4.¶
If delayed delivery of CMP messages is needed (e.g., to support enrollment over an asynchronous channel), it SHALL be performed as specified in Sections 4.4 and 5.1.2 of [RFC9483].¶
The mechanisms for exchanging messages between the registrar and backend PKI components (i.e., RA and/or CA) are outside the scope of this document. CMP's independence from the message transfer mechanism allows for flexibility in choosing the appropriate exchange method based on the application scenario. For the applicable security and privacy considerations, refer to Sections 7 and 8. Further guidance can be found in [RFC9483], Section 6.¶
BRSKI-AE with CMP can also be combined with Constrained BRSKI [cBRSKI], using CoAP for enrollment message transport as described by CoAP Transfer for CMP [RFC9482]. In such scenarios, the EST-specific parts of [cBRSKI] do not apply.¶
For BRSKI-AE scenarios where a general solution for discovering
registrars with CMP support is not available (cf. Section 4.2.1), the following minimalist approach
MAY be used: Perform discovery as defined in BRSKI [RFC8995], Appendix B, but use the service
name "brski-reg-cmp" (as defined in Section 6) instead of "brski-registrar" (as
defined in [RFC8995], Section 8.6). Note that this approach does not support join
proxies.¶
Further instantiations of BRSKI-AE can be done. They are left for future work.¶
In particular, CMC [RFC5272] (using its in-band source authentication options) and SCEP [RFC8894] (using its 'renewal' option) could be used.¶
The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might also be used here. For EST-fullCMC, further specification is necessary.¶
IANA has registered the following service name in the "Service Name and Transport Protocol Port Number Registry".¶
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 LCMPP is necessary and sufficient.¶
The security considerations laid out in BRSKI [RFC8995], Section 11 apply to the discovery and voucher exchange as well as for the status exchange information.¶
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 [RFC8995], Section 5.3. 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:¶
implicit consent;¶
the registrar signaling its consent to the RA out-of-band before or during the enrollment phase, for instance, by entering the pledge identity in a database;¶
the registrar providing its consent using an extra message that is transferred on the same channel as the enrollment messages, possibly in a TLS tunnel; and¶
the registrar explicitly stating its consent by signing the authenticated self-contained certificate enrollment request message in addition to the pledge.¶
Note: If EST was used, the registrar could give implicit consent on a certification request by forwarding the request to a PKI entity using a connection authenticated with a certificate containing an id-kp-cmcRA extension.¶
When CMP is used, the security considerations laid out in LCMPP [RFC9483] apply.¶
The privacy considerations laid out in BRSKI [RFC8995], Section 10 apply as well.¶
Note that CMP messages themselves are not encrypted. This may give eavesdroppers insight into which devices are bootstrapped into the domain. In turn, this might also be used to selectively block the enrollment of certain devices.¶
To prevent such issues, the underlying message transport channel can be encrypted. This is already provided by TLS between the pledge and the registrar, and for the onward exchange with backend systems, encryption may need to be added.¶
This informative annex provides some details about application examples.¶
Rolling stock or railroad cars contain a variety of sensors, actuators, and controllers. These communicate within the railroad car but also exchange information between railroad cars, forming a train 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.¶
UNISIG has included a CMP profile for the enrollment of TLS client and server X.509 certificates of on-board and track-side components in the Subset-137, which specifies the ETRAM/ETCS online key management for train control systems [UNISIG-Subset-137].¶
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.¶
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.¶
In electrical substation automation scenarios, a control center typically hosts PKI services to issue certificates for Intelligent Electronic Devices (IEDs) operated in a substation. Communication between the substation and control center is performed through a proxy/gateway/DMZ, which terminates protocol flows. Note that [NERC-CIP-005-5] requires inspection of protocols at the boundary of a security perimeter (in this case, the substation). In addition, security management in substation automation assumes central support of several enrollment protocols to support the various capabilities of IEDs from different vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies mandatory support of two enrollment protocols for the infrastructure side, SCEP [RFC8894] and EST [RFC7030], while an IED may support only one of them.¶
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 [ISO-IEC-15118-2]) as well as between the charging point and the charging point operator (e.g., OCPP [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.¶
This 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.¶
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.¶
We thank Eliot Lear for his contributions as a co-author at an earlier draft stage.¶
We thank Brian E. Carpenter, Michael Richardson, and Giorgio Romanenghi for their input and discussion on use cases and call flows.¶
Moreover, we thank Toerless Eckert (document shepherd); Barry Leiba (SECdir review); Mahesh Jethanandani (IETF area director); Meral Shirazipour (Gen-ART reviewer); Reshad Rahman (YANGDOCTORS reviewer); Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Danyliw, and Éric Vyncke (IESG reviewers); Michael Richardson (ANIMA design team member); and Rajeev Ranjan, Rufus Buschart, Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) for their reviews with suggestions for improvements.¶