]> 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 enhances Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) to allow employing alternative enrollment protocols, such as CMP. Using self-contained signed objects, the origin of enrollment requests and responses can be authenticated independently of message transfer. This supports end-to-end security and asynchronous operation of certificate enrollment and provides flexibility where to authenticate and authorize certification requests. Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction

Motivation BRSKI, as defined in , specifies a solution for secure automated zero-touch bootstrapping of new devices, which are given the name pledges, in the domain they should operate with. This includes the discovery of the registrar representing the target domain, time synchronization or validation, and the exchange of security information necessary to establish mutual trust between pledges and the target domain. As explained in , the target domain, or domain for short, is defined as the set of entities that share a common local trust anchor.

Voucher Exchange for Trust Anchor Establishment Initially, a pledge has a trust anchor only of its manufacturer, not yet of any target domain. In order for the pledge to automatically and securely obtain trust in a suitable target domain represented by its registrar, BRSKI uses vouchers as defined in . A voucher is a cryptographic object issued by the Manufacturer Authorized Signing Authority (MASA) of the pledge manufacturer to the specific pledge identified by the included device serial number. It is signed with the credentials of the MASA and can be validated by the manufacturer trust anchor imprinted with the pledge. So the pledge can accept the voucher contents, which indicate to the pledge that it can trust the domain identified by the given certificate. While RFC 8995 only specifies a single, online set of protocol option to communicate the voucher between MASA, registrar, and pledge (BRSKI-EST and BRSKI-MASA, see ), it also describes the architecture for how the voucher may be provided in online mode (synchronously) or offline mode (asynchronously). So for the voucher exchange offline mode is basically supported because the vouchers are self-contained signed objects, such that their security does not rely on protection by the underlying transfer. SZTP is an example of another protocol where vouchers may be delivered asynchronously by tools such as portable USB "thumb" drives. However, SZTP does not do signed voucher requests, so it does not allow the domain to verify the identity of the device in the same way, nor does it deploy LDevIDs to the device in the same way.

