rfc9733.original   rfc9733.txt 
ANIMA WG D. von Oheimb, Ed. Internet Engineering Task Force (IETF) D. von Oheimb, Ed.
Internet-Draft S. Fries Request for Comments: 9733 S. Fries
Intended status: Standards Track H. Brockhaus Category: Standards Track H. Brockhaus
Expires: 21 March 2025 Siemens ISSN: 2070-1721 Siemens
17 September 2024 February 2025
BRSKI-AE: Alternative Enrollment Protocols in BRSKI BRSKI with Alternative Enrollment (BRSKI-AE)
draft-ietf-anima-brski-ae-13
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-AE (Alternative Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative
Enrollment). Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate
BRSKI-AE extends BRSKI to support certificate enrollment mechanisms enrollment mechanisms instead of the originally specified use of
instead of the originally specified use of EST. It supports Enrollment over Secure Transport (EST). It supports certificate
certificate enrollment protocols, such as CMP, that use authenticated enrollment protocols such as the Certificate Management Protocol
self-contained signed objects for certification messages, allowing (CMP) that use authenticated self-contained signed objects for
for flexibility in network device onboarding scenarios. certification messages, allowing for flexibility in network device
The enhancements address use cases where the existing enrollment onboarding scenarios. The enhancements address use cases where the
mechanism may not be feasible or optimal, providing a framework for existing enrollment mechanism may not be feasible or optimal,
integrating suitable alternative enrollment protocols. providing a framework for integrating suitable alternative enrollment
This document also updates the BRSKI reference architecture to protocols. This document also updates the BRSKI reference
accommodate these alternative methods, ensuring secure and scalable architecture to accommodate these alternative methods, ensuring
deployment across a range of network environments. secure and scalable deployment across a range of network
environments.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/.
Discussion of this document takes place on the anima Working Group
mailing list (mailto:anima@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/anima/. Subscribe at
https://www.ietf.org/mailman/listinfo/anima/.
Source for this draft and an issue tracker can be found at
https://github.com/anima-wg/anima-brski-ae.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 March 2025. 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 Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Supported Scenarios . . . . . . . . . . . . . . . . . . . 5 1.1. Supported Scenarios
2. Terminology and abbreviations . . . . . . . . . . . . . . . . 6 2. Terminology and Abbreviations
3. Basic Requirements and Mapping to Solutions . . . . . . . . . 8 3. Basic Requirements and Mapping to Solutions
3.1. Solution Options for Proof of Possession . . . . . . . . 9 3.1. Solution Options for Proof of Possession
3.2. Solution Options for Proof of Identity . . . . . . . . . 9 3.2. Solution Options for Proof of Identity
4. Adaptations to BRSKI . . . . . . . . . . . . . . . . . . . . 11 4. Adaptations to BRSKI
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Architecture
4.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 15 4.2. Message Exchange
4.2.1. Pledge - Registrar Discovery . . . . . . . . . . . . 15 4.2.1. Pledge - Registrar Discovery
4.2.2. Pledge - Registrar - MASA Voucher Exchange . . . . . 15 4.2.2. Pledge - Registrar - MASA Voucher Exchange
4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry . 15 4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment . . 16 4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
4.2.5. Pledge - Registrar Enrollment Status Telemetry . . . 19 4.2.5. Pledge - Registrar Enrollment Status Telemetry
4.3. Enhancements to the Endpoint Addressing Scheme of 4.3. Enhancements to the Endpoint Addressing Scheme of BRSKI
BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Instantiation with Existing Enrollment Protocols
5. Instantiation with Existing Enrollment Protocols . . . . . . 21 5.1. BRSKI-CMP: BRSKI-AE Instantiated with CMP
5.1. BRSKI-CMP: BRSKI-AE instantiated with CMP . . . . . . . . 21 5.2. Support of Other Enrollment Protocols
5.2. Support of Other Enrollment Protocols . . . . . . . . . . 23 6. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Privacy Considerations
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 9. References
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Application Examples
10.2. Informative References . . . . . . . . . . . . . . . . . 26 A.1. Rolling Stock
Appendix A. Application Examples . . . . . . . . . . . . . . . . 29 A.2. Building Automation
A.1. Rolling Stock . . . . . . . . . . . . . . . . . . . . . . 29 A.3. Substation Automation
A.2. Building Automation . . . . . . . . . . . . . . . . . . . 29 A.4. Electric Vehicle Charging Infrastructure
A.3. Substation Automation . . . . . . . . . . . . . . . . . . 30 A.5. Infrastructure Isolation Policy
A.4. Electric Vehicle Charging Infrastructure . . . . . . . . 30 A.6. Sites with Insufficient Levels of Operational Security
A.5. Infrastructure Isolation Policy . . . . . . . . . . . . . 31 Acknowledgments
A.6. Sites with Insufficient Level of Operational Security . . 31 Contributors
Appendix B. History of Changes TBD RFC Editor: please delete . . 31 Authors' Addresses
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
BRSKI [RFC8995] is typically used with Enrollment over Secure Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] is
Transport (EST, [RFC7030]) as the enrollment protocol for operator- typically used with Enrollment over Secure Transport (EST) [RFC7030]
specific device certificates, employing HTTP over TLS for secure as the enrollment protocol for operator-specific device certificates,
message transfer. BRSKI-AE is a variant using alternative enrollment employing HTTP over TLS for secure message transfer. BRSKI-AE is a
protocols with authenticated self-contained objects for the device variant using alternative enrollment protocols with authenticated
certificate enrollment. self-contained objects for the device certificate enrollment.
This approach offers several distinct advantages. It allows for the This approach offers several distinct advantages. It allows for the
authentication of the origin of requests and responses independently authentication of the origin of requests and responses independently
of message transfer mechanisms. This capability facilitates end-to- of message transfer mechanisms. This capability facilitates end-to-
end authentication (i.e., end-to-end proof of origin) across multiple end authentication (i.e., end-to-end proof of origin) across multiple
transport hops and supports the asynchronous operation of certificate transport hops and supports the asynchronous operation of certificate
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 is 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 Manufacturer Authorized Signing Authority (MASA) [RFC8995], to the
to the registrar, which is the access point of the target domain, registrar (which is the access point of the target domain), and to
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 [RFC8366] exchange 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 Locally significant Device IDentifier * The pledge then obtains its Locally Significant Device IDentifier
(IDevID, [IEEE_802.1AR-2018]). To this end, the pledge generates (LDevID) [IEEE_802.1AR-2018]. To this end, the pledge generates a
a private key, called LDevID secret, and 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 LDevID certificate. On success, it receives device certificate, called an "LDevID certificate". On success,
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
* Facilitates secure message exchange over any type of transfer * facilitates secure message exchanges over any type of transfer
mechanism, including asynchronous delivery. mechanism, including asynchronous delivery.
It may be observed that the BRSKI voucher exchange between the It may be observed that the BRSKI voucher exchange between the
pledge, registrar, and MASA involves the use of authenticated self- pledge, registrar, and MASA involves the use of authenticated self-
contained objects, which inherently possess these properties. contained objects, which inherently possess these properties.
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 (RFC 8995) specifies the use It may be important to note that [RFC8995] specifies the use of HTTP
of HTTP over TLS, but variations such as Constrained BRSKI over TLS, but variations such as Constrained BRSKI [cBRSKI], which
[I-D.ietf-anima-constrained-voucher] which uses 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:
* Pledges and/or the target domain leverage an existing certificate * When pledges and/or the target domain leverage an existing
enrollment protocol other than EST, such as CMP. certificate enrollment protocol other than EST, such as CMP.
* The application context precludes the use of EST for certificate * When the application context precludes the use of EST for
enrollment due to factors such as: certificate enrollment due to factors such as when:
- The Registration Authority (RA) is not co-located with the - The Registration Authority (RA) is not co-located with the
registrar and requires end-to-end authentication of requesters, registrar and requires end-to-end authentication of requesters,
which EST does not support over multiple transport hops. which EST does not support over multiple transport hops.
- The RA or Certification Authority (CA) operator mandates - The RA or Certification Authority (CA) operator mandates
auditable proof of origin for Certificate Signing Requests auditable proof of origin for Certificate Signing Requests
(CSRs), which cannot be provided by TLS as it only offers (CSRs), which cannot be provided by TLS as it only offers
transient source authentication. transient source authentication.
- Certificates are requested for key types, such as Key - Certificates are requested for key types, such as Key
Encapsulation Mechanism (KEM) keys, that do not support signing Encapsulation Mechanism (KEM) keys, that do not support signing
or other single-shot proof-of-possession methods, as those or other single-shot proof-of-possession methods as those
described in [RFC6955]. EST, which relies on CSRs in PKCS #10 described in [RFC6955]. EST, which relies on CSRs in PKCS #10
[RFC2986] format, does not accommodate these key types because format [RFC2986], does not accommodate these key types because
it necessitates proof-of-possession methods that operate within it necessitates proof-of-possession methods that operate within
a single message, whereas proof of possession for KEM keys a single message, whereas proof of possession for KEM keys
requires prior receipt of a fresh challenge value. requires prior receipt of a fresh challenge value.
- The pledge implementation employs security libraries that do - The pledge implementation employs security libraries that do
not support EST or uses a TLS library lacking support for the not support EST or uses a TLS library lacking support for the
"tls-unique" value [RFC5929], which EST requires for the strong "tls-unique" value [RFC5929], which EST requires for the strong
binding of source authentication. binding of source authentication.
* Full RA functionality is not available on-site within the target * When full RA functionality is not available on-site within the
domain, and connectivity to an off-site RA may be intermittent or target domain, and connectivity to an off-site RA may be
entirely offline. intermittent or entirely offline.
* Authoritative actions by a local RA at the registrar are * When authoritative actions by a local RA at the registrar are
insufficient for fully and reliably authorizing pledge insufficient for fully and reliably authorizing pledge
certification requests, potentially due to a lack of access to certification requests, potentially due to a lack of access to
necessary data or inadequate security measures, such as the local necessary data or inadequate security measures, such as the local
storage of private keys. storage of private keys.
Bootstrapping may be managed in various ways depending on the Bootstrapping may be managed in various ways depending on the
application domain. Appendix A provides illustrative examples from application domain. Appendix A provides illustrative examples from
different industrial control system environments and operational different industrial control system environments and operational
contexts that motivate the support of alternative enrollment contexts that motivate the support of alternative enrollment
protocols. protocols.
2. Terminology and abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
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], partly repeated here. Also [RFC5280], and [IEEE_802.1AR-2018], which is partly repeated here.
several further terms are 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.
asynchronous: time-wise interrupted delivery of messages, The following terminology is used in this document:
here between a pledge and some backend system (e.g., an RA)
attribute request: message requesting content to be included in the asynchronous: the time-wise interrupted delivery of messages, here,
certification request between a pledge and some backend system (e.g., an RA).
attribute response: message providing the answer to the attribute attribute request: a message requesting content to be included in
request the certification request.
attribute response: a message providing the answer to the attribute
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: placement of a domain component separately from the domain backend: the placement of a domain component separately from the
registrar; may be on-site or off-site domain registrar; it may be on-site or off-site.
BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995] CA certs request: a message requesting CA certificates.
BRSKI-AE: BRSKI with *A*lternative *E*nrollment, a variation of CA certs response: a message providing the answer to a CA certs
BRSKI [RFC8995] in which BRSKI-EST, the enrollment protocol request.
between 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 certs request: message requesting CA certificates certificate confirm: a message stating to the backend PKI that the
requester of a certificate received the new certificate and
accepted it.
CA certs response: message providing the answer to a CA certs certification request: a message requesting a certificate with proof
request of identity.
certificate confirm: message stating to the backend PKI that the certification response: a message providing the answer to a
requester of a certificate received the new certificate and certification request.
accepted it
certification request: message requesting a certificate with proof local RA: the same as LRA.
of identity
certification response: message providing the answer to a off-site: the locality of a component, service, or functionality
certification request (such as RA or CA) that is not at the site of the registrar. This
may be a central site or a cloud service, to which connection may
be intermittent.
CMP: Certificate Management Protocol [RFC4210] [RFC9480] on-site: the locality of a component, service, or functionality at
the site of the registrar.
CSR: Certificate Signing Request PKI/registrar confirm: an acknowledgment of the PKI on the
certificate confirm.
EST: Enrollment over Secure Transport [RFC7030] pledge: a device that is to be bootstrapped into a target domain.
It requests an LDevID using IDevID credentials installed by its
manufacturer.
IDevID: Initial Device IDentifier of a pledge, provided by the registrar: short for domain registrar.
manufacturer and comprising a private key and the related X.509
certificate with its chain
LCMPP: Lightweight CMP Profile [RFC9483] site: the locality where an entity such as a pledge, registrar, or
PKI component is deployed. The target domain may have multiple
sites.
LDevID: Locally significant Device IDentifier of a pledge, provided synchronous: the time-wise uninterrupted delivery of messages, here,
by its target domain and comprising a private key and the related between a pledge and a registrar or backend system (e.g., the
X.509 certificate with its chain MASA).
local RA (LRA): a subordinate RA that is close to entities being target domain: the domain that a pledge is going to be bootstrapped
enrolled and separate from a subsequent RA. In BRSKI-AE it is into.
needed if a backend RA is used, and in this case, the LRA is co-
located with the registrar.
MASA: Manufacturer Authorized Signing Authority, provides vouchers The following abbreviations are used in this document:
off-site: locality of component or service or functionality, such as BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995]
RA or CA, not at the site of the registrar. This may be a central
site or a cloud service, to which connection may be intermittent.
on-site: locality of a component or service or functionality at the BRSKI-AE: BRSKI with Alternative Enrollment. Refers to a variation
site of the registrar 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.
PKI/registrar confirm: acknowledgment of the PKI on the certificate CA: Certification Authority
confirm
pledge: device that is to be bootstrapped into a target domain. It CMC: Certificate Management over CMS
requests an LDevID using IDevID credentials installed by its
manufacturer.
RA: Registration Authority, the PKI component to which a CA CMP: Certificate Management Protocol [RFC4210] [RFC9480]
typically delegates certificate management functions such as
authenticating pledges and performing authorization checks on
certification requests
registrar: short for domain registrar CMS: Cryptographic Message Syntax
site: the locality where an entity, such as a pledge, registrar, or CRMF: Certificate Request Message Format
PKI component is deployed. The target domain may have multiple
sites.
synchronous: time-wise uninterrupted delivery of messages, here CSR: Certificate Signing Request
between a pledge and a registrar or backend system (e.g., the
MASA)
target domain: the domain that a pledge is going to be bootstrapped EST: Enrollment over Secure Transport [RFC7030]
into
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
corresponding to the public key contained in a certification corresponding to the public key contained in a certification
request. This is typically achieved by a self-signature using the request. This is typically achieved by a self-signature using the
corresponding private key but can also be achieved indirectly, see corresponding private key but can also be achieved indirectly; see
[RFC4210], Section 4.3. [RFC4210], Section 4.3.
* Proof of identity, also called proof of origin: provides data * Proof of identity (also called "proof of origin"): provides data
origin authentication of the certification request. Typically, origin authentication of the certification request. Typically,
this is achieved by a signature using the pledge IDevID secret this is achieved by a signature using the pledge IDevID secret
over some data, which needs to include a sufficiently strong over some data, which needs to include a sufficiently strong
identifier of the pledge, such as the device serial number identifier of the pledge, such as the device serial number
typically included in the subject of the IDevID certificate. typically included in the subject of the IDevID certificate.
The remainder of this section gives a non-exhaustive list of solution The remainder of this section gives a non-exhaustive list of solution
examples, based on existing technology described in IETF documents. examples, based on existing technology described in IETF documents.
3.1. Solution Options for Proof of Possession 3.1. Solution Options for Proof of Possession
Certificate signing request (CSR) objects: CSRs are data structures Certificate Signing Request (CSR) objects are data structures
protecting only the integrity of the contained data and providing protecting only the integrity of the contained data and providing
proof of possession for a (locally generated) private key. Important proof of possession for a (locally generated) private key. Important
types of CSR data structures are: types of CSR data structures are:
* PKCS #10 [RFC2986]. This very common form of CSR is self-signed * PKCS #10 [RFC2986]: This very common form of CSR is self-signed to
to protect its integrity and to prove possession of the private protect its integrity and to prove possession of the private key
key that corresponds to the public key included in the request. that corresponds to the public key included in the request.
* Certificate Request Message Format (CRMF, [RFC4211]). This less * Certificate Request Message Format (CRMF) [RFC4211]: This less
common but more general CSR format supports several ways of common but more general CSR format supports several ways of
integrity protection and proof of possession. Typically a self- integrity protection and proof of possession. Typically a self-
signature is used, which is generated over (part of) the structure signature is used, which is generated over (part of) the structure
with the private key corresponding to the included public key. with the private key corresponding to the included public key.
CRMF also supports further proof-of-possession methods for types CRMF also supports further proof-of-possession methods for types
of keys that do not have signing capability. For details see of keys that do not have signing capability. For details, see
[RFC4211], Section 4. [RFC4211], Section 4.
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 the authentication, (i.e., proof of identity of the requester) because
key pair involved is new and therefore does not yet have a confirmed the key pair involved is new and therefore does not yet have a
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], also its variant EST-coaps [RFC9148], utilizes PKCS * EST [RFC7030] and its variant EST-coaps [RFC9148] utilize PKCS #10
#10 to encode Certificate Signing Requests (CSRs). While such a to encode CSRs. While such a CSR has not been designed to include
CSR has not been designed to include proof of origin, there is a proof of origin, there is a limited, indirect way of binding it to
limited, indirect way of binding it to the source authentication the source authentication of the underlying TLS session. This is
of the underlying TLS session. This is achieved by including in achieved by including in the CSR the "tls-unique" value [RFC5929]
the CSR the tls-unique value [RFC5929] resulting from the TLS resulting from the TLS handshake. As this is optionally supported
handshake. As this is optionally supported by the EST by the EST "/simpleenroll" endpoint used in BRSKI, and the TLS
"/simpleenroll" endpoint used in BRSKI and the TLS handshake handshake employed in BRSKI includes certificate-based client
employed in BRSKI includes certificate-based client authentication authentication of the pledge with its IDevID credentials, the
of the pledge with its IDevID credentials, the proof of pledge proof of pledge identity being an authenticated TLS client can be
identity being an authenticated TLS client can be bound to the bound to the CSR.
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
to authenticate and pre-authorize the pledge and to indicate this authenticate and pre-authorize the pledge and indicate this to the
to the (second) RA by signing the forwarded certification request (second) RA. This is done by signing the forwarded certification
with its private key and a related certificate that has the id-kp- request with its private key and a related certificate that has
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.
* SCEP [RFC8894] supports using a shared secret (passphrase) or an * The Simple Certificate Enrolment Protocol (SCEP) [RFC8894]
existing certificate to protect CSRs based on SCEP Secure Message supports using a shared secret (passphrase) or an existing
Objects using CMS wrapping ([RFC5652]). Note that the wrapping certificate to protect CSRs based on SCEP Secure Message Objects
using an existing IDevID in SCEP is referred to as 'renewal'. using Cryptographic Message Syntax (CMS) wrapping [RFC5652]. Note
This way SCEP does not rely on the security of the underlying that the wrapping using an existing IDevID in SCEP is referred to
message transfer. as "renewal". This way, SCEP does not rely on the security of the
underlying message transfer.
* CMP [RFC4210] [RFC9480] supports using a shared secret * CMP [RFC4210] [RFC9480] supports using a shared secret
(passphrase) or an existing certificate, which may be an IDevID (passphrase) or an existing certificate, which may be an IDevID
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.
* CMC [RFC5272] also supports utilizing a shared secret (passphrase) * Certificate Management over CMS (CMC) [RFC5272] also supports
or an existing certificate to protect certification requests, utilizing a shared secret (passphrase) or an existing certificate
which can be either in CRMF or PKCS #10 structure. The proof of to protect certification requests, which can be either in a CRMF
identity can be provided as part of a FullCMCRequest, based on CMS or PKCS #10 structure. The proof of identity can be provided as
[RFC5652] and signed with an existing IDevID secret. Thus, CMC part of a Full CMC Request based on CMS [RFC5652] and signed with
does not rely on the security of the underlying message transfer. 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- 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 page 12, line 32 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 as BRSKI but with a more flexible placement of the authentication and
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 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: same requirements as in BRSKI, see [RFC8995], * Join Proxy: This has the same requirements as in [RFC8995] (see
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
protocol with authenticated self-contained objects for protocol with authenticated self-contained objects for
certification requests. To this end, the URI scheme for certification requests. To this end, the URI scheme for
addressing endpoints at the registrar is generalized (see addressing endpoints at the registrar is generalized (see
Section 4.3). Section 4.3).
2. Rather than having full RA functionality, the registrar MAY 2. Rather than having full RA functionality, the registrar MAY
act as a local registration authority (LRA) and delegate part act as a Local Registration Authority (LRA) and delegate part
of its involvement in certificate enrollment to a backend RA. of its involvement in certificate enrollment to a backend RA.
In such scenarios, the registrar optionally checks In such scenarios, the registrar optionally checks
certification requests it receives from pledges and forwards certification requests it receives from pledges and forwards
them to the backend RA, which performs the remaining parts of them to the backend RA, which performs the remaining parts of
the enrollment request validation and authorization. Note the enrollment request validation and authorization. Note
that to this end the backend RA may need information regarding that to this end, the backend RA may need information
the authorization of pledges from the registrar or from other regarding the authorization of pledges from the registrar or
sources. On the way back, the registrar forwards responses by from other sources. On the way back, the registrar forwards
the PKI to the pledge on the same channel. responses by the PKI to the pledge on the same channel.
To support end-to-end authentication of the pledge across the To support end-to-end authentication of the pledge across the
registrar to the backend RA, the certification request signed registrar to the backend RA, the certification request signed
by the pledge needs to be upheld and forwarded by the by the pledge needs to be upheld and forwarded by the
registrar. Therefore, the registrar cannot use for its registrar. Therefore, for its communication with the PKI, the
communication with the PKI an enrollment protocol that is registrar cannot use an enrollment protocol that is different
different from the enrollment protocol used between the pledge from the enrollment protocol used between the pledge and the
and the registrar. registrar.
3. The use of a certificate enrollment protocol with 3. The use of a certificate enrollment protocol with
authenticated self-contained objects gives freedom how to authenticated self-contained objects gives freedom with how to
transfer enrollment messages between the pledge and an RA. transfer enrollment messages between the pledge and an RA.
BRSKI demands that the RA accept certification requests for BRSKI demands that the RA accept certification requests for
LDevIDs only with the consent of the registrar. BRSKI-AE LDevIDs only with the consent of the registrar. BRSKI-AE also
guarantees this also in case that the RA is not part of the guarantees this in the case that the RA is not part of the
registrar, even if the message exchange with backend systems registrar, even if the message exchange with backend systems
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 to 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: functionality as described in BRSKI [RFC8995]. The voucher * MASA: This has the functionality as described in [RFC8995]. The
exchange with the MASA via the domain registrar is performed as voucher exchange with the MASA via the domain registrar is
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 request with nonces) or asynchronous (using nonceless | (using voucher requests with nonces) or asynchronous (using
voucher requests). | nonceless voucher requests).
* Ownership tracker: 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: performs centralized certificate management functions as a * RA: This performs centralized certificate management functions as
public-key infrastructure for the domain operator. As far as not a PKI for the domain operator. In case these functions are 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: generates domain-specific certificates * CA (also called "domain CA"): This generates domain-specific
according to certification requests that have been authenticated certificates according to certification requests that have been
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 to the original showing commonalities and differences with the original approach as
approach as follows. follows.
* Discovery phase: mostly as in BRSKI step (1). For details see * Discover: This is mostly as in step (1) of [RFC8995]. For
Section 4.2.1. details, see Section 4.2.1.
* Identification phase: same as in BRSKI step (2). * Identify: This is the same as in step (2) of [RFC8995].
* Voucher exchange phase: same as in BRSKI steps (3) and (4). * Voucher exchange: This is the same as in steps (3) and (4) of
[RFC8995].
* Voucher status telemetry: same as in BRSKI directly after step * Voucher status telemetry: This is the same as directly after step
(4). (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: the final exchange of BRSKI step (5). * Enrollment status telemetry: This is the final exchange of step
(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 can discovery of registrars with enhanced feature sets. A pledge cannot
not 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 registrars. For further discussion, see [BRSKI-discovery].
[I-D.ietf-anima-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 the below Figure 2 | Note: The message exchanges marked OPTIONAL in Figure 2 below
cover all those supported by the use of EST in BRSKI. The last | cover all those supported by the use of EST in BRSKI. The last
OPTIONAL one, namely certificate confirmation, is not supported by | OPTIONAL one, namely certificate confirmation, is not supported
EST, but by 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 page 17, line 43 skipping to change at line 769
|[OPTIONAL certificate confirmation] | | |[OPTIONAL certificate confirmation] | |
|------- Certificate Confirm (7) ---->| | |------- Certificate Confirm (7) ---->| |
| | [OPTIONAL forwarding] | | | [OPTIONAL forwarding] |
| |--- Certificate Confirm--->| | |--- Certificate Confirm--->|
| |<-- 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 off- components of the operator (RA, CA, etc.) may be intermittent or
line. 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 The label '[OPTIONAL forwarding]' in Figure 2 means that on receiving
from a pledge a request message of the given type, 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
an error response in case it determines that such a request should be an error response in case it determines that such a request should be
rejected, for instance, because is not properly authenticated or not rejected, for instance, because it is not properly authenticated or
authorized.Also, certificate confirmation messages will usually be authorized. Also, certificate confirmation messages will usually be
forwarded to the backend PKI, but if the registrar knows that they forwarded to the backend PKI, but if the registrar knows that they
are not needed or wanted there it can acknowledge such messages are not needed or wanted there, it can acknowledge such messages
directly. directly.
The following list provides an abstract description of the flow The following list provides an abstract description of the flow
depicted in Figure 2. depicted in Figure 2.
* CA Certs Request (1): The pledge optionally requests the latest * CA Certs Request (1): The pledge optionally requests the latest
relevant CA certificates. This ensures that the pledge has the relevant CA certificates. This ensures that the pledge has the
complete set of current CA certificates beyond the pinned-domain- complete set of current CA certificates beyond the pinned-domain-
cert (which is contained in the voucher and which may be just the cert (which is contained in the voucher and which may be just the
domain registrar certificate). domain registrar certificate).
* CA Certs Response (2): This MUST contain any intermediate CA * CA Certs Response (2): This MUST contain any intermediate CA
certificates that the pledge may need to validate certificates and certificates that the pledge may need to validate certificates and
MAY contain the LDevID trust anchor. MAY contain the LDevID trust anchor.
* Attribute Request (3): Typically, the automated bootstrapping * Attribute Request (3): Typically, the automated bootstrapping
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
in the Certification Request (5) additional attributes that are additional attributes that are specific to the target domain in
specific to the target domain. 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 ACP domain. name' field required for enrollment into an Autonomic Control
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): This MUST contain on success 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.
* Certificate Confirm (7): An optional confirmation sent after the * Certificate Confirm (7): This is an optional confirmation that is
requested certificate has been received and validated. If sent, sent after the requested certificate has been received and
it MUST contain a positive or negative confirmation by the pledge validated. If sent, it MUST contain a positive or negative
to the PKI whether the certificate was successfully enrolled and confirmation by the pledge to the PKI whether the certificate was
fits its needs. successfully enrolled and fits its needs.
* PKI/Registrar Confirm (8): An acknowledgment by the PKI that MUST * PKI/Registrar Confirm (8): This is an acknowledgment by the PKI
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, 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 on 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
see also 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 and the The addressing scheme in [RFC8995] for certification requests,
related CA certificates and CSR attributes retrieval functions uses related CA certificates, and CSR attributes retrieval functions uses
the definition from EST [RFC7030]. Here is the example of simple the definition from EST [RFC7030]. An example of simple enrollment
enrollment: "/.well-known/est/simpleenroll". This approach is is: "/.well-known/est/simpleenroll". This approach is generalized to
generalized to the following notation: "/.well-known/<enrollment- the following notation: "/.well-known/<enrollment-
protocol>/<request>" in which <enrollment-protocol> refers to a protocol>/<request>" in which "<enrollment-protocol>" refers to a
certificate enrollment protocol. Note that enrollment is considered certificate enrollment protocol. Note that here, enrollment is
here a message sequence that contains at least a certification considered a message sequence that contains at least a certification
request and a certification response. The following conventions are request and a certification response. The following conventions are
used to provide maximal compatibility with BRSKI: used to provide maximal compatibility with BRSKI:
* <enrollment-protocol>: MUST reference the protocol being used. * "<enrollment-protocol>": This MUST reference the protocol being
Existing values include 'est' [RFC7030] as in BRSKI and 'cmp' as used. Existing values include 'est' [RFC7030] as in [RFC8995] and
in [RFC9483] and Section 5.1 below. Values for other existing 'cmp' as in [RFC9483] and Section 5.1 below. Values for other
protocols such as CMC and SCEP, as well as for 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, * "<request>": If present, this path component MUST describe the
depending on the enrollment protocol being used, the operation operation requested depending on the enrollment protocol being
requested. Enrollment protocols are expected to define their used. Enrollment protocols are expected to define their request
request endpoints, as done by existing protocols (see also endpoints, as is done by existing protocols (also see Section 5).
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
protocol(s) that it can use. It will recognize whether the protocol protocol(s) that it can use. It will recognize whether the protocol
it uses and the specific request it wants to perform are understood it uses and the specific request it wants to perform are understood
and supported by the domain registrar by sending the request to the and supported by the domain registrar. This is done by sending the
respective endpoint according to the above addressing scheme and then request to the respective endpoint according to the above addressing
evaluating the HTTP status code of the response. If the pledge uses scheme and then evaluating the HTTP status code of the response. If
endpoints that are not standardized, it risks that the registrar does the pledge uses endpoints that are not standardized, it risks that
not recognize a request and thus may reject it, even if the registrar the registrar does not recognize a request and thus may reject it
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
the CMP client can be stronger than for EST because they do not 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. need to be performed hop-by-hop but are usually end-to-end.
* CA Certs Request (1) and Response (2): * CA Certs Request (1) and Response (2): Requesting CA certificates
Requesting CA certificates is OPTIONAL. is OPTIONAL. If supported, it SHALL be implemented as specified
If supported, it SHALL be implemented as specified in [RFC9483], in [RFC9483], Section 4.3.1.
Section 4.3.1.
* Attribute Request (3) and Response (4): * Attribute Request (3) and Response (4): Requesting certification
Requesting certification request attributes is OPTIONAL. request attributes is OPTIONAL. If supported, it SHALL be
If supported, it SHALL be implemented as specified in [RFC9483], implemented as specified in [RFC9483], Section 4.3.3.
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): * Certification Request (5) and Response (6): Certificates SHALL be
Certificates SHALL be requested and provided as specified in LCMPP requested and provided as specified in the LCMPP from [RFC9483],
[RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483], Section 4.1.4 (based
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 If additional trust anchors beyond the pinned-domain-cert need to
to be conveyed to the pledge, this SHOULD be done in the caPubs be conveyed to the pledge, this SHOULD be done in the 'caPubs'
field 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): * Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit
Explicit confirmation of new certificates to the RA/CA MAY be used confirmation of new certificates to the RA/CA MAY be used as
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 Section 4.4 and Section 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
security and privacy considerations, refer to Section 7 and security and privacy considerations, refer to Sections 7 and 8.
Section 8. 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
[I-D.ietf-anima-constrained-voucher], using CoAP for enrollment [cBRSKI], using CoAP for enrollment message transport as described by
message transport as described by CoAP Transport for CMP [RFC9482]. CoAP Transfer for CMP [RFC9482]. In such scenarios, the EST-specific
In such scenarios, the EST-specific parts of parts of [cBRSKI] do not apply.
[I-D.ietf-anima-constrained-voucher] 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), registrars with CMP support is not available (cf. Section 4.2.1), the
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.
The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might
also be used here. For EST-fullCMC further specification is also be used here. For EST-fullCMC, further specification is
necessary. necessary.
6. IANA Considerations 6. IANA Considerations
This document requires one IANA action: register in the Service Name IANA has registered the following service name in the "Service Name
and Transport Protocol Port Number Registry and Transport Protocol Port Number Registry"
(https://www.iana.org/assignments/service-names-port-numbers/service- <https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xhtml) the following service name. names-port-numbers.xhtml>.
*Service Name:* brski-reg-cmp Service Name: brski-reg-cmp
*Transport Protocol(s):* tcp Transport Protocol(s): tcp
*Assignee:* IESG iesg@ietf.org (mailto:iesg@ietf.org) Description: Bootstrapping Remote Secure Key Infrastructure
*Contact:* IETF chair@ietf.org (mailto:chair@ietf.org) registrar with CMP capabilities according to the Lightweight CMP
*Description:* Bootstrapping Remote Secure Key Infrastructure Profile (LCMPP) [RFC9483]
registrar with CMP capabilities according to the Lightweight CMP Assignee: IESG iesg@ietf.org (mailto:iesg@ietf.org)
Profile (LCMPP, [RFC9483]) Contact: IETF chair@ietf.org (mailto:chair@ietf.org)
*Reference:* [THISRFC] Reference: RFC 9733
Note: We chose here the suffix "cmp" 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 pertains also 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 can domain-specific certificate, it must be made sure that a pledge
not circumvent the registrar in the decision of whether it is granted cannot circumvent the registrar in the decision of whether it is
an LDevID certificate by the CA. There are various ways how to granted an LDevID certificate by the CA. There are various ways to
fulfill this, including: fulfill this, including:
* implicit consent * implicit consent;
* the registrar signals its consent to the RA out-of-band before or * the registrar signaling its consent to the RA out-of-band before
during the enrollment phase, for instance by entering the pledge or during the enrollment phase, for instance, by entering the
identity in a database. pledge identity in a database;
* the registrar provides 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. possibly in a TLS tunnel; and
* the registrar explicitly states its consent by signing, in * the registrar explicitly stating its consent by signing the
addition to the pledge, the authenticated self-contained authenticated self-contained certificate enrollment request
certificate enrollment request message. 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 the 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. This in turn 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.
9. Acknowledgments 9. References
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), as well as Rajeev Ranjan, Rufus Buschart,
Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) for
their reviews with suggestions for improvements.
10. References
10.1. Normative References 9.1. Normative References
[IEEE_802.1AR-2018] [IEEE_802.1AR-2018]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE 802.1AR-2018, Networks - Secure Device Identity", IEEE 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, August 2018, DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://ieeexplore.ieee.org/document/8423794>. <https://ieeexplore.ieee.org/document/8423794>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/rfc/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/rfc/rfc9483>. <https://www.rfc-editor.org/info/rfc9483>.
10.2. Informative References 9.2. Informative References
[BRSKI-AE-overview] [BRSKI-AE-overview]
S. Fries and D. von Oheimb, "BRSKI-AE Protocol Overview", von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "Update
March 2023, on BRSKI-AE: Alternative Enrollment Protocols in BRSKI",
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>. Graphics on slide 4 of enrollment-protocols-in-brski-00>.
the status update on the BRSKI-AE draft 04 at IETF 116.
[I-D.ietf-anima-brski-discovery] [BRSKI-discovery]
Eckert, T. T. and E. Dijk, "Discovery for BRSKI Eckert, T., Ed. 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-04, 25 July 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-04>. brski-discovery-05>.
[I-D.ietf-anima-constrained-voucher] [cBRSKI] Richardson, M., Van der Stok, P., Kampanakis, P., and E.
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-25, 8 July Draft, draft-ietf-anima-constrained-voucher-26, 8 January
2024, <https://datatracker.ietf.org/doc/html/draft-ietf- 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
anima-constrained-voucher-25>. anima-constrained-voucher-26>.
[IEC-62351-9] [IEC-62351-9]
International Electrotechnical Commission, "IEC 62351 - International Electrotechnical Commission, "Power systems
Power systems management and associated information management and associated information exchange - Data and
exchange - Data and communications security - Part 9: communications security - Part 9: Cyber security key
Cyber security key management for power system equipment", management for power system equipment", IEC 62351-9:2023,
IEC 62351-9, May 2017. June 2023, <https://webstore.iec.ch/en/publication/66864>.
[ISO-IEC-15118-2] [ISO-IEC-15118-2]
International Standardization Organization / International International Organization for Standardization, "Road
Electrotechnical Commission, "ISO/IEC 15118-2 Road
vehicles - Vehicle-to-Grid Communication Interface - Part vehicles - Vehicle-to-Grid Communication Interface - Part
2: Network and application protocol requirements", ISO/ 2: Network and application protocol requirements",
IEC 15118-2, April 2014. ISO 15118-2:2014, April 2014,
<https://www.iso.org/standard/55366.html>.
[NERC-CIP-005-5] [NERC-CIP-005-5]
North American Reliability Council, "Cyber Security - North American Electric Reliability Council, "Cyber
Electronic Security Perimeter", CIP 005-5, December 2013. Security - Electronic Security Perimeter", CIP 005-5,
December 2013.
[OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0.1 [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0.1
(Draft)", December 2019. (Draft)", December 2019.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/rfc/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005, DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/rfc/rfc4210>. <https://www.rfc-editor.org/info/rfc4210>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005, DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/rfc/rfc4211>. <https://www.rfc-editor.org/info/rfc4211>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/rfc/rfc5272>. <https://www.rfc-editor.org/info/rfc5272>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/rfc/rfc5929>. <https://www.rfc-editor.org/info/rfc5929>.
[RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof- [RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955, of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
May 2013, <https://www.rfc-editor.org/rfc/rfc6955>. May 2013, <https://www.rfc-editor.org/info/rfc6955>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/rfc/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol", [RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol",
RFC 8894, DOI 10.17487/RFC8894, September 2020, RFC 8894, DOI 10.17487/RFC8894, September 2020,
<https://www.rfc-editor.org/rfc/rfc8894>. <https://www.rfc-editor.org/info/rfc8894>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994, Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021, DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/rfc/rfc8994>. <https://www.rfc-editor.org/info/rfc8994>.
[RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S. [RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST-coaps: Enrollment over Secure Transport with Raza, "EST-coaps: Enrollment over Secure Transport with
the Secure Constrained Application Protocol", RFC 9148, the Secure Constrained Application Protocol", RFC 9148,
DOI 10.17487/RFC9148, April 2022, DOI 10.17487/RFC9148, April 2022,
<https://www.rfc-editor.org/rfc/rfc9148>. <https://www.rfc-editor.org/info/rfc9148>.
[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate [RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
Management Protocol (CMP) Updates", RFC 9480, Management Protocol (CMP) Updates", RFC 9480,
DOI 10.17487/RFC9480, November 2023, DOI 10.17487/RFC9480, November 2023,
<https://www.rfc-editor.org/rfc/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/rfc/rfc9482>. November 2023, <https://www.rfc-editor.org/info/rfc9482>.
[UNISIG-Subset-137] [UNISIG-Subset-137]
UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
FFFIS; V1.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>.
http://www.kmc-subset137.eu/index.php/download/
Appendix A. Application Examples Appendix A. Application Examples
This informative annex provides some detail 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, which communicate within the railroad car actuators, and controllers. These communicate within the railroad
but also exchange information between railroad cars forming a train, car but also exchange information with other railroad cars of the
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 specifying the ETRAM/ETCS online key management for in the Subset-137, which specifies the ETRAM/ETCS online key
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
controllers that are connected to each other in a local network but controllers that are connected to each other in a local network but
with only limited or no connectivity to a central building management with only limited or no connectivity to a central building management
system. This problem may occur during installation time but also system. This problem may occur during installation time but also
during operation. In such a situation a service technician collects during operation. In such a situation, a service technician collects
the necessary data and transfers it between the local network and the the necessary data and transfers it between the local network and the
central building management system, e.g., using a laptop or a mobile central building management system, e.g., using a laptop or a mobile
phone. This data may comprise parameters and settings required in phone. This data may comprise parameters and settings required in
the operational phase of the sensors/actuators, like a component the operational phase of the sensors/actuators, like a component
certificate issued by the operator to authenticate against other certificate issued by the operator to authenticate against other
components and services. components and services.
The collected data may be provided by a domain registrar already The collected data may be provided by a domain registrar already
existing in the local network. In this case connectivity to the existing in the local network. In this case, connectivity to the
backend PKI may be facilitated by the service technician's laptop. backend PKI may be facilitated by the service technician's laptop.
Alternatively, the data can also be collected from the pledges Alternatively, the data can also be collected from the pledges
directly and provided to a domain registrar deployed in a different directly and provided to a domain registrar deployed in a different
network in preparation for the operational phase. In this case, network in preparation for the operational phase. In this case,
connectivity to the domain registrar may also be facilitated by the connectivity to the domain registrar may also be facilitated by the
service technician's laptop. service technician's laptop.
A.3. Substation Automation A.3. Substation Automation
In electrical substation automation scenarios, a control center In electrical substation automation scenarios, a control center
typically hosts PKI services to issue certificates for Intelligent typically hosts PKI services to issue certificates for Intelligent
Electronic Devices operated in a substation. Communication between Electronic Devices (IEDs) operated in a substation. Communication
the substation and control center is performed through a between the substation and control center is performed through a
proxy/gateway/DMZ, which terminates protocol flows. Note that proxy/gateway/DMZ, which terminates protocol flows. Note that
[NERC-CIP-005-5] requires inspection of protocols at the boundary of [NERC-CIP-005-5] requires inspection of protocols at the boundary of
a security perimeter (the substation in this case). In addition, a security perimeter (in this case, the substation). In addition,
security management in substation automation assumes central support security management in substation automation assumes central support
of several enrollment protocols to support the various capabilities of several enrollment protocols to support the various capabilities
of IEDs from different vendors. The IEC standard IEC62351-9 of IEDs from different vendors. The IEC standard IEC62351-9
[IEC-62351-9] specifies for the infrastructure side mandatory support [IEC-62351-9] specifies mandatory support of two enrollment protocols
of two enrollment protocols: SCEP [RFC8894] and EST [RFC7030], while for the infrastructure side, SCEP [RFC8894] and EST [RFC7030], while
an Intelligent Electronic Device may support only one of them. an IED may support only one of them.
A.4. Electric Vehicle Charging Infrastructure A.4. Electric Vehicle Charging Infrastructure
For electric vehicle charging infrastructure, protocols have been For electric vehicle charging infrastructure, protocols have been
defined for the interaction between the electric vehicle and the defined for the interaction between the electric vehicle and the
charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as 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. between the charging point and the charging point operator (e.g.,
OCPP [OCPP]). Depending on the authentication model, unilateral or OCPP [OCPP]). Depending on the authentication model, unilateral or
mutual authentication is required. In both cases, the charging point mutual authentication is required. In both cases, the charging point
uses an X.509 certificate to authenticate itself in TLS channels uses an X.509 certificate to authenticate itself in TLS channels
between the electric vehicle and the charging point. The management between the electric vehicle and the charging point. The management
of this certificate depends, among others, on the selected backend of this certificate depends, among other things, on the selected
connectivity protocol. In the case of OCPP, this protocol is meant backend connectivity protocol. In the case of OCPP, this protocol is
to be the only communication protocol between the charging point and meant to be the only communication protocol between the charging
the backend, carrying all information to control the charging point and the backend, carrying all information to control the
operations and maintain the charging point itself. This means that charging operations and maintain the charging point itself. This
the certificate management needs to be handled in-band of OCPP. This means that the certificate management needs to be handled in-band of
requires the ability to encapsulate the certificate management OCPP. This requires the ability to encapsulate the certificate
messages in a transport-independent way. Authenticated self- management messages in a transport-independent way. Authenticated
containment will support this by allowing the transport without a self-containment will support this by allowing the transport without
separate enrollment protocol, binding the messages to the identity of a separate enrollment protocol, binding the messages to the identity
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 Level 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. registrars with co-located RAs may not be able to fulfill. In
Especially the CA/Browser forum currently increases the security particular, the CA/Browser forum currently increases the security
requirements in the certificate issuance procedures for publicly requirements in the certificate issuance procedures for publicly
trusted certificates, i.e., those placed in trust stores of browsers, 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 which may be used to connect with devices in the domain. In case the
on-site components of the target domain can not be operated securely on-site components of the target domain cannot be operated securely
enough for the needs of an RA, this service should be transferred to enough for the needs of an RA, this service should be transferred to
an off-site backend component that has a sufficient level of an off-site backend component that has a sufficient level of
security. security.
Appendix B. History of Changes TBD RFC Editor: please delete Acknowledgments
List of reviewers:
* Toerless Eckert (document shepherd)
* Barry Leiba (SECdir)
* Mahesh Jethanandani (IETF area director)
* Meral Shirazipour (Gen-ART reviewer)
* Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy,
Roman Danyliw, and Éric Vyncke (IESG reviewers)
* Michael Richardson (ANIMA design team)
* Rajeev Ranjan, Rufus Buschart, Szofia Fazekas-Zisch, etc.
(Siemens)
* Reshad Rahman (YANGDOCTORS reviewer). Note that YANGDOCTORS Early
review of 2021-08-15 (https://datatracker.ietf.org/doc/review-
ietf-anima-brski-async-enroll-03-yangdoctors-early-rahman-
2021-08-15/) referred to the PRM aspect of draft-ietf-anima-brski-
async-enroll-03 (https://datatracker.ietf.org/doc/draft-ietf-
anima-brski-async-enroll/03/). This has been carved out of the
draft to a different one and thus is no more applicable here.
IETF draft ae-12 -> ae-13:
* Due to IANA requirement, shorten service name "brski-registrar-
cmp" to "brski-reg-cmp"
and change contact for service name registration from IESG to IETF
* Address Deb Cooley's DISCUSS by adding an item to the requirements
list Section 5.1 making the source of the initial trust anchor
explicit.
Including the vouchers in Figure 2 would not fit because the
figure has a different scope (namely, certificate enrollment) and
would get overloaded.
* Address Gunter Van de Velde's comments by taking over essentially
all his rewrites of text to help the structure and simplify
reading the content, while keeping the original message, as it
helps improve document quality
* Address John Scudder's comments by tweaking Section 2, fully
alphabetizing terms
* Address Murray Kucherawy's comment by adapting terminology
entries, leaving out 'communication' from 'asynchronous
communication' and 'synchronous communication'
* Address Roman Danyliw's comments by updating reference
I-D.eckert-anima-brski-discovery to I-D.ietf-anima-brski-discovery
and adding Section 8, which refers to the BRSKI privacy
considerations.
* Address Éric Vyncke's comment by replacing 'production' by
'manufacturing'
IETF draft ae-11 -> ae-12:
* Fix minor issues introduced during authors' response to the AD
review,
including nits spotted in the Gen-ART review by Meral Shirazipour
IETF draft ae-10 -> ae-11:
* In response to AD review by Mahesh Jethanandani,
- replace most occurrences of 'Note:' by 'Note that' or the like
- move 2nd paragraph of abstract to the introduction
- remove section 1.2 and merge its first paragraph with the
preceding section
- reconsider normative language, replacing one 'may' by 'MAY' in
section 4.1
- fix several ambiguities and hard-to-read sentences by re-
phrasing them
- make wording more consistent, in particular: 'certification
request'
- fix a number of (mostly grammar) nits
* Improve item on limitations of PKCS#10 regarding keys that cannot
sign
IETF draft ae-09 -> ae-10:
* Add reference to RFC 8633 at first occurrence of 'voucher' (fixes
#37)
* Update reference of CoAP Transfer for CMP from I-D to RFC 9482
* Move RFC 4210 and RFC 9480 references from normative to
informative
* Fix p10 vs. pkcs10 entry in list of example endpoints in
Section 4.3
* Minor fix in Figure 1 and few text tweaks due to Siemens-internal
review
* Extend the list of reviewers and acknowledgments by two Siemens
colleagues
IETF draft ae-08 -> ae-09:
* In response to review by Toerless,
- tweak abstract to make meaning of 'alternative enrollment' more
clear
- expand on first use not "well-known" abbreviations, such as
'EST',
adding also a references on their first use
- add summary and reason for choosing CMP at end of Section 3.2
- remove paragraph on optimistic discovery in controlled
environments
- mention role of reviewers also in acknowledgments section
* A couple of grammar and spelling fixes
IETF draft ae-07 -> ae-08:
* Update references to service names in Section 5.1
IETF draft ae-06 -> ae-07:
* Update subsections on discovery according to discussion in the
design team
* In Section 5.1, replace 'mandatory' by 'REQUIRED' regarding
adherence to LCMPP,
in response to SECDIR Last Call Review of ae-06 by Barry Leiba
IETF draft ae-05 -> ae-06:
* Extend section on discovery according to discussion in the design
team
* Make explicit that MASA voucher status telemetry is as in BRSKI
* Add note that on delegation, RA may need info on pledge
authorization
IETF draft ae-04 -> ae-05:
* Remove entries from the terminology section that should be clear
from BRSKI
* Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by
RA/CA
* Add the abbreviation 'LCMPP' for Lightweight CMP Profile to the
terminology section
* State clearly in Section 5.1 that LCMPP is mandatory when using
CMP
* Change URL of BRSKI-AE-overview graphics to slide on IETF 116
meeting material
IETF draft ae-03 -> ae-04:
* In response to SECDIR Early Review of ae-03 by Barry Leiba,
- replace 'end-to-end security' by the more clear 'end-to-end
authentication'
- restrict the meaning of the abbreviation 'AE' to 'Alternative
Enrollment'
- replace 'MAY' by 'may' in requirement on delegated registrar
actions
- re-phrase requirement on certification request exchange,
avoiding MANDATORY
- mention that further protocol names need be put in Well-Known
URIs registry
- explain consequence of using non-standard endpoints, not
following SHOULD
- remove requirement that 'caPubs' field in CMP responses SHOULD
NOT be used
- add paragraph in security considerations on additional use of
TLS for CMP
* In response to further internal reviews and suggestions for
generalization,
- significantly cut down the introduction because the original
motivations and most explanations are no more needed and would
just make it lengthy to read
- sort out asynchronous vs. offline transfer, off-site vs.
backend components
- improve description of CSRs and proof of possession vs. proof
of origin
- clarify that the channel between pledge and registrar is not
restricted to TLS, but in connection with constrained BRSKI may
also be DTLS. Also move the references to Constrained BRSKI
and CoAPS to better contexts.
- clarify that the registrar must not be circumvented in the
decision to grant and LDevID, and give hints and
recommendations how to make sure this
- clarify that the cert enrollment phase may involve additional
messages and that BRSKI-AE replaces [RFC8995], Section 5.9
(except Section 5.9.4)
- the certificate enrollment protocol needs to support transport
over (D)TLS only as far as its messages are transported between
pledge and registrar.
- the certificate enrollment protocol chosen between pledge and
registrar needs to be used also for the upstream enrollment
exchange with the PKI only if end-to-end authentication shall
be achieved across the registrar to the PKI.
- add that with CMP, further trust anchors SHOULD be transported
via caPubs
- remove the former Appendix A: "Using EST for Certificate
Enrollment", moving relevant points to the list of scenarios in
Section 1.1: "Supported Scenarios",
- streamline the item on EST in Section 3.2: "Solution Options
for Proof of Identity",
- various minor editorial improvements like making the wording
more consistent
IETF draft ae-02 -> ae-03:
* In response to review by Toerless Eckert,
- many editorial improvements and clarifications as suggested,
such as the comparison to plain BRSKI, the description of
offline vs. synchronous message transfer and enrollment, and
better differentiation of RA flavors.
- clarify that for transporting certificate enrollment messages
between pledge and registrar, the TLS channel established
between these two (via the join proxy) is used and the
enrollment protocol MUST support this.
- clarify that the enrollment protocol chosen between pledge and
registrar MUST also be used for the upstream enrollment
exchange with the PKI.
- extend the description and requirements on how during the
certificate enrollment phase the registrar MAY handle requests
by the pledge itself and otherwise MUST forward them to the PKI
and forward responses to the pledge.
* Change "The registrar MAY offer different enrollment protocols" to
"The registrar MUST support at least one certificate enrollment
protocol ..."
* In response to review by Michael Richardson,
- slightly improve the structuring of the Message Exchange
Section 4.2 and add some detail on the request/response
exchanges for the enrollment phase
- merge the 'Enhancements to the Addressing Scheme' Section 4.3
with the subsequent one: 'Domain Registrar Support of
Alternative Enrollment Protocols'
- add reference to SZTP (RFC 8572)
- extend venue information
- convert output of ASCII-art figures to SVG format
- various small other text improvements as suggested/provided
* Remove the tentative informative application to EST-fullCMC
* Move Eliot Lear from co-author to contributor, add Eliot to the
acknowledgments
* Add explanations for terms such as 'target domain' and 'caPubs'
* Fix minor editorial issues and update some external references
IETF draft ae-01 -> ae-02:
* Architecture: clarify registrar role including RA/LRA/enrollment
proxy
* CMP: add reference to CoAP Transport for CMPV2 and Constrained
BRSKI
* Include venue information
From IETF draft 05 -> IETF draft ae-01:
* Renamed the repo and files from 'anima-brski-async-enroll' to
'anima-brski-ae'
* Added graphics for abstract protocol overview as suggested by
Toerless Eckert
* Balanced (sub-)sections and their headers
* Added details on CMP instance, now called BRSKI-CMP
From IETF draft 04 -> IETF draft 05:
* David von Oheimb became the editor.
* Streamline wording, consolidate terminology, improve grammar, etc.
* Shift the emphasis towards supporting alternative enrollment
protocols.
* Update the title accordingly - preliminary change to be approved.
* Move comments on EST and detailed application examples to
informative annex.
* Move the remaining text of section 3 as two new sub-sections of
section 1.
From IETF draft 03 -> IETF draft 04:
* Moved UC2-related parts defining the pledge in responder mode to a
separate document. This required changes and adaptations in
several sections. Main changes concerned the removal of the
subsection for UC2 as well as the removal of the YANG model
related text as it is not applicable in UC1.
* Updated references to the Lightweight CMP Profile (LCMPP).
* Added David von Oheimb as co-author.
From IETF draft 02 -> IETF draft 03:
* Housekeeping, deleted open issue regarding YANG voucher-request in
UC2 as voucher-request was enhanced with additional leaf.
* Included open issues in YANG model in UC2 regarding assertion
value agent-proximity and CSR encapsulation using SZTP sub
module).
From IETF draft 01 -> IETF draft 02:
* Defined call flow and objects for interactions in UC2. Object
format based on draft for JOSE signed voucher artifacts and
aligned the remaining objects with this approach in UC2 .
* Terminology change: issue #2 pledge-agent -> registrar-agent to
better underline agent relation.
* Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
and pledge-responder-mode to better address the pledge operation.
* Communication approach between pledge and registrar-agent changed
by removing TLS-PSK (former section TLS establishment) and
associated references to other drafts in favor of relying on
higher layer exchange of signed data objects. These data objects
are included also in the pledge-voucher-request and lead to an
extension of the YANG module for the voucher-request (issue #12).
* Details on trust relationship between registrar-agent and
registrar (issue #4, #5, #9) included in UC2.
* Recommendation regarding short-lived certificates for registrar-
agent authentication towards registrar (issue #7) in the security
considerations.
* Introduction of reference to agent signing certificate using SKID
in agent signed data (issue #11).
* Enhanced objects in exchanges between pledge and registrar-agent
to allow the registrar to verify agent-proximity to the pledge
(issue #1) in UC2.
* Details on trust relationship between registrar-agent and pledge
(issue #5) included in UC2.
* Split of use case 2 call flow into sub sections in UC2.
From IETF draft 00 -> IETF draft 01:
* Update of scope in Section 1.1 to include in which the pledge acts
as a server. This is one main motivation for use case 2.
* Rework of use case 2 to consider the transport between the pledge
and the pledge-agent. Addressed is the TLS channel establishment
between the pledge-agent and the pledge as well as the endpoint
definition on the pledge.
* First description of exchanged object types (needs more work)
* Clarification in discovery options for enrollment endpoints at the
domain registrar based on well-known endpoints in Section 4.3 do
not result in additional /.well-known URIs. Update of the
illustrative example. Note that the change to /brski for the
voucher-related endpoints has been taken over in the BRSKI main
document.
* Updated references.
* Included Thomas Werner as additional author for the document.
From individual version 03 -> IETF draft 00:
* Inclusion of discovery options of enrollment endpoints at the
domain registrar based on well-known endpoints in Section 4.3 as
replacement of section 5.1.3 in the individual draft. This is
intended to support both use cases in the document. An
illustrative example is provided.
* Missing details provided for the description and call flow in
pledge-agent use case UC2, e.g. to accommodate distribution of CA
certificates.
* Updated CMP example in Section 5 to use Lightweight CMP instead of
CMP, as the draft already provides the necessary /.well-known
endpoints.
* Requirements discussion moved to separate section in Section 3.
Shortened description of proof-of-identity binding and mapping to
existing protocols.
* Removal of copied call flows for voucher exchange and registrar
discovery flow from [RFC8995] in Section 4 to avoid doubling or
text or inconsistencies.
* Reworked abstract and introduction to be more crisp regarding the
targeted solution. Several structural changes in the document to
have a better distinction between requirements, use case
description, and solution description as separate sections.
History moved to appendix.
From individual version 02 -> 03:
* Update of terminology from self-contained to authenticated self-
contained object to be consistent in the wording and to underline
the protection of the object with an existing credential. Note
that the naming of this object may be discussed. An alternative
name may be attestation object.
* Simplification of the architecture approach for the initial use
case having an off-site PKI.
* Introduction of a new use case utilizing authenticated self-
contain objects to onboard a pledge using a commissioning tool
containing a pledge-agent. This requires additional changes in
the BRSKI call flow sequence and led to changes in the
introduction, the application example,and also in the related
BRSKI-AE call flow.
* Update of provided examples of the addressing approach used in
BRSKI to allow for support of multiple enrollment protocols in
Section 4.3.
From individual version 01 -> 02:
* Update of introduction text to clearly relate to the usage of
IDevID and LDevID.
* Definition of the addressing approach used in BRSKI to allow for
support of multiple enrollment protocols in Section 4.3. This
section also contains a first discussion of an optional discovery
mechanism to address situations in which the registrar supports
more than one enrollment approach. Discovery should avoid that
the pledge performs a trial and error of enrollment protocols.
* Update of description of architecture elements and changes to
BRSKI in Section 4.1.
* Enhanced consideration of existing enrollment protocols in the
context of mapping the requirements to existing solutions in
Section 3 and in Section 5.
From individual version 00 -> 01:
* Update of examples, specifically for building automation as well
as two new application use cases in Appendix A.
* Deletion of asynchronous interaction with MASA to not complicate
the use case. Note that the voucher exchange can already be
handled in an asynchronous manner and is therefore not considered
further. This resulted in removal of the alternative path the
MASA in Figure 1 and the associated description in Section 4.1.
* Enhancement of description of architecture elements and changes to We thank Eliot Lear for his contributions as a co-author at an
BRSKI in Section 4.1. earlier draft stage.
* Consideration of existing enrollment protocols in the context of We thank Brian E. Carpenter, Michael Richardson, and Giorgio
mapping the requirements to existing solutions in Section 3. Romanenghi for their input and discussion on use cases and call
flows.
* New section starting Section 5 with the mapping to existing Moreover, we thank Toerless Eckert (document shepherd); Barry Leiba
enrollment protocols by collecting boundary conditions. (SECdir review); Mahesh Jethanandani (IETF area director); Meral
Shirazipour (Gen-ART reviewer); Reshad Rahman (YANGDOCTORS reviewer);
Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy,
Roman Danyliw, and Éric Vyncke (IESG reviewers); Michael Richardson
(ANIMA design team member); and Rajeev Ranjan, Rufus Buschart,
Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) for
their reviews with suggestions for improvements.
Contributors Contributors
Eliot Lear Eliot Lear
Cisco Systems Cisco Systems
Richtistrasse 7 Richtistrasse 7
CH-8304 Wallisellen CH-8304 Wallisellen
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
 End of changes. 198 change blocks. 
1088 lines changed or deleted 583 lines changed or added

This html diff was produced by rfcdiff 1.48.