]> Siemens AG

Otto-Hahn-Ring 6 Munich 81739 Germany david.von.oheimb@siemens.com https://www.siemens.com/

Siemens AG

Otto-Hahn-Ring 6 Munich 81739 Germany steffen.fries@siemens.com https://www.siemens.com/

Siemens AG

Otto-Hahn-Ring 6 Munich 81739 Germany hendrik.brockhaus@siemens.com https://www.siemens.com/

Operations and Management ANIMA WG Internet-Draft This document defines an enhancement of Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995). It supports alternative certificate enrollment protocols, such as CMP, that use authenticated self-contained signed objects for certification messages. Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction BRSKI is typically used with Enrollment over Secure Transport (EST, ) as the enrollment protocol for operator-specific device certificates, employing HTTP over TLS for secure message transfer. BRSKI-AE is a variant using alternative enrollment protocols with authenticated self-contained objects for the device certificate enrollment. This approach provides the following advantages. The origin of requests and responses can be authenticated independent of message transfer. This supports end-to-end authentication (proof of origin) also over multiple hops, as well as asynchronous operation of certificate enrollment. This in turn provides architectural flexibility where and when to ultimately authenticate and authorize certification requests while retaining full-strength integrity and authenticity of certification requests. This specification carries over the main characteristics of BRSKI, namely: The pledge is assumed to have received its Initial Device IDentifier (IDevID, ) credentials during its production. It uses them to authenticate itself to the Manufacturer Authorized Signing Authority (MASA, ), and to the registrar, which is the access point of the target domain, and to possibly further components of the domain where it will be operated. The pledge first obtains via the voucher exchange a trust anchor for authenticating entities in the domain such as the domain registrar. The pledge then obtains its Locally significant Device IDentifier (IDevID, ). To this end, the pledge generates a private key, called LDevID secret, and requests via the domain registrar from the PKI of its new domain a domain-specific device certificate, called LDevID certificate. On success, it receives the LDevID certificate along with its certificate chain. The goals of BRSKI-AE are to provide an enhancement of BRSKI for LDevID certificate enrollment using, alternatively to EST, a protocol that supports end-to-end authentication over multiple hops enables secure message exchange over any kind of transfer, including asynchronous delivery. Note that the BRSKI voucher exchange of the pledge with the registrar and MASA uses authenticated self-contained objects, so the voucher exchange already has these properties. The well-known URI approach of BRSKI and EST messages is extended with an additional path element indicating the enrollment protocol being used. Based on the definition of the overall approach and specific endpoints, this specification enables the registrar to offer multiple enrollment protocols, from which pledges and their developers can then pick the most suitable one. It may be noted that BRSKI (RFC 8995) specifies how to use HTTP over TLS, but further variants are known, such as Constrained BRSKI using CoAP over DTLS. In the sequel, 'HTTP' and 'TLS' are just references to the most common case, where variants such as using CoAP and/or DTLS are meant to be subsumed - the differences are not relevant here. This specification is sufficient together with its references to support BRSKI with the Certificate Management Protocol (CMP, ) profiled in the Lightweight CMP Profile (LCMPP, ). Combining BRSKI with a protocol or profile other than LCMPP will require additional IANA registrations based on the rules specified in this document. It may also require additional specifications for details of the protocol or profile (similar to ), which are outside the scope of this document.

Supported Scenarios BRSKI-AE is intended to be used in situations like the following. Pledges and/or the target domain reuse an already established certificate enrollment protocol different from EST, such as CMP. The application scenario indirectly excludes the use of EST for certificate enrollment, for reasons like these: The Registration Authority (RA) is not co-located with the registrar while it requires end-to-end authentication of requesters. Yet EST does not support end-to-end authentication over multiple hops. The RA or certification authority (CA) operator requires auditable proof of origin for Certificate Signing Requests (CSRs). This is not possible with TLS because it provides only transient source authentication. Certificates are requested for types of keys, such as Key Encapsulation Mechanism (KEM) keys, that do not support signing (nor alternative forms of single-shot proof of possession like those described in ). This is not supported by EST because it uses CSRs in PKCS #10 format, which can only use proof-of-possession methods that need just a single message, while proof of possession for KEM keys, for instance, requires receiving a fresh challenge value beforehand. The pledge implementation uses security libraries not providing EST support or uses a TLS library that does not support providing the so-called tls-unique value , which is needed by EST for strong binding of the source authentication. No full RA functionality is available on-site in the target domain, while connectivity to an off-site RA may be intermittent or entirely offline. Authoritative actions of a local RA at the registrar is not sufficient for fully and reliably authorizing pledge certification requests. This may be due to missing data access or due to an insufficient level of security, for instance regarding the local storage of private keys. Bootstrapping can be handled in various ways, depending on the application domains. The informative provides illustrative examples from various industrial control system environments and operational setups motivating the support of alternative enrollment protocols.