Enrollment of LDevID Certificate Trust in a pledge by other devices in the target domain is enabled by enrolling the pledge with a domain-specific Locally significant Device IDentity (LDevID) certificate. Recall that for certificate enrollment it is crucial to authenticate the entity requesting the certificate. Checking both the identity and the authorization of the requester is the job of a registration authority (RA). With BRSKI-EST, there is only one RA instance, co-located with the registrar. The certification request of the pledge is signed using its IDevID secret. It can be validated by the target domain (e.g., by the domain registrar) using the trust anchor of the pledge manufacturer, which needs to pre-installed in the domain. For enrolling devices with LDevID certificates, BRSKI specifies how Enrollment over Secure Transport (EST) can be used. EST has its specific characteristics, detailed in . In particular, it requires online on-site availability of the RA for performing the data origin authentication and final authorization decision on the certification request. This type of enrollment can be called 'synchronous enrollment'. EST, BRSKI-EST, and BRSKI-MASA as used in RFC 8995 are tied to a specific transport, TLS, which may not be suitable for the target use case outlined by the examples in . Therefore deployments may require different transport, see Constrained Voucher Artifacts for Bootstrapping Protocols and EST-coaps . Since EST does not support offline enrollment, it may be preferable for the reasons given in this section and depending on application scenarios as outlined in and to use alternative enrollment protocols such as the Certificate Management Protocol (CMP) profiled in or Certificate Management over CMS (CMC) . These protocols are more flexible, and by representing the certification request messages as authenticated self-contained objects, they are designed to be independent of the transfer mechanism. Depending on the application scenario, the required components of an RA may not be part of the BRSKI registrar. They even may not be available on-site but rather be provided by remote backend systems. The RA functionality may also be split into an on-site local RA (LRA) and a central RA component in the backend, referred to as PKI RA. For certification authorities (CAs) it is common to be located in the backend. The registrar or its deployment site may not have an online connection with these RA/CA components or the connectivity may be intermittent. This may be due to security requirements for operating the backend systems or due to deployments where on-site or always-online operation may be not feasible or too costly. In such scenarios, the authentication and authorization of certification requests will not or can not be performed on-site. In this document, enrollment that is not performed over an online connection is called 'asynchronous enrollment'. Asynchronous enrollment means that messages need to be forwarded through offline methods (e.g., Sneakernet/USB sticks) and/or at some point in time only part of the communication path is available. Messages need to be stored, along with the information needed for authenticating their origin, in front of an unavailable segment for potentially long time (e.g., days) before they can be forwarded. This implies that end-to-end security between the parties involved can not be provided by an authenticated (and often confidential) communications channel such as TLS used in EST/BRSKI-EST/BRSKI-MASA. Application scenarios may also involve network segmentation, which is utilized in industrial systems to separate domains with different security needs -- see also . Such scenarios lead to similar requirements if the TLS channel that carries the requester authentication is terminated before the actual requester authorization is performed. Thus request messages need to be forwarded on further channels before the registrar or RA can authorize the certification request. In order to preserve the requester authentication, authentication information needs to be retained and ideally bound directly to the certification request. There are basically two approaches for forwarding certification requests along with requester authentication information: The component in the target domain that forwards the certification request, such as a local RA being part of the registrar, combines the certification request with the validated identity of the requester (e,g., its IDevID certificate) and an indication of successful verification of the proof of possession (of the corresponding private key) in a way preventing changes to the combined information. This implies that it must be trusted by the PKI. When connectivity is available, the trusted component forwards the certification request together with the requester information (authentication and proof of possession) for further processing. This approach offers hop-by-hop security, but not end-to-end security. In BRSKI, the EST server, being co-located with the registrar in the domain, is such a component that needs to be trusted by the backend PKI components. They must rely on the local pledge authentication result provided by that component when performing the final authorization of the certification request. A trusted intermediate domain component is not needed when involved components use authenticated self-contained objects for the enrollment, directly binding the certification request and the requester authentication in a cryptographic way. This approach supports end-to-end security, without the need to trust in intermediate domain components. Manipulation of the request and the requester identity information can be detected during the validation of the self-contained signed object. Note that with this approach the way in which enrollment requests are forwarded by the registrar to the backend PKI components does not contribute to their security and therefore does not need to be addressed here. Focus of this document is the support of alternative enrollment protocols that allow the second approach, i.e., using authenticated self-contained objects for device certificate enrollment. This enhancement of BRSKI is named BRSKI-AE, where AE stands for Alternative Enrollment and for Asynchronous Enrollment. This specification carries over the main characteristics of BRSKI, namely that the pledge obtains trust anchor information for authenticating the domain registrar and other target domain components as well as a domain-specific X.509 device certificate (the LDevID certificate) along with the corresponding private key (the LDevID secret) and certificate chain. The goals are to provide an enhancement of BRSKI using enrollment protocols alternatively to EST that support end-to-end security for LDevID certificate enrollment and make it applicable to scenarios involving asynchronous enrollment. This is achieved by extending the well-known URI approach of BRSKI and EST message with an additional path element indicating the enrollment protocol being used, and defining a certificate waiting indication and handling, for the case that the certifying component is (temporarily) not available. This specification can be applied to both synchronous and asynchronous enrollment. As an improvement over BRSKI, this specification supports offering multiple enrollment protocols which enables pledges and their developers to pick the preferred one.

Supported Environments BRSKI-AE is intended to be used in domains that may have limited support of on-site PKI services and comprises application scenarios like the following. Scenarios indirectly excluding the use of EST for certificate enrollment, such as the requirement for end-to-end authentication of the requester while the RA is not co-located with the registrar. Scenarios having implementation restrictions that speak against using EST for certificate enrollment, such as the use of a library that does not support EST but CMP. Pledges and/or the target domain already having an established certificate management approach different from EST that shall be reused (e.g., in brownfield installations where CMP is used). No RA being available on site in the target domain. Connectivity to an off-site PKI RA is intermittent or entirely offline. A store-and-forward mechanism is used for communicating with the off-site services. Authoritative actions of a local RA being not sufficient for fully authorizing certification requests by pledges. Final authorization then is done by a PKI RA residing in the backend.

