Support of asynchronous Enrollment in BRSKI (BRSKI-AE)
draft-ietf-anima-brski-async-enroll-01

Document Type Active Internet-Draft (anima WG)
Authors Steffen Fries  , Hendrik Brockhaus  , Eliot Lear  , Thomas Werner 
Last updated 2021-01-07
Replaces draft-fries-anima-brski-async-enroll
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
ANIMA WG                                                        S. Fries
Internet-Draft                                              H. Brockhaus
Intended status: Standards Track                                 Siemens
Expires: July 11, 2021                                           E. Lear
                                                           Cisco Systems
                                                               T. Werner
                                                                 Siemens
                                                         January 7, 2021

         Support of asynchronous Enrollment in BRSKI (BRSKI-AE)
                 draft-ietf-anima-brski-async-enroll-01

Abstract

   This document describes enhancements of bootstrapping a remote secure
   key infrastructure (BRSKI) to also operate in domains featuring no or
   only timely limited connectivity between involved components.
   Moreover, newly introduced are methods to perform the BRSKI approach
   in environments, in which the role of the pledge changes to a server
   instead of the client.  This changes the interaction model as the
   pledge is pushed to interact with the registrar instead of pulling
   information from the registrar.  To support both, BRSKI-AE relies on
   the exchange of it authenticated self-contained objects (signature-
   wrapped objects) also for requesting and distributing of domain
   specific device certificates.  The defined approach is agnostic
   regarding the utilized enrollment protocol allowing the application
   of existing and potentially new certificate management protocols.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 11, 2021.

Fries, et al.             Expires July 11, 2021                 [Page 1]
Internet-Draft                  BRSKI-AE                    January 2021

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Scope of solution . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Supported environment . . . . . . . . . . . . . . . . . .   7
     3.2.  Application Examples  . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Rolling stock . . . . . . . . . . . . . . . . . . . .   7
       3.2.2.  Building automation . . . . . . . . . . . . . . . . .   8
       3.2.3.  Substation automation . . . . . . . . . . . . . . . .   8
       3.2.4.  Electric vehicle charging infrastructure  . . . . . .   9
       3.2.5.  Infrastructure isolation policy . . . . . . . . . . .   9
       3.2.6.  Less operational security in the target domain  . . .   9
   4.  Requirement discussion and mapping to solution elements . . .   9
   5.  Architectural Overview and Communication Exchanges  . . . . .  12
     5.1.  Use Case 1 (PULL): Support of off-site PKI service  . . .  12
       5.1.1.  Behavior of a pledge  . . . . . . . . . . . . . . . .  15
       5.1.2.  Pledge - Registrar discovery and voucher exchange . .  16
       5.1.3.  Registrar - MASA voucher exchange . . . . . . . . . .  16
       5.1.4.  Pledge - Registrar - RA/CA certificate enrollment . .  16
       5.1.5.  Addressing Scheme Enhancements  . . . . . . . . . . .  19
     5.2.  Use Case 2 (PUSH): pledge-agent . . . . . . . . . . . . .  19
       5.2.1.  Behavior of a pledge  . . . . . . . . . . . . . . . .  23
       5.2.2.  Behavior of a pledge-agent  . . . . . . . . . . . . .  24
       5.2.3.  Protocol Details (Pledge-Agent - Pledge)  . . . . . .  25
       5.2.4.  Protocol flow . . . . . . . . . . . . . . . . . . . .  29
     5.3.  Domain registrar support of different enrollment options   31
   6.  Example for signature-wrapping using existing enrollment
       protocols . . . . . . . . . . . . . . . . . . . . . . . . . .  32
     6.1.  EST Handling  . . . . . . . . . . . . . . . . . . . . . .  33
     6.2.  Lightweight CMP Handling  . . . . . . . . . . . . . . . .  33
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  34

Fries, et al.             Expires July 11, 2021                 [Page 2]
Internet-Draft                  BRSKI-AE                    January 2021

   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  34
     9.1.  Exhaustion attack on pledge . . . . . . . . . . . . . . .  34
     9.2.  PSK usage in TLS establishment  . . . . . . . . . . . . .  34
     9.3.  Misuse of acquired voucher and enrollment responses . . .  35
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  35
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     11.2.  Informative References . . . . . . . . . . . . . . . . .  36
   Appendix A.  History of changes [RFC Editor: please delete] . . .  38
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1.  Introduction

   BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies
   a solution for secure zero-touch (automated) bootstrapping of devices
   (pledges) in a deployment domain.  This includes the discovery of
   network elements in the target domain, time synchronization, and the
   exchange of security information necessary to establish trust between
   a pledge and the domain and to adopt a pledge as new network and
   application element.  Security information about the target domain,
   specifically the target domain certificate, is exchanged utilizing
   voucher objects as defined in [RFC8366].  These vouchers are
   authenticated self-contained (signed) objects, which may be provided
   online (synchronous) or offline (asynchronous) via the domain
   registrar to the pledge and originate from a Manufacturer's
   Authorized Signing Authority (MASA).  The MASA signed voucher
   contains the target domain certificate and can be verified by the
   pledge due to the possession of a manufacturer root certificate.  It
   facilitates the enrollment of the pledge in the target domain and is
   used to establish trust from the pledge to the domain.

   For the enrollment of devices BRSKI relies on EST [RFC7030] to
   request and distribute target domain specific device certificates.
   EST in turn relies on a binding of the certification request to an
   underlying TLS connection between the EST client and the EST server.
   According to BRSKI the domain registrar acts as EST server and is
   also acting as registration authority (RA) or local registration
   authority (LRA).  The binding to TLS is used to protect the exchange
   of a certification request (for an LDevID certificate) and to provide
   data origin authentication to support the authorization decision for
   processing the certification request.  The TLS connection is mutually
   authenticated and the client side authentication utilizes the
   pledge's manufacturer issued device certificate (IDevID certificate).
   This approach requires an on-site availability of a local asset or
   inventory management system performing the authorization decision
   based on tuple of the certification request and the pledge
   authentication using the IDevID certificate, to issue a domain
   specific certificate to the pledge.  The EST server (the domain

Fries, et al.             Expires July 11, 2021                 [Page 3]
Internet-Draft                  BRSKI-AE                    January 2021

   registrar) terminates the security association with the pledge and
   thus the binding between the certification request and the
   authentication of the pledge via TLS.  This type of enrollment
   utilizing an online connection to the PKI is considered as
   synchronous enrollment.

   For certain use cases on-site support of a RA/CA component and/or an
   asset management is not available and rather provided by an
   operator's backend and may be provided timely limited or completely
   through offline interactions.  This may be due to higher security
   requirements for operating the certification authority or for
   optimization of operation for smaller deployments to avoid the always
   on-site operation.  The authorization of a certification request
   based on an asset management in this case will not / can not be
   performed on-site at enrollment time.  Enrollment, which cannot be
   performed in a (timely) consistent fashion is considered as
   asynchronous enrollment in this document.  It requires the support of
   a store and forward functionality of certification request together
   with the requester authentication information.  This enables
   processing of the request at a later point in time.  A similar
   situation may occur through network segmentation, which is utilized
   in industrial systems to separate domains with different security
   needs.  Here, a similar requirement arises if the communication
   channel carrying the requester authentication is terminated before
   the RA/CA authorization handling of the certification request.  If a
   second communication channel is opened to forward the certification
   request to the issuing RA/ CA, the requester authentication
   information needs to be retained and ideally bound to the
   certification request.  This uses case is independent from timely
   limitations of the first use case.  For both cases, it is assumed
   that the requester authentication information is utilized in the
   process of authorization of a certification request.  There are
   different options to perform store and forward of certification
   requests including the requester authentication information:

   o  Providing a trusted component (e.g., an LRA) in the target domain,
      which stores the certification request combined with the requester
      authentication information (based on the IDevID) and potentially
      the information about a successful proof of possession (of the
      corresponding private key) in a way prohibiting changes to the
      combined information.  Note that the assumption is that the
      information elements may not be cryptographically bound together.
      Once connectivity to the backend is available, the trusted
      component forwards the certification request together with the
      requester information (authentication and proof of possession) to
      the off-site PKI for further processing.  It is assumed that the
      off-site PKI in this case relies on the local pledge
      authentication result and thus performs the authorization and

Fries, et al.             Expires July 11, 2021                 [Page 4]
Internet-Draft                  BRSKI-AE                    January 2021

      issues the requested certificate.  In BRSKI the trusted component
      may be the EST server residing co-located with the registrar in
      the target domain.

   o  Utilization of authenticated self-contained objects for the
      enrollment, binding the certification request and the requester
      authentication in a cryptographic way.  This approach reduces the
      necessary trust in a domain component to storage and delivery.
      Unauthorized modifications of the requester information (request
      and authentication) can be detected during the verification of the
      authenticated self-contained object.

   This targets environments, in which connectivity to a PKI is only
   temporary or not directly available, by specifying support for
   handling authenticated self-contained objects for enrollment.  As it
   is intended to enhance BRSKI it is named BRSKI-AE, where AE stands
   for asynchronous enrollment.  As BRSKI, BRSKI-AE results in the
   pledge storing an X.509 root certificate and sufficient for verifying
   the domain registrar / proxy identity (LDevID CA Certificate) as well
   as a domain specific X.509 device certificate (LDevID EE
   certificate).

   Based on the proposed approach, a second set of scenarios can be
   addressed, in which the pledge has either no direct communication
   path to the domain registrar, e.g., due to missing network
   connectivity or a different technology stack.  In such scenarios the
   pledge is likely to act as a server rather than a client.  It will be
   pushed (triggered) by the registrar or an intermediate component to
   generate request objects to be onboarded in the registrar's domain.
   For this, an additional component is introduced acting as an agent
   for the pledge towards the domain registrar, e.g., a commissioning
   tool.  In contrast to BRSKI here the objects to trigger a request
   generation and the responses are pushed to the pledge instead of
   being pulled as done in BRSKI.

   The goal is to enhance BRSKI to either allow other existing
   certificate management protocols supporting authenticated self-
   contained objects to be applied or to allow other types of encoding
   for the certificate management information exchange.  This is
   addressed by

   o  enhancing the well-known URI approach with an additional path for
      the utilized enrollment protocol.

   o  defining a certificate waiting indication and handling, if the
      certifying component is (temporarily) not available.