Terminology and abbreviations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document relies on the terminology defined in , , and . The following terms are described partly in addition.

asynchronous communication:

time-wise interrupted delivery of messages, here between a pledge and the registrar or an RA

authenticated self-contained object:

a data structure that is cryptographically bound to the identity of its originator by an attached digital signature on the actual object, using a private key of the originator such as the IDevID secret.

backend:

placement of a domain component separately from the domain registrar; may be on-site or off-site

BRSKI:

Bootstrapping Remote Secure Key Infrastructure

BRSKI-AE:

BRSKI with Alternative Enrollment, a variation of BRSKI in which BRSKI-EST, the enrollment protocol 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).

CMP:

Certificate Management Protocol

CSR:

Certificate Signing Request

EST:

Enrollment over Secure Transport

IDevID:

Initial Device IDentifier of a pledge, provided by the manufacturer and comprising a private key and the related X.509 certificate with its chain

LDevID:

Locally significant Device IDentifier of a pledge, provided by its target domain and comprising a private key and the related X.509 certificate with its chain

local RA (LRA):

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, and in this case, the LRA is co-located with the registrar.

LCMPP:

Lightweight CMP Profile

MASA:

Manufacturer Authorized Signing Authority

on-site:

locality of a component or service or functionality at the site of the registrar

off-site:

locality of component or service or functionality, such as 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.

pledge:

device that is to be bootstrapped into a target domain. It requests an LDevID using IDevID credentials installed by its manufacturer.

RA:

Registration Authority, the PKI component to which a CA typically delegates certificate management functions such as authenticating pledges and performing authorization checks on certification requests

registrar:

short for domain registrar

site:

the locality where an entity, such as a pledge, registrar, or PKI component is deployed. The target domain may have multiple sites.

synchronous communication:

time-wise uninterrupted delivery of messages, here between a pledge and a registrar or PKI component

target domain:

the domain that a pledge is going to be bootstrapped into

This document utilizes generic terminology regarding PKI management operations to be independent of the terminology of a specific enrollment protocol.

certification request:

message requesting a certificate with proof of identity

certification response:

message providing the answer to a certification request

attribute request:

message requesting content to be included in the certification request

attribute response:

message providing the answer to the attribute request

CA certs request:

message requesting CA certificates

CA certs response:

message providing the answer to a CA certs request

certificate confirm:

message stating to the backend PKI that the requester of a certificate received the new certificate and accepted it

PKI/registrar confirm:

acknowledgment of the PKI on the certificate confirm

Basic Requirements and Mapping to Solutions Based on the intended target scenarios described in and the application examples described in , the following requirements are derived to support authenticated self-contained objects as containers carrying certification requests. The following properties are required for a certification request: Proof of possession: demonstrates access to the private key corresponding to the public key contained in a certification request. This is typically achieved by a self-signature using the corresponding private key but can also be achieved indirectly, see . Proof of identity, also called proof of origin: provides data origin authentication of the certification request. Typically, this is achieved by a signature using the pledge IDevID secret over some data, which needs to include a sufficiently strong identifier of the pledge, such as the device serial number typically included in the subject of the IDevID certificate. The remainder of this section gives a non-exhaustive list of solution examples, based on existing technology described in IETF documents.

Solution Options for Proof of Possession Certificate signing request (CSR) objects: CSRs are data structures protecting only the integrity of the contained data and providing proof of possession for a (locally generated) private key. Important types of CSR data structures are: PKCS #10 . This very common form of CSR is self-signed to protect its integrity and to prove possession of the private key that corresponds to the public key included in the request. Certificate Request Message Format (CRMF, ). This less common but more general CSR format supports several ways of integrity protection and proof of possession. Typically a self-signature is used, which is generated over (part of) the structure with the private key corresponding to the included public key. CRMF also supports further proof-of-possession methods for types of keys that do not have signing capability. For details see . It should be noted that the integrity protection of CSRs includes the public key because it is part of the data signed by the corresponding private key. Yet this signature does not provide data origin authentication, i.e., proof of identity of the requester because the key pair involved is new and therefore does not yet have a confirmed identity associated with it.