List of Application Examples 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. They motivate the support of alternative enrollment protocols, based on the following examples of operational environments: Rolling stock Building automation Electrical substation automation Electric vehicle charging infrastructures Infrastructure isolation policy Sites with insufficient level of operational security

Terminology 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 defined partly in addition.

asynchronous communication:

time-wise interrupted communication between a pledge and a registrar or PKI component.

authenticated self-contained object:

data structure that is cryptographically bound to the IDevID certificate of a pledge. The binding is assumed to be provided through a digital signature of the actual object using the IDevID secret.

backend:

same as off-site

BRSKI-AE:

Variation of BRSKI in which BRSKI-EST, the enrollment protocol between pledge and the registrar including the RA, is replaced by alternative enrollment protocols such as Lightweight CMP. To this end a new URI scheme used for performing the certificate enrollment. BRSKI-AE enables the use of other enrollment protocols between pledge and registrar and to any backend RA components with end-to-end security.

CA:

Certification Authority, which is the PKI component that issues certificates and provides certificate status information.

domain:

shorthand for target domain

IDevID:

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

LDevID:

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

local RA (LRA):

RA that is on site with the registrar and that may be needed in addition to an off-site RA.

on-site:

locality of a component or service or functionality in the local target deployment site of the registrar.

off-site:

locality of component or service or functionality in an operator site different from the target deployment site. This may be a central site or a cloud service, to which only a temporary connection is available.

PKI RA:

off-site RA in the backend of the target domain

pledge:

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

RA:

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

site:

the locality where an entity, e.g., pledge, registrar, RA, CA, is deployed. Different sites can belong to the same target domain.

synchronous communication:

time-wise uninterrupted communication between a pledge and a registrar or PKI component.

target domain:

the set of entities that the pledge should be able to operate with and that share a common local trust anchor, independent of where the entities are deployed.

Requirements and Mapping to Solutions

Basic Requirements There are two main drivers for the definition of BRSKI-AE: The solution architecture may already use or require a certificate management protocol other than EST. Therefore, this other protocol should be usable for requesting LDevID certificates. The domain registrar may not be the (final) point that authenticates and authorizes certification requests, and the pledge may not have a direct connection to it. Therefore, certification requests should be self-contained signed objects. Based on the intended target environment described in and the application examples described in , the following requirements are derived to support authenticated self-contained objects as containers carrying certification requests. At least 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. 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 rest of this section gives an non-exhaustive list of solution examples, based on existing technology described in IETF documents:

Solution Options for Proof of Possession Certification request objects: Certification requests are data structures protecting only the integrity of the contained data and providing proof of possession for a (locally generated) private key. Examples for certification request data structures are: PKCS#10 . This certification request structure 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. CRMF . This certificate request message format also supports integrity protection and proof of possession, typically by a self-signature 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 support any signature algorithm. The integrity protection of certification request fields includes the public key because it is part of the data signed by the corresponding private key. Yet note that for the above examples this is not sufficient to provide data origin authentication, i.e., proof of identity. This extra property can be achieved by an additional binding to the IDevID of the pledge. This binding to the source authentication supports the authorization decision of the certification request. The binding of data origin authentication to the certification request may be delegated to the protocol used for certificate management.

Solution Options for Proof of Identity The certification request should be bound to an existing authenticated credential (here, the IDevID certificate) to enable a proof of identity and, based on it, an authorization of the certification request. The binding may be achieved through security options in an underlying transport protocol such as TLS if the authorization of the certification request is (completely) done at the next communication hop. This binding can also be done in a transport-independent way by wrapping the certification request with a signature employing an existing IDevID. In the BRSKI context, this will be the IDevID. This requirement is addressed by existing enrollment protocols in various ways, such as: EST utilizes PKCS#10 to encode the certification request. The Certificate Signing Request (CSR) optionally provides a binding to the underlying TLS session by including the tls-unique value in the self-signed PKCS#10 structure. The tls-unique value results from the TLS handshake. Since the TLS handshake includes certificate-based client authentication and the pledge utilizes its IDevID for it, the proof of identity is provided by such a binding to the TLS session. This can be supported using the EST /simpleenroll endpoint. Note that the binding of the TLS handshake to the CSR is optional in EST. sketches wrapping the CSR with a Full PKI Request message sent to the /fullcmc endpoint. This would allow for source authentication at message level as an alternative to indirectly binding to the underlying TLS authentication in the transport layer. 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 also CMC does not rely on the security of the underlying message transfer.