Fries, et al.             Expires July 11, 2021                 [Page 5]
Internet-Draft                  BRSKI-AE                    January 2021

   o  allowing to utilize credentials different from the pledge's IDevID
      to establish a TLS connection to the domain registrar, which is
      necessary in case of using a pledge-agent.

   Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple
   enrollment protocols on the infrastructure side, allowing the pledge
   manufacturer to select the most appropriate.  Thus, BRSKI-AE can be
   applied for both, asynchronous and synchronous enrollment.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119]
   [RFC8174] when, and only when, they appear in all capitals, as shown
   here.  The following terms are defined additionally:

   CA:  Certification authority, issues certificates.

   RA:  Registration authority, an optional system component to which a
      CA delegates certificate management functions such as
      authorization checks.

   LRA:  Local registration authority, an optional RA system component
      with proximity to end entities.

   IED:  Intelligent Electronic Device (in essence a pledge).

   on-site:  Describes a component or service or functionality available
      in the target deployment domain.

   off-site:  Describes a component or service or functionality
      available in an operator domain different from the target
      deployment domain.  This may be a central site, to which only a
      temporary connection is available, or which is in a different
      administrative domain.

   asynchronous communication:  Describes a timely interrupted
      communication between an end entity and a PKI component.

   synchronous communication:  Describes a timely uninterrupted
      communication between an end entity and a PKI component.

   authenticated self-contained object:  Describes an object, which is
      cryptographically bound to the IDevID EE certificate of a pledge.
      The binding is assumed to be provided through a digital signature
      of the actual object using the corresponding private key of the
      IDevID.

Fries, et al.             Expires July 11, 2021                 [Page 6]
Internet-Draft                  BRSKI-AE                    January 2021

3.  Scope of solution

3.1.  Supported environment

   This solution is intended to be used in domains with limited support
   of on-site PKI services and comprises use cases in which:

   o  there is no registration authority available in the target domain.
      The connectivity to an off-site RA in an operator's network may
      only be available temporarily.  A local store and forward device
      is used for the communication with the off-site services.

   o  authoritative actions of a LRA are limited and may not comprise
      authorization of certification requests of pledges.  Final
      authorization is done at the RA residing in the operator domain.

   o  the target deployment domain already has an established
      certificate management approach that shall be reused to (e.g., in
      brownfield installations).

   In addition, the solution is intended to be applicable in domains in
   which pledges have no direct connection to the domain registrar, but
   are expected to be managed by the registrar.  This can be motivated
   by pledges featuring a different technology stack or by pledges
   without an existing connection to the domain registrar during
   onboarding.  These pledges are likely to act in a server role.
   Therefore, the pledge needs to provide endpoints on which it can be
   triggered for requesting the generation of voucher-request objects
   and certification objects as well as to provide the response objects
   to the pledge.  here the pledge is not expected to start a
   communication with the domain registrar for onboarding, but is
   expected to be pushed for the interaction.

3.2.  Application Examples

   The following examples are intended to motivate the support of
   different enrollment approaches in general and asynchronous
   enrollment specifically, by introducing industrial applications
   cases, which could leverage BRSKI as such but also require support of
   asynchronous operation as intended with BRSKI-AE.

3.2.1.  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,
   or with a backend.  These devices are typically unaware of backend
   connectivity.  Managing certificates may be done during maintenance

Fries, et al.             Expires July 11, 2021                 [Page 7]
Internet-Draft                  BRSKI-AE                    January 2021

   cycles of the railroad car, but can already be prepared during
   operation.  The preparation may comprise the generation of
   certification requests by the components which are collected and
   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.

3.2.2.  Building automation

   In building automation, a use case can be described by a detached
   building or the basement of a building equipped with sensor,
   actuators, and controllers connected, but with only limited or no
   connection to the centralized building management system.  This
   limited connectivity may be during the installation time but also
   during operation time.  During the installation in the basement, a
   service technician collects the necessary information from the
   basement network and provides them to the central building management
   system, e.g., using a laptop or even a mobile phone to transport the
   information.  This information may comprise parameters and settings
   required in the operational phase of the sensors/actuators, like a
   certificate issued by the operator to authenticate against other
   components and services.

   The collected information may be provided by a domain registrar
   already existing in the installation network.  In this case
   connectivity to the backend PKI may be facilitated by the service
   technician's laptop.  Contrary, the information can also be collected
   from the pledges directly and provided to a domain registrar deployed
   in a different network.  In this cases connectivity to the domain
   registrar may be facilitated by the service technician's laptop.

3.2.3.  Substation automation

   In electrical substation automation a control center typically hosts
   PKI services to issue certificates for Intelligent Electronic Devices
   (IED)s operated in a substation.  Communication between the
   substation and control center is done through a proxy/gateway/DMZ,
   which terminates protocol flows.  Note that [NERC-CIP-005-5] requires
   inspection of protocols at the boundary of a security perimeter (the
   substation in this case).  In addition, security management in
   substation automation assumes central support of different enrollment
   protocols to facilitate the capabilities of IEDs from different
   vendors.  The IEC standard IEC62351-9 [IEC-62351-9] specifies the
   mandatory support of two enrollment protocols, SCEP [RFC8894] and EST
   [RFC7030] for the infrastructure side, while the IED must only
   support one of the two.

Fries, et al.             Expires July 11, 2021                 [Page 8]
Internet-Draft                  BRSKI-AE                    January 2021

3.2.4.  Electric vehicle charging infrastructure

   For the electric vehicle charging infrastructure protocols have been
   defined for the interaction between the electric vehicle (EV) and the
   charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as
   between the charging point and the charging point operator (e.g.
   OCPP [OCPP]).  Depending on the authentication model, unilateral or
   mutual authentication is required.  In both cases the charging point
   uses an X.509 certificate to authenticate itself in the context of a
   TLS connection between the EV and the charging point.  The management
   of this certificate depends (beyond others) on the selected backend
   connectivity protocol.  Specifically, in case of OCPP it is intended
   as single 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 is intended to be handled in-band of OCPP.
   This requires to be able to encapsulate the certificate management
   exchanges in a transport independent way.  Authenticated self-
   containment will ease this by allowing the transport without a
   separate enrollment protocol.

3.2.5.  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
   resources will be allowed in carefully controlled short periods of
   time, for example when a batch of new devices are deployed, but
   impossible at other times.

3.2.6.  Less operational security in the target domain

   The registration point performing the authorization of a certificate
   request is a critical PKI component and therefore implicates higher
   operational security than other components utilizing the issued
   certificates for their security features.  CAs may also demand higher
   security in the registration procedures.  Especially the CA/Browser
   forum currently increases the security requirements in the
   certificate issuance procedures for publicly trusted certificates.
   There may be the situation that the target domain does not offer
   enough security to operate a registration point and therefore wants
   to transfer this service to a backend.

4.  Requirement discussion and mapping to solution elements

   For the requirements discussion it is assumed that the domain
   registrar receiving a certification request as authenticated self-
   contained object is not the authorization point for this

Fries, et al.             Expires July 11, 2021                 [Page 9]
Internet-Draft                  BRSKI-AE                    January 2021

   certification request.  If the domain registrar is the authorization
   point, BRSKI can be used directly.  Note that BRSKI-AE could also be
   used in this case.

   Based on the intended target environment described in Section 3.1 and
   the motivated application examples described in Section 3.2 the
   following base requirements are derived to support authenticated
   self-contained objects as container carrying the certification
   request and further information to support asynchronous operation.

   At least the following properties are required:

   o  Proof of Possession: proves to possess and control the private key
      corresponding to the public key contained in the certification
      request, typically by addind a signature using the private key.

   o  Proof of Identity: provides data-origin authentication of a data
      object, e.g., a certificate request, utilizing an existing IDevID.
      Certificate updates may utilize the certificate that is to be
      updated.

   Solution examples (not complete) based on existing technology are
   provided with the focus on existing IETF documents:

   o  Certification request objects: Certification requests are
      structures protecting only the integrity of the contained data
      providing a proof-of-private-key-possession for locally generated
      key pairs.  Examples for certification requests are:

      *  PKCS#10 [RFC2986]: Defines a structure for a certification
         request.  The structure is signed to ensure integrity
         protection and proof of possession of the private key of the
         requester that corresponds to the contained public key.

      *  CRMF [RFC4211]: Defines a structure for the certification
         request message.  The structure supports integrity protection
         and proof of possession, through a signature generated over
         parts of the structure by using the private key corresponding
         to the contained public key.

      Note that the integrity of the certification request is bound to
      the public key contained in the certification request by
      performing the signature operation with the corresponding private
      key.  In the considered application examples, this is not
      sufficient and needs to be bound to the existing credential of the
      pledge (IDevID) additionally.  This binding supports the
      authorization decision for the certification request through the
      provisioning of a proof of identity.  The binding of data origin