Solution Options for Proof of Identity Binding a certificate signing request (CSR) to an existing authenticated credential (the BRSKI context, the IDevID certificate) enables proof of origin, which in turn supports an authorization decision on the CSR. The binding of data origin authentication to the CSR is typically delegated to the protocol used for certificate management. This binding may be achieved through security options in an underlying transport protocol such as TLS if the authorization of the certification request is (sufficiently) done at the next communication hop. Depending on the key type, the binding can also be done in a stronger, transport-independent way by wrapping the CSR with a signature. This requirement is addressed by existing enrollment protocols in various ways, such as: EST , also its variant EST-coaps , utilizes PKCS #10 to encode Certificate Signing Requests (CSRs). While such a CSR has not been designed to include proof of origin, there is a limited, indirect way of binding it to the source authentication of the underlying TLS session. This is achieved by including in the CSR the tls-unique value resulting from the TLS handshake. As this is optionally supported by the EST "/simpleenroll" endpoint used in BRSKI and the TLS handshake employed in BRSKI includes certificate-based client authentication of the pledge with its IDevID credentials, the proof of pledge identity being an authenticated TLS client can be bound to the CSR. Yet this binding is only valid in the context of the TLS session established with the registrar acting as the EST server and typically also as an RA. So even such a cryptographic binding of the authenticated pledge identity to the CSR is not visible nor verifiable to authorization points outside the registrar, such as a (second) RA in the backend. What the registrar needs to do is to authenticate and pre-authorize the pledge and to indicate this to the (second) RA by signing the forwarded certification request with its private key and a related certificate that has the id-kp-cmcRA extended key usage attribute. sketches wrapping PKCS #10-formatted CSRs with a Full PKI Request message sent to the "/fullcmc" endpoint. This would allow for source authentication at the message level, such that the registrar could forward it to external RAs in a meaningful way. This approach is so far not sufficiently described and likely has not been implemented. SCEP supports using a shared secret (passphrase) or an existing certificate to protect CSRs based on SCEP Secure Message Objects using CMS wrapping (). Note that the wrapping using an existing IDevID in SCEP is referred to as 'renewal'. This way SCEP does not rely on the security of the underlying message transfer. CMP supports using a shared secret (passphrase) or an existing certificate, which may be an IDevID credential, to authenticate certification requests via the PKIProtection structure in a PKIMessage. The certification request is typically encoded utilizing CRMF, while PKCS #10 is supported as an alternative. Thus, CMP does not rely on the security of the underlying message transfer. CMC also supports utilizing a shared secret (passphrase) or an existing certificate to protect certification requests, which can be either in CRMF or PKCS #10 structure. The proof of identity can be provided as part of a FullCMCRequest, based on CMS and signed with an existing IDevID secret. Thus, CMC does not rely on the security of the underlying message transfer. To sum up, EST does not meet the requirements for authenticated self-contained objects, but SCEP, CMP, and CMC do. This document primarily focuses on CMP as it has more industry adoption than CMC and SCEP has issues not detailed here.

Adaptations to BRSKI To enable using alternative certificate enrollment protocols supporting end-to-end authentication, asynchronous enrollment, and more general system architectures, BRSKI-AE provides some generalizations on BRSKI . This way, authenticated self-contained objects such as those described in above can be used for certificate enrollment, and RA functionality can be deployed freely in the target domain. Parts of the RA functionality can even be distributed over several nodes. The enhancements are kept to a minimum to ensure the reuse of already defined architecture elements and interactions. In general, the communication follows the BRSKI model and utilizes the existing BRSKI architecture elements. In particular, the pledge initiates communication with the domain registrar and interacts with the MASA as usual for voucher request and response processing.

Architecture The key element of BRSKI-AE is that the authorization of a certification request MUST be performed based on an authenticated self-contained object. The certification request is bound in a self-contained way to a proof of origin based on the IDevID credentials. Consequently, the certification request MAY be transferred using any mechanism or protocol. Authentication and authorization of the certification request can be done by the domain registrar and/or by backend domain components. As mentioned in , these components may be offline or off-site. The registrar and other on-site domain components may have no or only temporary (intermittent) connectivity to them. This leads to generalizations in the placement and enhancements of the logical elements as shown in .

| Proxy |<-------->| Registrar w/ | . | | . |.......| | LRA or RA | . | IDevID | . +-------+ +--------------+ . | | BRSKI-AE over TLS ^ . +--------+ using, e.g., LCMPP | . . | . ...............................|......... on-site (local) domain components | | e.g., LCMPP | .............................................|.................. . Public-Key Infrastructure v . . +---------+ +------------------------------------------+ . . | |<----+ Registration Authority | . . | CA +---->| RA (unless part of Domain Registrar) | . . +---------+ +------------------------------------------+ . ................................................................ backend (central or off-site) domain components ]]>