Adaptations to BRSKI In order to support alternative certificate enrollment protocols, 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 distributed freely in the target domain. The enhancements needed are kept to a minimum in order to ensure 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. Consequently, the authentication and authorization of the certification request MAY be done by the domain registrar and/or by other domain components. These components may be offline or reside in some central backend of the domain operator (off-site) as described in . The registrar and other on-site domain components may have no or only temporary (intermittent) connectivity to them. The certification request MAY also be piggybacked on another protocol. This leads to generalizations in the placement and enhancements of the logical elements as shown in .

| Vendor Service | | +------------------------+ | | M anufacturer| | | | A uthorized |Ownership| | | S igning |Tracker | | | A uthority | | | +--------------+---------+ | ^ | | V | +--------+ ......................................... | | | . . | BRSKI- | | . +-------+ +--------------+ . | MASA | Pledge | . | Join | | Domain |<----+ | | . | Proxy | | Registrar w/ | . | |<------>|.......|<-------->| Enrollment | . | | . | | | Proxy/LRA/RA | . | IDevID | . +-------+ +--------------+ . | | BRSKI-AE (over TLS) ^ . | | . | . +--------+ ...............................|......... on-site (local) domain components | | e.g., RFC 4210, | RFC 7030, ... .............................................|.................. . Public-Key Infrastructure v . . +---------+ +------------------------------------------+ . . | |<----+ Registration Authority | . . | PKI CA +---->| PKI RA (unless part of Domain Registrar) | . . +---------+ +------------------------------------------+ . ................................................................ off-site (central, backend) domain components ]]>