Fries, et al.             Expires July 11, 2021                [Page 10]
Internet-Draft                  BRSKI-AE                    January 2021

      authentication to the certification request may be delegated to
      the protocol used for certificate management.

   o  Proof of Identity options: The certification request should be
      bound to an existing credential (here IDevID) to enable a proof of
      identity and based on it an authorization of the certification
      request.  The binding may be realized through security options in
      an underlying transport protocol if the authorization of the
      certification request is done at the next communication hop.
      Alternatively, this binding can be done by a wrapping signature
      employing an existing credential (initial: IDevID, renewal:
      LDevID).  This requirement is addressed by existing enrollment
      protocols in different ways, for instance:

      *  EST [RFC7030]: Utilizes PKCS#10 to encode the certification
         request.  The Certificate Signing Request (CSR) may contain a
         binding to the underlying TLS by including the tls-unique value
         in the self-signed CSR structure.  The tls-unique value is one
         result of the TLS handshake.  As the TLS handshake is performed
         mutually authenticated and the pledge utilized its IDevID for
         it, the proof of identity can be provided by the binding to the
         TLS session.  This is supported in EST using simpleenroll.  To
         avoid the binding to the underlying authentication in the
         transport layer, EST offers the support of a wrapping the CSR
         with an existing certificate by using Full PKI Request
         messages.

      *  SCEP [RFC8894]: Provides the option to utilize either an
         existing secret (password) or an existing certificate to
         protect the CSR based on SCEP Secure Message Objects using CMS
         wrapping ([RFC5652]).  Note that the wrapping using an existing
         IDevID credential in SCEP is referred to as renewal.  SCEP
         therefore does not rely on the security of an underlying
         transport.

      *  CMP [RFC4210] Provides the option to utilize either an existing
         secret (password) or an existing certificate to protect the
         PKIMessage containing the certification request.  The
         certification request is encoded utilizing CRMF.  PKCS#10 is
         optionally supported.  The proof of identity of the PKIMessage
         containing the certification request can be achieved by using
         IDevID credentials to a PKIProtection carrying the actual
         signature value.  CMP therefore does not rely on the security
         of an underlying transport protocol.

      *  CMC [RFC5272] Provides the option to utilize either an existing
         secret (password) or an existing certificate to protect the
         certification request (either in CRMF or PKCS#10) based on CMS

Fries, et al.             Expires July 11, 2021                [Page 11]
Internet-Draft                  BRSKI-AE                    January 2021

         [RFC5652]).  Here a FullCMCRequest can be used, which allows
         signing with an existing IDevID credential to provide a proof
         of identity.  CMC therefore does not rely on the security of an
         underlying transport.

   Note that besides the already existing enrollment protocols there is
   ongoing work in the ACE WG to define an encapsulation of EST messages
   in OSCORE to result in a TLS independent way of protecting EST.  This
   approach [I-D.selander-ace-coap-est-oscore] may be considered as
   further variant.

5.  Architectural Overview and Communication Exchanges

   To support asynchronous enrollment, the base system architecture
   defined in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is enhanced
   to facilitate the two target use cases.

   o  Use case 1 (PULL case): the pledge requests certificates from a
      PKI operated off-site via the domain registrar.

   o  Use case 2 (PUSH case): allows delayed (delegated) onboarding
      using a pledge-agent instead a direct connection to the domain
      registrar.  The communication model between pledge-agent and
      pledge is intended to use a PUSH approach in which the pledge acts
      as a server.

   Note that the terminology PUSH and PULL relates to the pledge
   behavior.  In PULL the pledge requests data objects as in BRSKI,
   while in the PUSH case the pledge is in the server role and will be
   provided with the data objects.  The pledge-agent, as it represents
   the pledge, is expected to act in a PULL mode towards the domain
   registrar.  Both use cases are described in the next subsections.
   They utilize the existing BRSKI architecture elements as much as
   possible.  Necessary enhancements to support authenticated self-
   contained objects for certificate enrollment are kept on a minimum to
   ensure reuse of already defined architecture elements and
   interactions.

   For the authenticated self-contained objects used for the
   certification request, BRSKI-AE relies on the defined message
   wrapping mechanisms of the enrollment protocols stated in Section 4
   above.

5.1.  Use Case 1 (PULL): Support of off-site PKI service

   One assumption of BRSKI-AE is that the authorization of a
   certification request is performed based on an authenticated self-
   contained object, binding the certification request to the

Fries, et al.             Expires July 11, 2021                [Page 12]
Internet-Draft                  BRSKI-AE                    January 2021

   authentication using the IDevID.  This supports interaction with off-
   site or off-line PKI (RA/CA) components.  In addition, the
   authorization of the certification request may not be done by the
   domain registrar but by a PKI residing in the backend of the domain
   operator (off-site) as described in Section 3.1.  This leads to
   changes in the placement or enhancements of the logical elements as
   shown in Figure 1.

                                              +------------------------+
      +--------------Drop Ship--------------->| Vendor Service         |
      |                                       +------------------------+
      |                                       | M anufacturer|         |
      |                                       | A uthorized  |Ownership|
      |                                       | S igning     |Tracker  |
      |                                       | A uthority   |         |
      |                                       +--------------+---------+
      |                                                      ^
      |                                                      |
      V                                                      |
   +--------+     .........................................  |
   |        |     .                                       .  | BRSKI-
   |        |     .  +------------+       +------------+  .  | MASA
   | Pledge |     .  |   Join     |       | Domain     <-----+
   |        |     .  |   Proxy    |       | Registrar/ |  .
   |        <-------->............<-------> Enrollment |  .
   |        |     .  |        BRSKI-AE    | Proxy      |  .
   | IDevID |     .  |            |       +------^-----+  .
   |        |     .  +------------+              |        .
   |        |     .                              |        .
   +--------+     ...............................|.........
                   "on-site domain" components   |
                                                 |e.g., RFC 7030,
                                                 |      RFC 4210, ...
    .............................................|.....................
    . +---------------------------+     +--------v------------------+ .
    . | Public Key Infrastructure |<----+ PKI RA                    | .
    . | PKI CA                    |---->+                           | .
    . +---------------------------+     +---------------------------+ .
    ...................................................................
            "off-site domain" components

       Figure 1: Architecture overview using off-site PKI components

   The architecture overview in Figure 1 utilizes the same logical
   elements as BRSKI but with a different placement in the deployment
   architecture for some of the elements.  The main difference is the
   placement of the PKI RA/CA component, which is performing the
   authorization decision for the certification request message.  It is

Fries, et al.             Expires July 11, 2021                [Page 13]
Internet-Draft                  BRSKI-AE                    January 2021

   placed in the off-site domain of the operator (not the deployment
   site directly), which may have no or only temporary connectivity to
   the deployment or on-site domain of the pledge.  This is to underline
   the authorization decision for the certification request in the
   backend rather than on-site.  The following list describes the
   components in the target domain:

   o  Join Proxy: same functionality as described in BRSKI.

   o  Domain Registrar / Enrollment Proxy: In general the domain
      registrar proxy has a similar functionality regarding the
      imprinting of the pledge in the deployment domain to facilitate
      the communication of the pledge with the MASA and the PKI.
      Different is the authorization of the certification request.
      BRSKI-AE allows to perform this in the operator's backend (off-
      site), and not directly at the domain registrar.

      *  Voucher exchange: The voucher exchange with the MASA via the
         domain registrar is performed as described in BRSKI
         [I-D.ietf-anima-bootstrapping-keyinfra] .

      *  Certificate enrollment: For the pledge enrollment the domain
         registrar in the deployment domain supports the adoption of the
         pledge in the domain based on the voucher request.
         Nevertheless, it may not have sufficient information for
         authorizing the certification request.  If the authorization of
         the certification request is done in the off-site domain, the
         domain registrar forwards the certification request to the RA
         to perform the authorization.  Note that this requires, that
         the certification request object is enhanced with a proof-of-
         identity to allow the authorization based on the bound identity
         information of the pledge.  As stated above, this can be done
         by an additional signature using the IDevID.  The domain
         registrar here acts as an enrollment proxy or local
         registration authority.  It is also able to handle the case
         having no connection temporarily to an off-site PKI, by storing
         the authenticated certification request and forwarding it to
         the RA upon reestablished connectivity.  As authenticated self-
         contained objects are used, it requires an enhancement of the
         domain registrar.  This is done by supporting alternative
         enrollment approaches (protocol options, protocols, encoding)
         by enhancing the addressing scheme to communicate with the
         domain registrar (see Section 5.1.5).

   The following list describes the vendor related components/service
   outside the deployment domain:

Fries, et al.             Expires July 11, 2021                [Page 14]
Internet-Draft                  BRSKI-AE                    January 2021

   o  MASA: general functionality as described in
      [I-D.ietf-anima-bootstrapping-keyinfra].  Assumption is that the
      interaction with the MASA may be synchronous (voucher request with
      nonce) or asynchronous (voucher request without nonce).

   o  Ownership tracker: as defined in
      [I-D.ietf-anima-bootstrapping-keyinfra].

   The following list describes the operator related components/service
   operated in the backend:

   o  PKI RA: Performs certificate management functions (validation of
      certification requests, interaction with inventory/asset
      management for authorization of certification requests, etc.) for
      issuing, updating, and revoking certificates for a domain as a
      centralized infrastructure for the domain operator.  The inventory
      (asset) management may be a separate component or integrated into
      the RA directly.

   o  PKI CA: Performs certificate generation by signing the certificate
      structure provided in the certification request.

   Based on BRSKI and the architectural changes the original protocol
   flow is divided into three phases showing commonalities and
   differences to the original approach as depicted in the following.

   o  Discovery phase (same as BRSKI)

   o  Voucher exchange with deployment domain registrar (same as BRSKI).

   o  Enrollment phase (changed to support the application of
      authenticated self-contained objects).

5.1.1.  Behavior of a pledge

   The behavior of a pledge as described in
   [I-D.ietf-anima-bootstrapping-keyinfra] is kept with one exception.
   After finishing the imprinting phase (4) the enrollment phase (5) is
   performed with a method supporting authenticated self-contained
   objects.  Using EST with simpleenroll cannot be applied here, as it
   binds the pledge authentication with the existing IDevID to the
   transport channel (TLS) rather than to the certification request
   object directly.  This authentication in the transport layer is not
   visible / verifiable at the authorization point in the off-site
   domain.  Section 6 discusses potential enrollment protocols and
   options applicable.

Fries, et al.             Expires July 11, 2021                [Page 15]
Internet-Draft                  BRSKI-AE                    January 2021

5.1.2.  Pledge - Registrar discovery and voucher exchange

   The discovery phase is applied as specified in
   [I-D.ietf-anima-bootstrapping-keyinfra].

5.1.3.  Registrar - MASA voucher exchange

   The voucher exchange is performed as specified in
   [I-D.ietf-anima-bootstrapping-keyinfra].

5.1.4.  Pledge - Registrar - RA/CA certificate enrollment

   As stated in Section 4 the enrollment shall be performed using an
   authenticated self-contained object providing proof of possession and
   proof of identity.

Fries, et al.             Expires July 11, 2021                [Page 16]
Internet-Draft                  BRSKI-AE                    January 2021

   +--------+         +---------+    +------------+     +------------+
   | Pledge |         | Circuit |    | Domain     |     | Operator   |
   |        |         | Join    |    | Registrar  |     | RA/CA      |
   |        |         | Proxy   |    |  (JRC)     |     | (OPKI)     |
   +--------+         +---------+    +------------+     +------------+
     /-->                                      |                    |
   [Request of CA Certificates]                |                    |
     |---------- CA Certs Request ------------>|                    |
     |              [if connection to operator domain is available] |
     |                                         |-Request CA Certs ->|
     |                                         |<- CA Certs Response|
     |<-------- CA Certs Response--------------|                    |
     /-->                                      |                    |
   [Request of Certificate Attributes to be included]               |
     |---------- Attribute Request ----------->|                    |
     |              [if connection to operator domain is available] |
     |                                         |Attribute Request ->|
     |                                         |<-Attribute Response|
     |<--------- Attribute Response -----------|                    |
     /-->                                      |                    |
   [Certification request]                     |                    |
     |-------------- Cert Request ------------>|                    |
     |              [if connection to operator domain is available] |
     |                                         |--- Cert Request -->|
     |                                         |<-- Cert Response --|
   [Optional Certificate waiting indication]   |                    |
     /-->                                      |                    |
     |<---------- Cert Waiting ----------------|                    |
     |-- Cert Polling (with orig request ID) ->|                    |
     |              [if connection to operator domain is available] |
     |                                         |--- Cert Request -->|
     |                                         |<-- Cert Response --|
     /-->                                      |                    |
     |<------------- Cert Response ------------|                    |
     /-->                                      |                    |
   [Certificate confirmation]                  |                    |
     |-------------- Cert Confirm ------------>|                    |
     |                                         /-->                 |
     |                                         |[optional]          |
     |                                         |--- Cert Confirm -->|
     |                                         |<-- PKI Confirm ----|
     |<------------- PKI/Registrar Confirm ----|                    |

                     Figure 2: Certificate enrollment

   The following list provides an abstract description of the flow
   depicted in Figure 2.

Fries, et al.             Expires July 11, 2021                [Page 17]
Internet-Draft                  BRSKI-AE                    January 2021

   o  CA Cert Request: The pledge SHOULD request the full distribution
      of CA Certificates.  This ensures that the pledge has the complete
      set of current CA certificates beyond the pinned-domain-cert
      (which may be the domain registrar certificate contained in the
      voucher).

   o  CA Cert Response: Contains at least one CA certificate of the
      issuing CA.

   o  Attribute Request: 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 deployment domain
      into the certification request.  To get these attributes in
      advance, the attribute request SHOULD be used.

   o  Attribute Response: Contains the attributes to be included in the
      certification request message.

   o  Cert Request: Depending on the utilized enrollment protocol, this
      certification request contains the authenticated self-contained
      object ensuring both, proof-of-possession of the corresponding
      private key and proof-of-identity of the requester.

   o  Cert Response: certification response message containing the
      requested certificate and potentially further information like
      certificates of intermediary CAs on the certification path.

   o  Cert Waiting: waiting indication for the pledge to retry after a
      given time.  For this a request identifier is necessary.  This
      request identifier may be either part of the enrollment protocol
      or build based on the certification request.

   o  Cert Polling: querying the registrar, if the certificate request
      was already processed; can be answered either with another Cert
      Waiting, or a Cert Response.

   o  Cert Confirm: confirmation message from pledge after receiving and
      verifying the certificate.

   o  PKI/Registrar Confirm: confirmation message from PKI/registrar
      about reception of the pledge's certificate confirmation.

   [RFC Editor: please delete] /*

   Open Issues:

   o  Description of certificate waiting and retries.

Fries, et al.             Expires July 11, 2021                [Page 18]
Internet-Draft                  BRSKI-AE                    January 2021

   o  Message exchange description is expected to be done by the
      utilized enrollment protocol based on the addressing scheme (see
      also Section 6.

   o  Handling of certificate/PKI confirmation message between pledge
      and domain registrar and PKI (treated optional?).

   */

5.1.5.  Addressing Scheme Enhancements

   BRSKI-AE requires enhancements to the addressing scheme defined in
   [I-D.ietf-anima-bootstrapping-keyinfra] to accommodate the additional
   handling of authenticated self-contained objects for the
   certification request.  As this is supported by different enrollment
   protocols, they can be directly employed (see also Section 6).  For
   the support of different enrollment options at the domain registrar,
   the addressing approach of BRSKI using a "/.well-known" tree from
   [RFC8615] is enhanced.

   The current addressing scheme in BRSKI for the client certificate
   request function during the enrollment is using the definition from
   EST [RFC7030], here on the example on simple enroll: "/.well-
   known/est/simpleenroll" This approach is generalized to the following
   notation: "/.well-known/enrollment-protocol/request" in which
   enrollment-protocol may be an already existing protocol or a newly
   defined approach.  Note that enrollment is considered here as a
   sequence of at least a certification request and a certification
   response.  In case of existing enrollment protocols the following
   notation is used proving compatibility to BRSKI:

   o  enrollment-protocol: references either EST [RFC7030] as in BRSKI
      or CMP, CMC, SCEP, or newly defined approaches as alternatives.
      Note: the IANA registration of the well-known URI is expected to
      be done by the enrollment protocol.  For CMP an update is defined,
      which provides the definition of the well-known URI in CMP Updates
      Lightweight CMP Profile [I-D.ietf-lamps-cmp-updates].

   o  request: depending on the utilized enrollment protocol, the
      request describes the required operation at the registrar side.
      Enrollment protocols are expected to define the request endpoints
      as done by existing protocols (see also Section 6).

5.2.  Use Case 2 (PUSH): pledge-agent

   To support mutual trust establishment of pledges, not directly
   connected to the domain registrar, a similar approach is applied as
   discussed for the use case 1.  It relies on the exchange of

Fries, et al.             Expires July 11, 2021                [Page 19]
Internet-Draft                  BRSKI-AE                    January 2021

   authenticated self-contained objects (the voucher request/response
   objects as known from BRSKI and the certification request/response
   objects as introduced by BRSKI-AE).  This allows independence from
   the protection provided by the underlying transport.

   In contrast to BRSKI, the exchange of these objects is performed with
   the help of a pledge-agent, supporting the interaction of the pledge
   with the domain registrar.  It may be an integrated functionality of
   a commissioning tool.  This leads to enhancements of the logical
   elements in the BRSKI architecture as shown in Figure 3.  The pledge-
   agent interfaces with the pledge to enable creation or consumption of
   required data objects, which are exchanged with the domain registrar.
   Moreover, the addition of the pledge-agent also influences the
   sequences for the data exchange between the pledge and the domain
   registrar described in [I-D.ietf-anima-bootstrapping-keyinfra].  The
   general goal for the pledge-agent application is the reuse of already
   defined endpoints on the domain registrar side.  The behavior of the
   endpoint may need to be adapted.