The architecture overview in has the same logical elements as BRSKI, but with a more flexible placement of the authentication and authorization checks on certification requests. Depending on the application scenario, the registrar MAY still do all of these checks (as is the case in BRSKI), or part of them. The following list describes the on-site components in the target domain of the pledge shown in . Join Proxy: same requirements as in BRSKI, see Domain Registrar including LRA or RA functionality: in BRSKI-AE, the domain registrar has mostly the same functionality as in BRSKI, namely to act as the gatekeeper of the domain for onboarding new devices and to facilitate the communication of pledges with their MASA and the domain PKI. Yet there are some generalizations and specific requirements: The registrar MUST support at least one certificate enrollment protocol with authenticated self-contained objects for certification requests. To this end, the URI scheme for addressing endpoints at the registrar is generalized (see ). Rather than having full RA functionality, the registrar MAY act as a local registration authority (LRA) and delegate part of its involvement in certificate enrollment to a backend RA. In such scenarios, the registrar optionally checks certification requests it receives from pledges and forwards them to the backend RA, which performs the remaining parts of the enrollment request validation and authorization. Note that to this end the backend RA may need information regarding the authorization of pledges from the registrar or from other sources. On the way back, the registrar forwards responses by the PKI to the pledge on the same channel. To support end-to-end authentication of the pledge across the registrar to the backend RA, the certification request signed by the pledge needs to be upheld and forwarded by the registrar. Therefore, the registrar cannot use for its communication with the PKI an enrollment protocol that is different from the enrollment protocol used between the pledge and the registrar. The use of a certificate enrollment protocol with authenticated self-contained objects gives freedom how to transfer enrollment messages between the pledge and an RA. BRSKI demands that the RA accept certification requests for LDevIDs only with the consent of the registrar. BRSKI-AE guarantees this also in case that the RA is not part of the registrar, even if the message exchange with backend systems is unprotected and involves further transport hops. See for details on how this can be achieved. Despite the above generalizations to the enrollment phase, the final step of BRSKI, namely the enrollment status telemetry, is kept as it is. The following list describes the components provided by the vendor or manufacturer outside the target domain. MASA: functionality as described in BRSKI . The voucher exchange with the MASA via the domain registrar is performed as described in BRSKI. Note: From the definition of the interaction with the MASA in follows that it may be synchronous (using voucher request with nonces) or asynchronous (using nonceless voucher requests). Ownership tracker: as defined in BRSKI. The following list describes backend target domain components, which may be located on-site or off-site in the target domain. RA: performs centralized certificate management functions as a public-key infrastructure for the domain operator. As far as not already done by the domain registrar, it performs the final validation and authorization of certification requests. Otherwise, the RA co-located with the domain registrar directly connects to the CA. CA, also called domain CA: generates domain-specific certificates according to certification requests that have been authenticated and authorized by the registrar and/or an extra RA. Based on the diagram in BRSKI and the architectural changes, the original protocol flow is divided into several phases showing commonalities and differences to the original approach as follows. Discovery phase: mostly as in BRSKI step (1). For details see . Identification phase: same as in BRSKI step (2). Voucher exchange phase: same as in BRSKI steps (3) and (4). Voucher status telemetry: same as in BRSKI directly after step (4). Certificate enrollment phase: the use of EST in step (5) is changed to employing a certificate enrollment protocol that uses an authenticated self-contained object for requesting the LDevID certificate. For transporting the certificate enrollment request and response messages, the (D)TLS channel established between pledge and registrar is MANDATORY to use. To this end, the enrollment protocol, the pledge, and the registrar need to support the use of this existing channel for certificate enrollment. Due to this architecture, the pledge does not need to establish additional connections for certificate enrollment and the registrar retains full control over the certificate enrollment traffic. Enrollment status telemetry: the final exchange of BRSKI step (5).

Message Exchange The behavior of a pledge described in BRSKI is kept, with one major exception. After finishing the Imprint step (4), the Enroll step (5) MUST be performed with an enrollment protocol utilizing authenticated self-contained objects, as explained in . discusses selected suitable enrollment protocols and options applicable. An abstract overview of the BRSKI-AE protocol can be found at .

Pledge - Registrar Discovery Discovery as specified in BRSKI does not support the discovery of registrars with enhanced feature sets. A pledge can not find out in this way whether discovered registrars support the certificate enrollment protocol it expects, such as CMP. As a more general solution, the BRSKI discovery mechanism can be extended to provide up-front information on the capabilities of registrars. Future work such as may provide this. In the absence of such a generally applicable solution, BRSKI-AE deployments may use their particular way of doing discovery. defines a minimalist approach that MAY be used for CMP.

Pledge - Registrar - MASA Voucher Exchange The voucher exchange is performed as specified in .

Pledge - Registrar - MASA Voucher Status Telemetry The voucher status telemetry is performed as specified in .