The architecture overview in has the same logical elements as BRSKI, but with 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, or none of them. The following list describes the on-site components in the target domain of the pledge shown in . Join Proxy: same functionality as described in BRSKI Domain Registrar including RA, LRA, or Enrollment Proxy: in BRSKI-AE, the domain registrar has mostly the same functionality as in BRSKI, namely to facilitate the communication of the pledge with the MASA and the PKI. Yet there are two generalizations: The registrar MUST support at least one certificate enrollment protocol that uses for certificate requests authenticated self-contained objects. To this end, the URI scheme for addressing the endpoint at the registrar is generalized (see ). To support the end-to-end proof of identity of the pledge, the enrollment protocol used by the pledge MUST also be used by the registrar for its upstream certificate enrollment message exchange with backend PKI components. Between the pledge and the registrar the enrollment request messages are tunneled over the TLS channel already established between these entities. The registrar optionally checks the requests and then passes them on to the PKI. On the way back, it forwards responses by the PKI to the pledge on the existing TLS channel. The registrar MAY also delegate all or part of its certificate enrollment support to a separate system. That is, alternatively to having full RA functionality, the registrar may act as a local registration authority (LRA) or just as an enrollment proxy. In such cases, the domain registrar may forward the certification request to some off-site RA component, also called PKI RA here, that performs the remaining parts of the enrollment request validation and authorization. This also covers the case that the registrar has only intermittent connection and forwards certification requests to off-site PKI components upon re-established connectivity. Still all certificate enrollment traffic goes via the registrar, such that from the pledge perspective there is no difference in connectivity and the registrar is involved in all steps. The final step of BRSKI, namely the enrollment status telemetry, is also kept. 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 (voucher request with nonce) or asynchronous (voucher request without nonce). Ownership tracker: as defined in BRSKI. The following list describes the target domain components that can optionally be operated in the off-site backend of the target domain. PKI RA: Performs certificate management functions for the domain as a centralized 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 PKI CA. PKI CA: Performs certificate generation by signing the certificate structure requested in already authenticated and authorized certification requests. Based on the diagram in BRSKI and the architectural changes, the original protocol flow is divided into four phases showing commonalities and differences to the original approach as follows. Discovery phase: same as in BRSKI steps (1) and (2). Voucher exchange phase: same as in BRSKI steps (3) and (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. Still for transporting certificate enrollment request and response messages between the pledge and the registrar, the TLS channel established between them via the join proxy is used. So the enrollment protocol MUST support this. Due to this architecture, the pledge does not need to establish an additional connection for certificate enrollment and the registrar retains control over the certificate enrollment traffic. Enrollment status telemetry phase: the final exchange of BRSKI step (5).

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

Pledge - Registrar Discovery The discovery is done as specified in .

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

Pledge - Registrar - RA/CA Certificate Enrollment The certificate enrollment phase may involve several exchanges of requests and responses. Which of the message exchanges marked OPTIONAL in the below are potentially used, or are actually required or prohibited to be used, depends on the application scenario and on the employed enrollment protocol. These OPTIONAL exchanges 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. The only generally MANDATORY message exchange is for the actual certificate request and response. As stated in , the certificate request MUST be performed using an authenticated self-contained object providing not only proof of possession but also proof of identity (source authentication).

| | | [OPTIONAL request of CA certificates] | | |---------- CA Certs Request (1)--------->| | | | [OPTIONAL forwarding] | | |---CA Certs Request -->| | |<--CA Certs Response---| |<--------- CA Certs Response (2)---------| | |--> | | | [OPTIONAL request of attributes | | | to include in Certificate Request] | | |---------- Attribute Request (3)-------->| | | | [OPTIONAL forwarding] | | |--- Attribute Req. --->| | |<-- Attribute Resp. ---| |<--------- Attribute Response (4)--------| | |--> | | | [MANDATORY certificate request] | | |---------- Certificate Request (5)------>| | | | [OPTIONAL forwarding] | | |--- Certificate Req.-->| | |<--Certificate Resp.---| |<--------- Certificate Response (6)------| | |--> | | | [OPTIONAL certificate confirmation] | | |---------- Certificate Confirm (7)------>| | | | [OPTIONAL forwarding] | | |---Certificate Conf.-->| | |<---- PKI Confirm -----| |<--------- PKI/Registrar Confirm (8)-----| | ]]>

The various connections between the registrar and the PKI components of the operator (RA/CA) may be intermittent or off-line. Messages are to be sent as soon as sufficient transfer capacity is available. The label [OPTIONAL forwarding] means that on receiving from a pledge a request of the given type, the registrar MAY answer the request directly itself. Otherwise the registrar MUST forward the request to a backend PKI component and forward any resulting response back to the pledge. Notes: The decision 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. There are several options how the registrar could be able to directly answer requests for CA certificates or for certificate request attributes. It could cache responses obtained from the backend PKI and later use their contents for responding to requests asking for the same data. The contents could also be explicit provisioned at the registrar. Certificate 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 may be just the domain registrar certificate). CA Certs Response (2): This MUST contain the current root CA certificate, which typically is the LDevID trust anchor, and any additional certificates that the pledge may need to validate certificates. Attribute Request (3): Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. Nevertheless, there are cases in which the pledge may also include additional attributes specific to the target domain into the certification request. To get these attributes in advance, the attribute request can be used. 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. Attribute Response (4): This MUST contain the attributes to be included in the subsequent certification request. Certificate Request (5): This MUST contain the authenticated self-contained object ensuring both proof of possession of the corresponding private key and proof of identity of the requester. Certificate Response (6): This MUST contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs. Certificate Confirm (7): An optional confirmation sent after the requested certificate has been received and validated. It contains 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 Cert Confirm. The generic messages described above may be implemented using any certificate enrollment protocol that supports authenticated self-contained objects for the certificate request as described in and tunneling over TLS. 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 enrollment step, but due to the generalization on the enrollment protocol described in this document its 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. As this is supported by various existing enrollment protocols, they can be employed without modifications to existing PKI RAs/CAs supporting the respective enrollment protocol (see also ). The addressing scheme in BRSKI for certification requests and the related CA certificates and CSR attributes retrieval functions uses the definition from EST , here on 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, or for newly defined protocols, require their own specifications for their use of the <enrollment-protocol> and <request> URI components and are outside the scope of this document. <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 at the registrar. A pledge SHOULD use the endpoints defined for the enrollment protocol(s) that it is capable of. It will recognize whether its preferred protocol or the request that it tries to perform is supported by the domain registrar by sending a request to its preferred enrollment endpoint according to the above addressing scheme and evaluating the HTTP status code in the response. The following list of endpoints provides an illustrative example for 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 .