Fries, et al.             Expires July 11, 2021                [Page 20]
Internet-Draft                  BRSKI-AE                    January 2021

                                             +------------------------+
      +--------------Drop Ship---------------| Vendor Service         |
      |                                      +------------------------+
      |                                      | M anufacturer|         |
      |                                      | A uthorized  |Ownership|
      |                                      | S igning     |Tracker  |
      |                                      | A uthority   |         |
      |                                      +--------------+---------+
      |                                                     ^
      |                                                     |  BRSKI-
      V                                                     |   MASA
   +-------+     +-------+     .............................|.........
   |       |     |       |     .                            |        .
   |       |     |       |     .  +-----------+       +-----v-----+  .
   |       |     |Pledge |     .  |           |       |           |  .
   |Pledge |     | Agent |     .  |   Join    |       | Domain    |  .
   |       |     |       |     .  |   Proxy   |       | Registrar |  .
   |       <----->.......<-------->...........<-------> (PKI RA)  |  .
   |       |     |       |     .  |       BRSKI-AE    |           |  .
   |       |     |       |     .  |           |       +-----+-----+  .
   |IDevID |     |opt.   |     .  +-----------+             |        .
   |       |     |IDevID |     .         +------------------+-----+  .
   |       |     |or     |     .         | Key Infrastructure     |  .
   |       |     |LDevID |     .         | (e.g., PKI Certificate |  .
   +-------+     +-------+     .         |       Authority)       |  .
                               .         +------------------------+  .
                               .......................................
                                         "Domain" components

           Figure 3: Architecture overview using a pledge-agent

   The architecture overview in Figure 3 utilizes the same logical
   components as BRSKI with the pledge-agent component as additional
   component.

   For authentication towards the domain registrar, the pledge-agent may
   use the IDevID or LDevID credentials if available, which are verified
   by the domain registrar as part of the TLS establishment.  The
   provisioning of this credential to the pledge-agent is out of scope
   for this specification.  Alternatively, the domain registrar may
   authenticate the user operating the pledge-agent to perform
   authorization of a pledge onboarding action.  Examples for such user
   level authentication are the application of HTTP authentication or
   the usage of authorization tokens or the application of user related
   certificates in the TLS handshake or other.  If the pledge-agent
   utilizes a certificate, the domain registrar must be able to verify
   the certificate by possessing the corresponding root certificate.

Fries, et al.             Expires July 11, 2021                [Page 21]
Internet-Draft                  BRSKI-AE                    January 2021

   The following list describes the components in the deployment domain:

   o  Pledge: The pledge is expected to respond the necessary data
      objects for bootstrapping to the pledge-agent.  The transport
      protocol used between the pledge and the pledge-agent in the
      context of this document is assumed to be HTTP.  Other transport
      protocols may be used, such as CoAP, but their usage is out of
      scope for this document.  As the pledge is triggered/PUSHED by the
      pledge-agent, it becomes a callee.  This leads to some differences
      to BRSKI:

      *  Discovery of the domain registrar by the pledge will be omitted
         as the pledge is expected to be triggered by the pledge-agent.

      *  Discovery of the pledge by the pledge-agent must be possible to
         enable interaction.

      *  As the pledge-agent must be able to trigger the pledge for
         bootstrapping, the pledge must offer communication endpoints.

      *  The pledge-agent is expected to provide an option to trigger
         the bootstrapping by pushing data objects to the pledge.

      *  Order of exchanges in the call flow is different as the pledge-
         agent collects both voucher request objects and certification
         request objects at once and provides them to the registrar.
         This approach may also be used to perform a bulk bootstrapping
         of several devices.

      *  The data objects utilized for the data exchange between the
         pledge and the registrar are signature-wrapped objects as in
         use case 1 Section 5.1.

   o  Pledge-Agent: provides a communication path to exchange data
      objects between the pledge and the domain registrar.  The pledge-
      agent facilitates situations, in which the domain registrar is not
      directly reachable by the pledge, either due to a different
      technology stack or due to missing connectivity (e.g., if the
      domain registrar resides in the cloud and the pledge has no
      connectivity, yet).  The pledge-agent collect the bootstrapping
      information such as voucher request objects and certification
      request objects from one or multiple pledges at once and performs
      a bulk bootstrapping based on the collected data.  The pledge-
      agent triggers the pledge for generating these objects.  The
      pledge-agent may be configured with the domain registrar
      information or may use the discovery mechanism defined in
      [I-D.ietf-anima-bootstrapping-keyinfra].  The trust assumptions on
      the connection between the pledge and the pledge-agent only

Fries, et al.             Expires July 11, 2021                [Page 22]
Internet-Draft                  BRSKI-AE                    January 2021

      require to ensure proximity between both to provide a minimum
      protection of arbitrary request to generate voucher request
      objects and/or enrollment request objects.  The trust assumptions
      on the connection between the pledge-agent and the registrar only
      requires that the pledge-agent enables the exchange of signature
      wrapped objects between the pledge and the registrar.

   o  Join Proxy: same functionality as described in
      [I-D.ietf-anima-bootstrapping-keyinfra].  Note that it may be used
      by the pledge-agent instead of the pledge.

   o  Domain Registrar: In general the domain registrar fulfills the
      same functionality regarding the bootstrapping of the pledge in
      the deployment domain by facilitating the communication of the
      pledge with the MASA service and the domain PKI service.  In
      contrast to [I-D.ietf-anima-bootstrapping-keyinfra], the domain
      registrar does not interact with a pledge directly but through the
      pledge-agent.  This prohibits a pledge authentication using its
      IDevID during TLS establishment towards the registrar.  If the
      pledge-agent has an IDevID or is already possessing a LDevID valid
      in the deployment domain, it is expected to use this
      authentication towards the domain registrar.

   The manufacturer provided components/services (MASA and Ownership
   tracker) are used as defined in
   [I-D.ietf-anima-bootstrapping-keyinfra].

5.2.1.  Behavior of a pledge

   In contrast to use case 1 Section 5.1 the pledge acts as a server
   component if data is pushed in the bootstrapping phase.  It is
   triggered by the pledge-agent for the generation of voucher request
   and enrollment request objects as well as for the processing of the
   response objects and the generation of status information.  Due to
   the use of the pledge-agent, the interaction with the domain
   registrar is changed as shown in Figure 4.  To enable interaction
   with the pledge-agent, the pledge provides interfaces using the BRSKI
   REST interface based on the "/.well-known/brski" URI tree.  The
   following endpoints are defined for the pledge:

   o  /.well-known/brski/triggervoucherrequest: trigger pledge to create
      voucher request.

   o  /.well-known/brski/triggerenrollrequest: trigger pledge to create
      enrollment request.

   o  /.well-known/brski/supplyvoucherresponse: supply voucher response
      to pledge.

Fries, et al.             Expires July 11, 2021                [Page 23]
Internet-Draft                  BRSKI-AE                    January 2021

   o  /.well-known/brski/supplyenrollresponse: supply enroll response to
      pledge.

   o  /.well-known/brski/supplyCACerts: supply CACerts to pledge
      (optional).

5.2.2.  Behavior of a pledge-agent

   The pledge-agent is a new component in the BRSKI context.  It
   provides connectivity between the pledge and the domain registrar and
   utilizes the endpoints on the domain registrar side already specified
   in [I-D.ietf-anima-bootstrapping-keyinfra].  The pledge-agent is
   expected to interact with the pledge independent of the domain
   registrar.  As stated before, the data exchange concerns the data
   objects exchanged between the pledge and the domain registrar, which
   are the voucher request/response objects, the enrollment request/
   response objects, as well as status information.  As the pledge acts
   as server, it has to provide endpoints to allow for request/response
   interaction.  For the transport HTTPS is chosen in non-constraint
   environments, but may also be performed using other transport
   mechanisms.  This changes the general interaction between the pledge
   and the domain registrar as shown in Figure 4.

   The pledge-agent may have an own IDevID or a deployment domain issued
   LDevID to be utilized in the TLS communication establishment towards
   the domain registrar.  Note that the pledge-agent may also be used
   without TLS client-side authentication if no suitable credential is
   available.  This is a deviation from BRSKI, in which the pledge's
   IDevID credential is used to perform TLS client authentication.  As
   BRSKI-AE targets the use of authenticated self-contained data objects
   between the pledge and the domain registrar, the binding of the
   pledge identity to the requests can be achieved through the data
   object signature.  Nevertheless, the authentication of the pledge-
   agent is recommended if the onboarding is only to be performed by an
   authorized pledge-agent.  This authentication may be realized by a
   device (IDevID or LDevID), and if not available through user related
   credentials in the context of the HTTP based authentication, SAML
   tokens or other.  Note that having no specific credentials on the
   pledge-agent allows to employ applications with low trust
   requirements.

   According to [I-D.ietf-anima-bootstrapping-keyinfra] section 5.3, the
   domain registrar performs the pledge authorization for onboarding
   within his domain based on the provided voucher request.

Fries, et al.             Expires July 11, 2021                [Page 24]
Internet-Draft                  BRSKI-AE                    January 2021

5.2.2.1.  Registrar discovery

   The discovery phase may be applied as specified in
   [I-D.ietf-anima-bootstrapping-keyinfra] with the deviation that it is
   done between the pledge-agent and the domain registrar.
   Alternatively, the pledge-agent may be configured with the address of
   the domain registrar.