Pledge - Registrar - RA/CA Certificate Enrollment This replaces the EST integration for PKI bootstrapping described in (while remains as the final phase, see below). The certificate enrollment phase may involve the transmission of several messages. Details can depend on the application scenario, the employed enrollment protocol, and other factors. The only message exchange REQUIRED is for the actual certification request and response. Further message exchanges MAY be performed as needed. Note: The message exchanges marked OPTIONAL in the below cover all those supported by the use of EST in BRSKI. The last OPTIONAL one, namely certificate confirmation, is not supported by EST, but by CMP and other enrollment protocols.

| | | | [OPTIONAL forwarding] | | |----- CA Certs Request ------->| | |<---- CA Certs Response -------| |<-------- CA Certs Response (2) ---------| | | | | | [OPTIONAL request of attributes | | | to include in Certification Request] | | |--------- Attribute Request (3) -------->| | | | [OPTIONAL forwarding] | | |----- Attribute Request ------>| | |<---- Attribute Response ------| |<-------- Attribute Response (4) --------| | | | | | [REQUIRED certification request] | | |--------- Certification Request (5) ---->| | | | [OPTIONAL forwarding] | | |---- Certification Request --->| | |<--- Certification Response ---| |<-------- Certification Response (6) ----| | | | | | [OPTIONAL certificate confirmation] | | |--------- Certificate Confirm (7) ------>| | | | [OPTIONAL forwarding] | | |----- Certificate Confirm ---->| | |<---- PKI Confirm -------------| |<-------- PKI/Registrar Confirm (8) -----| | ]]>

It may be noted that connections between the registrar and the PKI components of the operator (RA, CA, etc.) may be intermittent or off-line. Messages should be sent as soon as sufficient transfer capacity is available. The label [OPTIONAL forwarding] in means that on receiving from a pledge a request message of the given type, the registrar MAY answer the request directly. In this case, it MUST authenticate its responses with the same credentials as used for authenticating itself at the TLS level for the voucher exchange. Otherwise, the registrar MUST forward the request to the RA and forward any resulting response back to the pledge. The decision of whether to forward a request or to answer it directly can depend on various static and dynamic factors. They include the application scenario, the capabilities of the registrar and of the local RA possibly co-located with the registrar, the enrollment protocol being used, and the specific contents of the request. Note that there are several options for how the registrar could be able to directly answer requests for CA certificates or for certification request attributes. It could cache responses obtained from the domain PKI and later use their contents for responding to requests asking for the same data. The contents could also be explicitly provisioned at the registrar. Further note that certification requests typically need to be handled by the backend PKI, but the registrar can answer them directly with an error response in case it determines that such a request should be rejected, for instance, because is not properly authenticated or not authorized. Also, certificate confirmation messages will usually be forwarded to the backend PKI, but if the registrar knows that they are not needed or wanted there it can acknowledge such messages directly. The following list provides an abstract description of the flow depicted in . CA Certs Request (1): The pledge optionally requests the latest relevant CA certificates. This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain-cert (which is contained in the voucher and which may be just the domain registrar certificate). CA Certs Response (2): This MUST contain any intermediate CA certificates that the pledge may need to validate certificates and MAY contain the LDevID trust anchor. Attribute Request (3): Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. Nevertheless, there are cases in which the pledge may also include in the Certification Request (5) additional attributes that are specific to the target domain. To get these attributes in advance, the attribute request may be used. Attribute Response (4): This MUST contain the attributes requested in (3) to be included in the subsequent Certification Request (5). For example, specifies how the attribute request is used to signal to the pledge the acp-node-name field required for enrollment into an ACP domain. Certification Request (5): This MUST contain the authenticated self-contained object ensuring both the proof of possession of the corresponding private key and the proof of identity of the requester. Certification Response (6): This MUST contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs and any additional trust anchors. Certificate Confirm (7): An optional confirmation sent after the requested certificate has been received and validated. If sent, it MUST contain a positive or negative confirmation by the pledge to the PKI whether the certificate was successfully enrolled and fits its needs. PKI/Registrar Confirm (8): An acknowledgment by the PKI that MUST be sent on reception of the Certificate Confirm. The generic messages described above may be implemented using any certificate enrollment protocol that supports authenticated self-contained objects for the certification request as described in . Examples are available in . Note that the optional certificate confirmation by the pledge to the PKI described above is independent of the mandatory enrollment status telemetry done between the pledge and the registrar in the final phase of BRSKI-AE, described next.

Pledge - Registrar Enrollment Status Telemetry The enrollment status telemetry is performed as specified in . In BRSKI this is described as part of the certificate enrollment step, but due to the generalization on the enrollment protocol described in this document it is regarded as a separate phase here.