,ct=voucher-cms+json ,ct=json ,ct=json ;ct=pkcs7-mime ;ct=pkcs7-mime ;ct=pkcs7-mime ;ct=pkixcmp ;ct=pkixcmp ;ct=pkixcmp ;ct=pkixcmp ]]>

Instantiation to Existing Enrollment Protocols This section maps the requirements to support proof of possession and proof of identity to selected existing enrollment protocols and provides further aspects of instantiating them in BRSKI-AE.

BRSKI-CMP: Instantiation to CMP Instead of referring to CMP as specified in and , this document refers to the Lightweight CMP Profile because the subset of CMP defined there is sufficient for the functionality needed here. When using CMP, the following specific implementation requirements apply (cf. ). CA Certs Request Requesting CA certificates over CMP is OPTIONAL.
If supported, it SHALL be implemented as specified in . Attribute Request Requesting certificate request attributes over CMP is OPTIONAL.
If supported, it SHALL be implemented as specified in .
Note that alternatively the registrar MAY modify the contents of requested certificate contents as specified in . Certificate Request Proof of possession SHALL be provided as defined in the Lightweight CMP Profile (based on CRMF) or (based on PKCS#10).
In certificate response messages the caPubs field, which generally in CMP may convey CA certificates to the requester, SHOULD NOT be used. Proof of identity SHALL be provided by using signature-based protection of the certification request message as outlined in using the IDevID secret. Certificate Confirm Explicit confirmation of new certificates to the RA/CA MAY be used as specified in the Lightweight CMP Profile .
Note that independently of certificate confirmation within CMP, enrollment status telemetry with the registrar will be performed as described in BRSKI . If delayed delivery of responses (for instance, to support asynchronous enrollment) within CMP is needed, it SHALL be performed as specified in the Lightweight CMP Profile and . Due to the use of self-contained signed request messages providing end-to-end security and the general independence of CMP of message transfer, the way in which messages are exchanged by the registrar with backend PKI (RA/CA) components is out of scope of this document. It can be freely chosen according to the needs of the application scenario (e.g., using HTTP). CMP Updates and the Lightweight CMP Profile provide requirements for interoperability. BRSKI-AE with CMP can also be combined with Constrained BRSKI , using CoAP for enrollment message transport as described by CoAP Transport for CMPV2 . In this scenario, of course the EST-specific parts of do not apply.

Other Instantiations of BRSKI-AE 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 does not require IANA actions.

Security Considerations The security considerations as laid out in BRSKI apply for the discovery and voucher exchange as well as for the status exchange information. The security considerations as laid out in the Lightweight CMP Profile apply as far as CMP is used.

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 Michael Richardson and Rajeev Ranjan for their reviews.

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 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 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. Siemens Siemens Entrust This document contains a set of updates to the syntax and transfer of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210, RFC 5912, and RFC 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 signaling the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed. Siemens Siemens Siemens AG This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer 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. Palo Alto Networks Palo Alto Networks This document specifies the use of 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 IoT space. Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping 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. Constrained BRSKI 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 is typically encoded in JSON, Constrained BRSKI defines a compact CBOR-encoded voucher. The BRSKI voucher 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 CoAPS. 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. 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 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), and2. 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 contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK] 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 presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. 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. 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