5.2.2.2.  Pledge/Pledge-agent discovery

   The discovery of the pledge by pledge-agent is done by mDNS.  The
   pledge constructs a local host name based on device local information
   (device serial number), which results for instance in
   "serialnumber.brski-pledge._tcp.local.".  This can then be discovered
   by the pledge-agent via mDNS.  Note that other mechanisms for
   discovery may be used.

5.2.3.  Protocol Details (Pledge-Agent - Pledge)

   The interaction of the pledge with the pledge-agent may be
   accomplished using different transport means (protocols and or
   network technologies).  For this document the usage of HTTP is
   targeted as in BRSKI.  Alternatives may be CoAP or Bluetooth Low
   Energy (BLE) or Nearfield Communication (NFC).  This requires an
   independence of the security of the exchanged data objects between
   the pledge and the registrar from the security provided by the
   transport.  Therefore, signature-wrapped objects build the base for
   the information exchange between the pledge and the registrar.  Note
   that trigger messages from the pledge-agent may not be signed as the
   pledge has no means to verify them.  Therefore, TLS support is
   required to ensure a secure transport based on a proximity
   information shared between the pledge-agent and the pledge.  This is
   done to ensure that a technician had physical contact to the pledge.

5.2.3.1.  TLS establishment

   The pledge and the pledge-agent establish a TLS secured communication
   channel.  As the IDevID on the pledge cannot be used as TLS server
   certificate, a pre-shared key (PSK) is applied.

   TLS [RFC8446] allows to import externally provided PSKs.  The use of
   an external PSK is defined based on the guidelines provided in
   [I-D.ietf-tls-external-psk-guidance]

   The PSK is derived from information known to the pledge and the
   pledge-agent, which are

Fries, et al.             Expires July 11, 2021                [Page 25]
Internet-Draft                  BRSKI-AE                    January 2021

      device serial-number: Device serial number stored in the pledge
      and also part of the X520SerialNumber (defined in [RFC5280]) as
      part of the IDevID.

      randomizer: additional value, which is not exposed on the
      communication interface of the pledge.  This information may be
      provided through the bill of material or a QR code attached to the
      device and must have a length of at least 128 bits.

   The pledge and the pledge-agent construct the PSK to be used in TLS
   based on a HMAC-based Extract-and-Expand Key Derivation Function
   (HKDF, [RFC5869].).  The PSK is derived following the external PSK
   importer [I-D.ietf-tls-external-psk-importer].  The interface takes
   an EPSK (External PSK) with an external identity and a base key
   (epsk) as input.  The external identity is provided as part of the
   ImportedIdentity structure containing information:

      ImportedIdentity.external_identity = "onboarding"

      ImportedIdentity.context = "brski_proximity"

      ImportedIdentity.target_protocol = 0x0304

      ImportedIdentity.target_kdf = 0x0001

   The target protocol identified is TLS 1.3 (value 0x0304).  The target
   KDF identified is HKDF_SHA256 (value 0x0001).

   The base key is determined as following:

      epsk = serial-number | randomizer

      epskx = HKDF-Extract(0, epsk)

      ipskx = HKDF-Expand-Label(epskx, "derived psk",
      Hash(ImportedIdentity), 32)

   The length value of the HKDF-Expand function is set to 32 octets
   corresponds to the output length of the selected KDF.

   TLS shall be used with the derived IPSK with

      TLS key agreement: "psk_dhe_ke"

      TLS cipher suite: TLS_AES_128_GCM_SHA256

Fries, et al.             Expires July 11, 2021                [Page 26]
Internet-Draft                  BRSKI-AE                    January 2021

5.2.3.2.  Object exchange

   The pledge-agent provides the registrar certificate to the pledge to
   be put into the "proximity-registrar-cert" leaf in the pledge
   voucher-request object.  This enables the registrar to verify, that
   it is the target registrar for the request.  The registrar
   certificate may be configured at the pledge-agent or may be fetched
   by the pledge-agent based on a prior TLS connection establishment
   with the domain registrar.  The pledge-agent triggers the pledge, to
   generate a pledge voucher-request object (PleVouReq) .

   Triggering is done using HTTPS POST with the operation path value of
   "/.well-known/brski/triggervoucherrequest".

   The pledge-agent triggervoucherrequest Content-Type header is:

   application/json: /* to be defined */(different format used as
   response): defines a JSON document to provide the registrar
   certificate to the pledge.  The pledge shall construct the voucher
   request object as defined [I-D.ietf-anima-bootstrapping-keyinfra] and
   sign the request using the pledges IDevID credential.  The response
   is encoded as JSON-in-JWS (or JWS-signed-JSON, tbd).

   After the voucher request exchange the pledge will be triggered to
   generate an enrollment request object.  As in BRSKI the enrollment
   request object is a PKCS#10 request, with an additional wrapping
   signature using the IDevID.  As the initial enrollment aims to
   request a general certificate, no certificate attributes are provided
   to the pledge.

   /* Discussion: The pledge-agent may have been pre-configured with the
   CSR attributes, that it could provide to the pledge to request a
   specific certificate (for a communication endpoint on the pledge.
   This is expected to be done later, once the pledge has an LDevID and
   can be further configured. */

   The enrollment request is generated as authenticated self-signed
   object, which assures proof of possession of the private key
   corresponding to the contained public key in the enrollment request
   as well as a proof of identity, based on the IDevID of the pledge.
   This is done as described for use case 1 Section 5.1.

   The pledge-agent enrollment-request Content-Type header is:

   application/json: to be defined (different format used as response):
   defines a JSON document.  Optional CSR parameter may be provided to
   the pledge.  The pledge shall construct the certification request as
   PKCS#10 object and sign the request using the pledge's IDevID

Fries, et al.             Expires July 11, 2021                [Page 27]
Internet-Draft                  BRSKI-AE                    January 2021

   credential.  The response is encoded as PKCS#10-in-JSON/JWS (tbd).
   If the pledge does not have specific information about the content of
   the LDevID to be applied for (like device name, etc.) the domain
   registrar will provide this information to the issuing CA.

   /* to be discussed */ The domain registrar may either enhance the
   PKCS#10 request or generate a structure containing the attributes to
   be included by the CA and sends both (the original PKCS#10 request
   and the enhancements) to the domain CA.  As enhancing the PKCS#10
   request destroys the initial proof of possession of the corresponding
   private key, the CA would need to accept RA-verified requests.

   With the collected voucher request object and the enrollment request
   object, the pledge-agent starts the interaction with the domain
   registrar.  If the domain registrar is in a different network, the
   pledge-agent closes the TLS session with the pledge (to be resumed
   for provisioning of voucher object and certificate.

   /* further description necessary at least for */

      Consideration of TLS session resumption for the second run

      Authentication of pledge-agent to domain registrar

      Behavior of registrar when pledge LDevID not used in TLS

      Values to be taken from the IDevID into the PKCS#10 (like pledge
      serial number or subjectName, or certificate template)

      PKCS#10-in-JSON/JWS (tbd) handling by domain registrar to request
      a generic LDevID from the domain CA service.

      Order of requests may be different as in BRSKI

      Definition of objects and encoding, some existing encoding may
      change as for the voucher?

   Once the pledge-agent has collected the response objects from the
   domain registrar (voucher and certificate), it will re-start the
   interaction the pledge.  For this the pledge-agent resumes the
   previous TLS connection with the pledge.

   The pledge-agent will provide the information via two distinct
   endpoints at the pledge:

   The voucher response will be provided with a HTTPS POST using the
   operation path value of "/.well-known/brski/supplyvoucherresponse".

Fries, et al.             Expires July 11, 2021                [Page 28]
Internet-Draft                  BRSKI-AE                    January 2021

   The pledge-agent voucher-response Content-Type header is:

   application/jose: /* to be discussed, as the current voucher is a
   "application/voucher-cms+json" object). */ The pledge will generate a
   voucher status object and provides it in the response.  The response
   is encoded as JSON-in-JWS ("application/jose"), signed by the IDevID
   of the pledge (LDevID not available yet).

   The enrollment response will be provided with a HTTPS POST using the
   operation path value of "/.well-known/brski/supplyenrollresponse".

   The pledge-agent enroll-response Content-Type header is:

   application/pkcs7-mime: to be defined (contains LDevID + certificate
   chain).

   /* to be discussed */: the enrollment response object may also be an
   application/jose object with a signature of the domain registrar.
   This may be used either to transport additional data which is bound
   to the LDevID or it may be considered for enrollment status to ensure
   that in an error case the registrar providing the certificate can be
   identified.

   The pledge will generate an enrollment status object as confirmation,
   showing it can apply the certificate and possesses the corresponding
   private key

   The response ist encoded as JSON-in-JWS.  The signature is created
   using the LDevID of the pledge.

5.2.4.  Protocol flow

   The following protocol description assumes an already established TLS
   channel as described in Section 5.2.3.1 and focuses on the exchange
   of signature wrapped objects using endpoints defined for the pledge
   in Section 5.2.3.2

   +--------+      +-------+    +-----------+   +--------+   +---------+
   | Pledge |      | Pledge|    | Domain    |   | Domain |   | Vendor  |
   |        |      | Agent |    | Registrar |   | CA     |   | Service |
   |        |      |       |    |  (JRC)    |   |        |   | (MASA)  |
   +--------+      +-------+    +-----------+   +--------+   +---------+
     |                   |              |               |    Internet |
     |       opt: configure             |               |             |
     |       - registrar-certificate    |               |             |
     |       - optional CSR attributes  |               |             |
     |                   |              |               |             |
     |<TLS Establishment>|              |               |             |