Enhancements to the Endpoint Addressing Scheme of BRSKI BRSKI-AE provides generalizations to the addressing scheme defined in BRSKI to accommodate alternative enrollment protocols that use authenticated self-contained objects for certification requests. In existing RAs/CAs supporting such an enrollment protocol (see also ), these generalizations can be employed without modifications. The addressing scheme in BRSKI for certification requests and the related CA certificates and CSR attributes retrieval functions uses the definition from EST . Here is the example of simple enrollment: "/.well-known/est/simpleenroll". This approach is generalized to the following notation: "/.well-known/<enrollment-protocol>/<request>" in which <enrollment-protocol> refers to a certificate enrollment protocol. Note that enrollment is considered here a message sequence that contains at least a certification request and a certification response. The following conventions are used to provide maximal compatibility with BRSKI: <enrollment-protocol>: MUST reference the protocol being used. Existing values include 'est' as in BRSKI and 'cmp' as in and below. Values for other existing protocols such as CMC and SCEP, as well as for newly defined protocols are outside the scope of this document. For use of the <enrollment-protocol> and <request> URI components, they would need to be specified in a suitable RFC and placed into the Well-Known URIs registry, just as EST in . <request>: if present, this path component MUST describe, depending on the enrollment protocol being used, the operation requested. Enrollment protocols are expected to define their request endpoints, as done by existing protocols (see also ). Well-known URIs for various endpoints on the domain registrar are already defined as part of the base BRSKI specification or indirectly by EST. In addition, alternative enrollment endpoints MAY be supported by the registrar. A pledge SHOULD use the endpoints defined for the enrollment protocol(s) that it can use. It will recognize whether the protocol it uses and the specific request it wants to perform are understood and supported by the domain registrar by sending the request to the respective endpoint according to the above addressing scheme and then evaluating the HTTP status code of the response. If the pledge uses endpoints that are not standardized, it risks that the registrar does not recognize a request and thus may reject it, even if the registrar supports the intended protocol and operation. The following list of endpoints provides an illustrative example of a domain registrar supporting several options for EST as well as for CMP to be used in BRSKI-AE. The listing contains the supported endpoints to which the pledge may connect for bootstrapping. This includes the voucher handling as well as the enrollment endpoints. The CMP-related enrollment endpoints are defined as well-known URIs in CMP Updates and the Lightweight CMP Profile .

Instantiation with Existing Enrollment Protocols This section maps the generic requirements to support proof of possession and proof of identity to selected existing certificate enrollment protocols and specifies further aspects of using such enrollment protocols in BRSKI-AE.