Using EST for Certificate Enrollment When using EST with BRSKI, pledges interact via TLS with the domain registrar, which acts both as EST server and as the PKI RA. The TLS channel is mutually authenticated, where the pledge uses its IDevID certificate issued by its manufacturer. Using BRSKI-EST has the advantage that the mutually authenticated TLS channel established between the pledge and the registrar can be reused for protecting the message exchange needed for enrolling the LDevID certificate. This strongly simplifies the implementation of the enrollment message exchange. Yet the use of TLS has the limitation that this cannot provide auditability nor end-to-end authentication of the CSR by the pledge at a remote PKI RA/CA because the TLS session is transient and terminates at the registrar. This is a problem in particular if the enrollment is done via multiple hops, part of which may not even be network-based. With enrollment protocols that use for CSRs self-contained signed objects, logs of CSRs can be audited because CSRs can be third-party authenticated in retrospect, whereas TLS connections can not. Furthermore, the BRSKI registrars in each site have to be hardened so that they can be trusted to be the TLS initiator of the EST connection to the PKI RA/CA, and in result, their keying material needs to be managed with more security care than that of pledges because of trust requirements, for example they need to have the id-kp-cmcRA extended key usage attribute according to , see . Impairment to a BRSKI registrar can result in arbitrarily many fake certificate registrations because real authentication and authorization checks can then be circumvented. Relying on TLS authentication of the TLS client, which is supposed to be the certificate requester, for a strong proof of origin for the CSR is conceptually non-trivial and can have implementation challenges. EST has the option to include in the certification request, which is a PKCS#10 CSR, the so-called tls-unique value of the underlying TLS channel. This binding of the proof of identity of the TLS client to the proof of possession for the private key requires specific support by TLS implementations. The registrar terminates the security association with the pledge at TLS level and thus the binding between the certification request and the authentication of the pledge. In BRSKI , the registrar typically doubles as the PKI RA and thus also authenticates the CSR and filters/denies requests from non-authorized pledges. If the registrar cannot do the final authorization checks on the CSR and needs to forward it to the PKI RA, there is no end-to-end proof of identity and thus the decision of the PKI RA must trust on the pledge authentication performed by the registrar. If successfully authorized, the CSR is passed to the PKI CA, which will issue the domain-specific certificate (LDevID). If in this setup the protocol between the on-site registrar and the remote PKI RA is also EST, this approach requires online or at least intermittent connectivity between registrar and PKI RA, as well as availability of the PKI RA for performing the final authorization decision on the certification request. A further limitation of using EST as the certificate enrollment protocol is that due to using PKCS#10 structures in enrollment requests, the only possible proof-of-possession method is a self-signature, which excludes requesting certificates for key types that do not support signing. CMP, for instance, has special proof-of-possession options for key agreement and KEM keys, see .

Application Examples This informative annex provides some detail to the application examples listed in .

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 building a train, with track-side equipment, and/or possibly with backend systems. These devices are typically unaware of backend system connectivity. Managing certificates may be done during maintenance cycles of the railroad car, but can already be prepared during operation. Preparation will include generating certification requests, which are collected and later forwarded for processing, once the railroad car is connected to the operator backend. 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 enrollment of TLS client and server X.509 certificates of on-board and track-side components in the Subset-137 specifying the ETRAM/ETCS on-line 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 with 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 as 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 in order 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 cannot be operated securely enough for the needs of an RA, this service should be transferred to an off-site backend component that has a sufficient level of security.

History of Changes TBD RFC Editor: please delete List of reviewers (besides the authors): Toerless Eckert (document shepherd) Michael Richardson Rajeev Ranjan From IETF draft ae-02 -> IETF draft 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 instantiation to EST-fullCMC Move Eliot Lear from co-author to contributor, add him to the acknowledgments Add explanations for terms such as 'target domain' and 'caPubs' Fix minor editorial issues and update some external references From IETF draft ae-01 -> IETF draft 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. 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 offsite 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