Fries, et al.             Expires July 11, 2021                [Page 29]
Internet-Draft                  BRSKI-AE                    January 2021

     |                   |              |               |             |
   [example: trigger voucher and certification request generation ]   |
     |                   |              |               |             |
     |<-trigger PleVouReq|              |               |             |
     |  (registrar-cert) |              |               |             |
     |- Voucher Request->|              |               |             |
     |                   |              |               |             |
     |<--trigger ER------|              |               |             |
     |                   |              |               |             |
     |----Cert Request-->|              |               |             |
     |                   |<---- TLS --->|               |             |
     |                   |              |               |             |
     |                   |              |               |             |
     |                   |--- VouReq -->|               |             |
     |                   |       [accept device?]       |             |
     |                   |       [contact vendor]       |             |
     |                   |              |----- Voucher Request ------>|
     |                   |              |----- Pledge ID ------------>|
     |                   |              |----- Domain ID ------------>|
     |                   |              |----- optional: nonce ------>|
     |                   |              |             [extract DomainID]
     |                   |              |             [update audit log]
     |                   |              |<--------- Voucher  ---------|
     |                   |<-- Voucher --|               |             |
     |                   |              |<----- device audit log  ----|
     |                   |              |               |             |
   [optional retrieve CA certs]         |               |             |
     |                   |- CACertReq ->|               |             |
     |                   |              |- CACertReq -->|             |
     |                   |              |<-CACertResp --|             |
     |                   |< CACertResp -|               |             |
     |                   |              |               |             |
   [certification request handling pledge-agent and infrastructure]   |
     |                   |-- CertReq -->|               |             |
     |                   |              |-- CertReq --->|             |
     |                   |              |<--CertResp----|             |
     |                   |<-- CertResp -|               |             |
     |                   |              |               |             |
     |                   |              |               |             |
   [push voucher and certificate to pledge, optionally push CA certs] |
     |                   |              |               |             |
     | < TLS Resumption >|              |               |             |
     |                   |              |               |             |
     |<--supply Voucher--|              |               |             |
     |- Voucher Status-->|              |               |             |
     |                   |              |               |             |
     |<---supply Cert----|              |               |             |
     |-- Enroll Status-->|              |               |             |

Fries, et al.             Expires July 11, 2021                [Page 30]
Internet-Draft                  BRSKI-AE                    January 2021

     |                   |              |               |             |
     |                 [voucher status telemetry ]      |             |
     |                   |VoucherStatus>|               |             |
     |                   |[verify audit log and voucher]|             |
     |                   |              |               |             |
     |                   |     [enroll Status]          |             |
     |                   |-- CertConf ->|               |             |
     |                   |              |-- CertConf -->|             |
     |                   |              |               |             |

       Figure 4: Request handling of the pledge using a pledge-agent

   As shown in Figure 4 the pledge-agent collects the voucher request
   and enrollment request objects from a pledge.  As the pledge-agent is
   intended to work between the pledge and the domain registrar, a
   collection of requests from multiple pledges is possible, allowing a
   bulk bootstrapping of multiple pledges using the connection between
   the pledge-agent and the domain registrar.

   The information exchange between the pledge-agent and the domain
   registrar resembles the exchanges between the pledge and the domain
   registrar from BRSKI in the PULL case.

   [RFC Editor: please delete] /* to be discussed: Description on how
   the registrar makes the decision if he is connected with pledge
   directly (as in BRSKI PULL) or with a pledge-agent (PUSH).  This may
   result in a case statement (client-side authentication in TLS, user
   authentication above TLS, etc.) for the TLS connection establishment
   in the original BRSKI document in section 5.1 */

   Once the pledge-agent has finished the exchanges with the domain
   registrar to get the voucher object and the enrollment object, it can
   close the TLS connection to the domain registrar and provide the
   objects to the pledge(s).  The content of the response objects is
   defined through the voucher [RFC8366] and the certificate [RFC5280].

5.3.  Domain registrar support of different enrollment options

   Well-known URIs for different endpoints on the domain registrar are
   already defined as part of the base BRSKI specification.  In
   addition, alternative enrollment endpoints may be supported at the
   domain registrar.  The pledge / pledge-agent will recognize if its
   supported enrollment option is supported by the domain registrar by
   sending a request to its preferred enrollment endpoint.

   The following provides an illustrative example for a domain registrar
   supporting different options for EST as well as CMP to be used in
   BRSKI-AE.  The listing contains the supported endpoints for the

Fries, et al.             Expires July 11, 2021                [Page 31]
Internet-Draft                  BRSKI-AE                    January 2021

   bootstrapping, to which the pledge may connect.  This includes the
   voucher handling as well as the enrollment endpoints.

     </brski/voucherrequest>,ct=voucher-cms+json
     </brski/voucher_status>,ct=json
     </brski/enrollstatus>,ct=json
     </est/cacerts>;ct=pkcs7-mime
     </est/simpleenroll>;ct=pkcs7-mime
     </est/simplereenroll>;ct=pkcs7-mime
     </est/fullcmc>;ct=pkcs7-mime
     </est/serverkeygen>;ct= pkcs7-mime
     </est/csrattrs>;ct=pkcs7-mime
     </cmp/initialization>;ct=pkixcmp
     </cmp/certification>;ct=pkixcmp
     </cmp/keyupdate>;ct=pkixcmp
     </cmp/p10>;ct=pkixcmp
     </cmp/getCAcert>;ct=pkixcmp
     </cmp/getCSRparam>;ct=pkixcmp

   [RFC Editor: please delete] /*

   Open Issues:

   o  Clarify, if /.well-known discovery can be performed as discussed
      in the design team (usage of GET /.well-known/brski to collect
      information about enrollment specific endpoint support, to be
      specified in a separate draft).  Also, is a discovery option
      necessary at all, as the pledge will most likely implement only
      one enrollment option?  It can be helpful in the pledge-agent use
      case, when the pledge-agent has no information about the supported
      enrollment options (less likely).

   o  In addition to the current content types, we may specify that the
      response provide information about different content types as
      multiple values.  This would allow to further adopt the encoding
      of the objects exchanges (ASN.1, JSON, CBOR, ...).  -> dependent
      on the utilized protocol.

   */

6.  Example for signature-wrapping using existing enrollment protocols

   This sections map the requirements to support proof of possession and
   proof of identity to selected existing enrollment protocols.  Note
   that that the work in the ACE WG described in
   [I-D.selander-ace-coap-est-oscore] may be considered here as well, as
   it also addresses the encapsulation of EST in a way to make it

Fries, et al.             Expires July 11, 2021                [Page 32]
Internet-Draft                  BRSKI-AE                    January 2021

   independent from the underlying TLS using OSCORE resulting in an
   authenticated self-contained object.

6.1.  EST Handling

   When using EST [RFC7030], the following constraints should be
   considered:

   o  Proof of possession is provided by using the specified PKCS#10
      structure in the request.

   o  Proof of identity is achieved by signing the certification request
      object, which is only supported when Full PKI Request (the
      /fullcmc endpoint) is used.  This contains sufficient information
      for the RA to make an authorization decision on the received
      certification request.  Note: EST references CMC [RFC5272] for the
      definition of the Full PKI Request.  For proof of identity, the
      signature of the SignedData of the Full PKI Request would be
      calculated using the IDevID credential of the pledge.

   o  [RFC Editor: please delete] /* TBD: in this case the binding to
      the underlying TLS connection is not be necessary. */

   o  When the RA is not available, as per [RFC7030] Section 4.2.3, a
      202 return code should be returned by the Registrar.  The pledge
      in this case would retry a simpleenroll with a PKCS#10 request.
      Note that if the TLS connection is teared down for the waiting
      time, the PKCS#10 request would need to be rebuilt if it contains
      the unique identifier (tls_unique) from the underlying TLS
      connection for the binding.

   o  [RFC Editor: please delete] /* TBD: clarification of retry for
      fullcmc is necessary as not specified in the context of EST */

6.2.  Lightweight CMP Handling

   Instead of using CMP [RFC4210], this specification refers to the
   lightweight CMP profile [I-D.ietf-lamps-lightweight-cmp-profile], as
   it restricts the full featured CMP to the functionality needed here.
   For this, the following constrains should be observed:

   o  For proof of possession, the defined approach in Lightweight CMP
      section 5.1.1 (based on CRMF) and 5.1.5 based on PCKS#10 should be
      supported.

   o  Proof of identity can be provided by using the signatures to
      protect the certificate request message as outlined in section
      4.2.

Fries, et al.             Expires July 11, 2021                [Page 33]
Internet-Draft                  BRSKI-AE                    January 2021

   o  When the RA/CA is not available, a waiting indication should be
      returned in the PKIStatus by the Registrar.  The pledge in this
      case would retry using the PollReqContent with a request
      identifier certReqId provided in the initial CertRequest message
      as specified in section 6.1.4 with delayed enrollment.