BRSKI-CMP: BRSKI-AE instantiated with CMP Instead of referring to CMP as specified in and , this document refers to the Lightweight CMP Profile (LCMPP) because the subset of CMP defined there is sufficient for the functionality needed here. When using CMP, adherence to the LCMPP is REQUIRED. In particular, the following specific requirements apply (cf. ). CA Certs Request (1) and Response (2):
Requesting CA certificates is OPTIONAL.
If supported, it SHALL be implemented as specified in . Attribute Request (3) and Response (4):
Requesting certification request attributes is OPTIONAL.
If supported, it SHALL be implemented as specified in . Alternatively, the registrar MAY modify the contents of the requested certificate contents as specified in . Certification Request (5) and Response (6):
Certificates SHALL be requested and provided as specified in the LCMPP (based on CRMF) or (based on PKCS #10). Proof of possession SHALL be provided in a way suitable for the key type. Proof of identity SHALL be provided by signature-based protection of the certification request message as outlined in using the IDevID secret. When the registrar forwards a certification request by the pledge to a backend RA/CA, the registrar is RECOMMENDED to wrap the original certification request in a nested message signed with its own credentials as described in . This explicitly conveys the consent by the registrar to the RA while retaining the original certification request message with its proof of origin provided by the pledge signature. In case additional trust anchors (besides the pinned-domain-cert) need to be conveyed to the pledge, this SHOULD be done in the caPubs field of the certification response rather than in a CA Certs Response. Certificate Confirm (7) and PKI/Registrar Confirm (8):
Explicit confirmation of new certificates to the RA/CA MAY be used as specified in . Note that independently of the certificate confirmation within CMP, enrollment status telemetry with the registrar at BRSKI level will be performed as described in . If delayed delivery of CMP messages is needed (for instance, to support enrollment over an asynchronous channel), it SHALL be performed as specified in Section and Section of . How messages are exchanged between the registrar and backend PKI components (i.e., RA and/or CA) is out of scope of this document. Since CMP is independent of message transfer, the mechanism for this exchange can be freely chosen according to the needs of the application scenario. For the applicable security considerations, see . Further guidance can be found in . BRSKI-AE with CMP can also be combined with Constrained BRSKI , using CoAP for enrollment message transport as described by CoAP Transport for CMP . In this scenario, the EST-specific parts of do not apply. For BRSKI-AE scenarios where a general solution (cf. ) for discovering registrars with CMP support is not available, the following minimalist approach MAY be used. Perform discovery as defined in BRSKI but using the service name "brski-registrar-cmp" (defined in ) instead of "brski-registrar" (defined in ). Note that this approach does not support join proxies.

Support of Other Enrollment Protocols Further instantiations of BRSKI-AE can be done. They are left for future work. In particular, CMC (using its in-band source authentication options) and SCEP (using its 'renewal' option) could be used. The fullCMC variant of EST sketched in might also be used here. For EST-fullCMC further specification is necessary.

IANA Considerations This document requires one IANA action: register in the Service Name and Transport Protocol Port Number Registry the following service name. Service Name: brski-registrar-cmp
Transport Protocol(s): tcp
Assignee: IESG iesg@ietf.org
Contact: IESG iesg@ietf.org
Description: Bootstrapping Remote Secure Key Infrastructure registrar with CMP capabilities according to the Lightweight CMP Profile (LCMPP, )
Reference: [THISRFC] Note: We chose here the suffix "cmp" rather than some other abbreviation like "lcmpp" mainly because this document defines the normative CMP instantiation of BRSKI-AE, which implies adherence to LCMPP is necessary and sufficient.

Security Considerations The security considerations laid out in BRSKI apply to the discovery and voucher exchange as well as for the status exchange information. In particular, even if the registrar delegates part or all of its RA role during certificate enrollment to a separate system, it still must be made sure that the registrar takes part in the decision on accepting or declining a request to join the domain, as required in . As this pertains also to obtaining a valid domain-specific certificate, it must be made sure that a pledge can not circumvent the registrar in the decision of whether it is granted an LDevID certificate by the CA. There are various ways how to fulfill this, including: implicit consent the registrar signals its consent to the RA out-of-band before or during the enrollment phase, for instance by entering the pledge identity in a database. the registrar provides its consent using an extra message that is transferred on the same channel as the enrollment messages, possibly in a TLS tunnel. the registrar explicitly states its consent by signing, in addition to the pledge, the authenticated self-contained certificate enrollment request message. Note: If EST was used, the registrar could give implicit consent on a certification request by forwarding the request to a PKI entity using a connection authenticated with a certificate containing an id-kp-cmcRA extension. When CMP is used, the security considerations laid out in the LCMPP apply. Note that CMP messages are not encrypted. This may give eavesdroppers insight into which devices are bootstrapped into the domain, and this in turn might also be used to selectively block the enrollment of certain devices. To prevent this, the underlying message transport channel can be encrypted. This is already provided by TLS between the pledge and the registrar, and for the onward exchange with backend systems, encryption may need to be added.

Acknowledgments We thank Eliot Lear for his contributions as a co-author at an earlier draft stage. We thank Brian E. Carpenter, Michael Richardson, and Giorgio Romanenghi for their input and discussion on use cases and call flows. Moreover, we thank Toerless Eckert (document shepherd), Barry Leiba (SECdir review), Mahesh Jethanandani (IETF area director), Meral Shirazipour (Gen-ART reviewer), 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.

This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. IEEE In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. Graphics on slide 4 of the status update on the BRSKI-AE draft 04 at IETF 116. This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK] This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding). Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK] This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm. This document obsoletes RFC 2875. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates. Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. This document contains a set of updates to the syntax of Certificate Management Protocol (CMP) version 2 and its HTTP transfer mechanism. This document updates RFCs 4210, 5912, and 6712. The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments. CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signal the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed. This document specifies the use of the Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space. International Electrotechnical Commission North American Reliability Council International Standardization Organization / International Electrotechnical Commission UNISIG http://www.kmc-subset137.eu/index.php/download/ Open Charge Alliance Futurewei USA Siemens AG IoTconsultancy.nl This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting as initiators.

Application Examples This informative annex provides some detail about application examples.

Rolling Stock Rolling stock or railroad cars contain a variety of sensors, actuators, and controllers, which communicate within the railroad car but also exchange information between railroad cars forming a train, with track-side equipment, and/or possibly with backend systems. These devices are typically unaware of backend system connectivity. Enrolling certificates may be done during maintenance cycles of the railroad car, but can already be prepared during operation. Such asynchronous enrollment will include generating certification requests, which are collected and later forwarded for processing whenever the railroad car gets connectivity with the backend PKI of the operator. The authorization of the certification request is then done based on the operator's asset/inventory information in the backend. UNISIG has included a CMP profile for the enrollment of TLS client and server X.509 certificates of on-board and track-side components in the Subset-137 specifying the ETRAM/ETCS online key management for train control systems .

Building Automation In building automation scenarios, a detached building or the basement of a building may be equipped with sensors, actuators, and controllers that are connected to each other in a local network but with only limited or no connectivity to a central building management system. This problem may occur during installation time but also during operation. In such a situation a service technician collects the necessary data and transfers it between the local network and the central building management system, e.g., using a laptop or a mobile phone. This data may comprise parameters and settings required in the operational phase of the sensors/actuators, like a component certificate issued by the operator to authenticate against other components and services. The collected data may be provided by a domain registrar already existing in the local network. In this case connectivity to the backend PKI may be facilitated by the service technician's laptop. Alternatively, the data can also be collected from the pledges directly and provided to a domain registrar deployed in a different network in preparation for the operational phase. In this case, connectivity to the domain registrar may also be facilitated by the service technician's laptop.

Substation Automation In electrical substation automation scenarios, a control center typically hosts PKI services to issue certificates for Intelligent Electronic Devices operated in a substation. Communication between the substation and control center is performed through a proxy/gateway/DMZ, which terminates protocol flows. Note that requires inspection of protocols at the boundary of a security perimeter (the substation in this case). In addition, security management in substation automation assumes central support of several enrollment protocols to support the various capabilities of IEDs from different vendors. The IEC standard IEC62351-9 specifies for the infrastructure side mandatory support of two enrollment protocols: SCEP and EST , while an Intelligent Electronic Device may support only one of them.

Electric Vehicle Charging Infrastructure For electric vehicle charging infrastructure, protocols have been defined for the interaction between the electric vehicle and the charging point (e.g., ISO 15118-2 ) as well as between the charging point and the charging point operator (e.g. OCPP ). Depending on the authentication model, unilateral or mutual authentication is required. In both cases, the charging point uses an X.509 certificate to authenticate itself in TLS channels between the electric vehicle and the charging point. The management of this certificate depends, among others, on the selected backend connectivity protocol. In the case of OCPP, this protocol is meant to be the only communication protocol between the charging point and the backend, carrying all information to control the charging operations and maintain the charging point itself. This means that the certificate management needs to be handled in-band of OCPP. This requires the ability to encapsulate the certificate management messages in a transport-independent way. Authenticated self-containment will support this by allowing the transport without a separate enrollment protocol, binding the messages to the identity of the communicating endpoints.

Infrastructure Isolation Policy This refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. In such a case, limited access to external PKI services will be allowed in carefully controlled short periods of time, for example when a batch of new devices is deployed, and forbidden or prevented at other times.

Sites with Insufficient Level of Operational Security The RA performing (at least part of) the authorization of a certification request is a critical PKI component and therefore requires higher operational security than components utilizing the issued certificates for their security features. CAs may also demand higher security in the registration procedures from RAs, which domain registrars with co-located RAs may not be able to fulfill. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates, i.e., those placed in trust stores of browsers, which may be used to connect with devices in the domain. In case the on-site components of the target domain can not be operated securely enough for the needs of an RA, this service should be transferred to an off-site backend component that has a sufficient level of security.

History of Changes TBD RFC Editor: please delete List of reviewers: Toerless Eckert (document shepherd) Barry Leiba (SECdir) Mahesh Jethanandani (IETF area director) Meral Shirazipour (Gen-ART reviewer) Michael Richardson (ANIMA design team) Rajeev Ranjan, Rufus Buschart, Szofia Fazekas-Zisch, etc. (Siemens) YANGDOCTORS Early review of 2021-08-15 referred to the PRM aspect of 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-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 Minor fix in 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 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 IETF draft ae-06 -> ae-07: Update subsections on discovery according to discussion in the design team In , 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 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 (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 : "Supported Scenarios", streamline the item on EST in : "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 and add some detail on the request/response exchanges for the enrollment phase merge the 'Enhancements to the Addressing Scheme' 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 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 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 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 to use Lightweight CMP instead of CMP, as the draft already provides the necessary /.well-known endpoints. Requirements discussion moved to separate section in . 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 in 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 . 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 . 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 . Enhanced consideration of existing enrollment protocols in the context of mapping the requirements to existing solutions in and in . From individual version 00 -> 01: Update of examples, specifically for building automation as well as two new application use cases in . 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 . Enhancement of description of architecture elements and changes to BRSKI in . Consideration of existing enrollment protocols in the context of mapping the requirements to existing solutions in . New section starting with the mapping to existing enrollment protocols by collecting boundary conditions.

Contributors Cisco Systems

Richtistrasse 7 Wallisellen CH-8304 Switzerland +41 44 878 9200 lear@cisco.com