7.  IANA Considerations

   This document requires the following IANA actions:

   IANA is requested to enhance the Registry entitled: "BRSKI well-
   known URIs" with the following:

     URI                    document   description
     triggervoucherrequest  [THISRFC]   create voucher request
     triggerenrollrequest   [THISRFC]   create enrollment request
     supplyvoucherresponse  [THISRFC]   supply voucher response
     supplyenrollresponse   [THISRFC]   supply enrollment response
     supplyCACerts          [THISRFC]   supply CA certs

   [RFC Editor: please delete] /* to be done: IANA consideration to be
   included for the defined namespaces in Section 5.1.5 and Section 5.3
   .  */

8.  Privacy Considerations

   [RFC Editor: please delete] /* to be done: clarification necessary */

9.  Security Considerations

9.1.  Exhaustion attack on pledge

   Exhaustion attack on pledge based on DoS attack (connection
   establishment, etc.)

9.2.  PSK usage in TLS establishment

   TLS is used to provide a proximity information to the pledge.  As the
   devices in scope may not feature an input or output interface for
   local interaction, a PSK is use to establish the connection between
   the pledge and the pledge-agent.  Certificate based authentication of
   the pledge cannot be used, as the device does not have the
   appropriate information contained in the IDevID.  The PSK is build
   using a KDF, which uses the serial number of the device, potential
   further device related information and a randomizer value.  This
   information is stored within the pledge and is also part of product
   information (also an QR code attached to the device).  If a potential
   attacker is able to physically access the device, he may read this

Fries, et al.             Expires July 11, 2021                [Page 34]
Internet-Draft                  BRSKI-AE                    January 2021

   information and is to connect to the pledge.  Without physical
   proximity to the device, to capture the QR code information, the
   attacker may guess the device' serial number but will not be able to
   construct the PSK as the randomizer value is not known.

9.3.  Misuse of acquired voucher and enrollment responses

   Pledge-agent that uses acquired voucher and enrollment response for
   domain 1 in domain 2: can be detected in Voucher Request processing
   on domain registrar side.  Requires domain registrar to verify the
   proximity-registrar-cert leaf in the voucher request against his own
   as well as the association of the pledge to his domain based on the
   serial number contained in the voucher.

   Misbinding of pledge by a faked domain registrar is countered as
   described in BRSKI security considerations (section 11.4).

10.  Acknowledgments

   We would like to thank the various reviewers for their input, in
   particular Brian E.  Carpenter, Michael Richardson, Giorgio
   Romanenghi, Oskar Camenzind, for their input and discussion on use
   cases and call flows.

11.  References

11.1.  Normative References

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-45 (work in progress), November 2020.

   [I-D.ietf-tls-external-psk-importer]
              Benjamin, D. and C. Wood, "Importing External PSKs for
              TLS", draft-ietf-tls-external-psk-importer-06 (work in
              progress), December 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

Fries, et al.             Expires July 11, 2021                [Page 35]
Internet-Draft                  BRSKI-AE                    January 2021

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

11.2.  Informative References

   [I-D.ietf-lamps-cmp-updates]
              Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp-
              updates-06 (work in progress), November 2020.

   [I-D.ietf-lamps-lightweight-cmp-profile]
              Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP
              Profile", draft-ietf-lamps-lightweight-cmp-profile-04
              (work in progress), November 2020.

   [I-D.ietf-tls-external-psk-guidance]
              Housley, R., Hoyland, J., Sethi, M., and C. Wood,
              "Guidance for External PSK Usage in TLS", draft-ietf-tls-
              external-psk-guidance-01 (work in progress), November
              2020.

   [I-D.selander-ace-coap-est-oscore]
              Selander, G., Raza, S., Furuhed, M., Vucinic, M., and T.
              Claeys, "Protecting EST Payloads with OSCORE", draft-
              selander-ace-coap-est-oscore-04 (work in progress),
              November 2020.

   [IEC-62351-9]
              International Electrotechnical Commission, "IEC 62351 -
              Power systems management and associated information
              exchange - Data and communications security - Part 9:
              Cyber security key management for power system equipment",
              IEC 62351-9 , May 2017.

   [ISO-IEC-15118-2]
              International Standardization Organization / International
              Electrotechnical Commission, "ISO/IEC 15118-2 Road
              vehicles - Vehicle-to-Grid Communication Interface - Part
              2: Network and application protocol requirements", ISO/
              IEC 15118-2 , April 2014.

Fries, et al.             Expires July 11, 2021                [Page 36]
Internet-Draft                  BRSKI-AE                    January 2021

   [NERC-CIP-005-5]
              North American Reliability Council, "Cyber Security -
              Electronic Security Perimeter", CIP 005-5, December 2013.

   [OCPP]     Open Charge Alliance, "Open Charge Point Protocol 2.0.1
              (Draft)", December 2019.

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              DOI 10.17487/RFC2986, November 2000,
              <https://www.rfc-editor.org/info/rfc2986>.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210,
              DOI 10.17487/RFC4210, September 2005,
              <https://www.rfc-editor.org/info/rfc4210>.

   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
              Certificate Request Message Format (CRMF)", RFC 4211,
              DOI 10.17487/RFC4211, September 2005,
              <https://www.rfc-editor.org/info/rfc4211>.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
              <https://www.rfc-editor.org/info/rfc5272>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Fries, et al.             Expires July 11, 2021                [Page 37]
Internet-Draft                  BRSKI-AE                    January 2021

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [RFC8894]  Gutmann, P., "Simple Certificate Enrolment Protocol",
              RFC 8894, DOI 10.17487/RFC8894, September 2020,
              <https://www.rfc-editor.org/info/rfc8894>.

Appendix A.  History of changes [RFC Editor: please delete]

   From IETF draft 00 -> IETF 01:

   o  Update of scope in Section 3.1 to include in which the pledge acts
      as a server.  This is one main motivation for use case 2.

   o  Rework of use case 2 in Section 5.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.

   o  First description of exchanged object types (needs more work)

   o  Clarification in discovery options for enrollment endpoints at the
      domain registrar based on well-known endpoints in Section 5.3 do
      not result in additional /.well-known URIs.  Update of the
      illustrative example.  Note that the change to /brski for the
      voucher related endpoints has been taken over in the BRSKI main
      document.

   o  Updated references.

   o  Included Thomas Werner as additional author for the document.

   From individual version 03 -> IETF draft 00:

   o  Inclusion of discovery options of enrollment endpoints at the
      domain registrar based on well-known endpoints in Section 5.3 as
      replacement of section 5.1.3 in the individual draft.  This is
      intended to support both use cases in the document.  An
      illustrative example is provided.

   o  Missing details provided for the description and call flow in
      pledge-agent use case Section 5.2, e.g. to accommodate
      distribution of CA certificates.

   o  Updated CMP example in Section 6 to use lightweight CMP instead of
      CMP, as the draft already provides the necessary /.well-known
      endpoints.

Fries, et al.             Expires July 11, 2021                [Page 38]
Internet-Draft                  BRSKI-AE                    January 2021

   o  Requirements discussion moved to separate section in Section 4.
      Shortened description of proof of identity binding and mapping to
      existing protocols.

   o  Removal of copied call flows for voucher exchange and registrar
      discovery flow from [I-D.ietf-anima-bootstrapping-keyinfra] in
      Section 5.1 to avoid doubling or text or inconsistencies.

   o  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:

   o  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.

   o  Simplification of the architecture approach for the initial use
      case having an offsite PKI.

   o  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.

   o  Update of provided examples of the addressing approach used in
      BRSKI to allow for support of multiple enrollment protocols in
      Section 5.1.5.

   From individual version 01 -> 02:

   o  Update of introduction text to clearly relate to the usage of
      IDevID and LDevID.

   o  Definition of the addressing approach used in BRSKI to allow for
      support of multiple enrollment protocols in Section 5.1.5.  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.

Fries, et al.             Expires July 11, 2021                [Page 39]
Internet-Draft                  BRSKI-AE                    January 2021

   o  Update of description of architecture elements and changes to
      BRSKI in Section 5.

   o  Enhanced consideration of existing enrollment protocols in the
      context of mapping the requirements to existing solutions in
      Section 4 and in Section 6.

   From individual version 00 -> 01:

   o  Update of examples, specifically for building automation as well
      as two new application use cases in Section 3.2.

   o  Deletion of asynchronous interaction with MASA to not complicate
      the use case.  Note that the voucher exchange can already be
      handled in an asynchronous manner and is therefore not considered
      further.  This resulted in removal of the alternative path the
      MASA in Figure 1 and the associated description in Section 5.

   o  Enhancement of description of architecture elements and changes to
      BRSKI in Section 5.

   o  Consideration of existing enrollment protocols in the context of
      mapping the requirements to existing solutions in Section 4.

   o  New section starting Section 6 with the mapping to existing
      enrollment protocols by collecting boundary conditions.

Authors' Addresses

   Steffen Fries
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: steffen.fries@siemens.com
   URI:   https://www.siemens.com/

   Hendrik Brockhaus
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: hendrik.brockhaus@siemens.com
   URI:   https://www.siemens.com/

Fries, et al.             Expires July 11, 2021                [Page 40]
Internet-Draft                  BRSKI-AE                    January 2021

   Eliot Lear
   Cisco Systems
   Richtistrasse 7
   Wallisellen  CH-8304
   Switzerland

   Phone: +41 44 878 9200
   Email: lear@cisco.com

   Thomas Werner
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: thomas-werner@siemens.com
   URI:   https://www.siemens.com/

Fries, et al.             Expires July 11, 2021                [Page 41]