<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-anima-brski-ae-13" number="9733" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" prepTime="2025-03-03T15:17:32" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae-13" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9733" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="BRSKI-AE">BRSKI with Alternative Enrollment (BRSKI-AE)</title>
    <seriesInfo name="RFC" value="9733" stream="IETF"/>
    <author initials="D." surname="von Oheimb" fullname="David von Oheimb" role="editor">
      <organization abbrev="Siemens" showOnFrontPage="true">Siemens AG</organization>
      <address>
        <postal>
          <street>Otto-Hahn-Ring 6</street>
          <city>Munich</city>
          <code>81739</code>
          <country>Germany</country>
        </postal>
        <email>david.von.oheimb@siemens.com</email>
        <uri>https://www.siemens.com/</uri>
      </address>
    </author>
    <author initials="S." surname="Fries" fullname="Steffen Fries">
      <organization abbrev="Siemens" showOnFrontPage="true">Siemens AG</organization>
      <address>
        <postal>
          <street>Otto-Hahn-Ring 6</street>
          <city>Munich</city>
          <code>81739</code>
          <country>Germany</country>
        </postal>
        <email>steffen.fries@siemens.com</email>
        <uri>https://www.siemens.com/</uri>
      </address>
    </author>
    <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
      <organization abbrev="Siemens" showOnFrontPage="true">Siemens AG</organization>
      <address>
        <postal>
          <street>Otto-Hahn-Ring 6</street>
          <city>Munich</city>
          <code>81739</code>
          <country>Germany</country>
        </postal>
        <email>hendrik.brockhaus@siemens.com</email>
        <uri>https://www.siemens.com/</uri>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>OPS</area>
    <workgroup>anima</workgroup>
    <keyword>BRSKI</keyword>
    <keyword>IoT</keyword>
    <keyword>zero-touch onboarding</keyword>
    <keyword>alternative enrollment protocols</keyword>
    <keyword>CMP</keyword>
    <keyword>self-contained signed objects</keyword>
    <keyword>end-to-end proof of origin</keyword>
    <keyword>auditable source authentication</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines enhancements to the Bootstrapping Remote Secure
      Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative
      Enrollment (BRSKI-AE).  BRSKI-AE extends BRSKI to support certificate
      enrollment mechanisms instead of the originally specified use of
      Enrollment over Secure Transport (EST).  It supports certificate
      enrollment protocols such as the Certificate Management Protocol (CMP)
      that use authenticated self-contained signed objects for certification
      messages, allowing for flexibility in network device onboarding
      scenarios.  The enhancements address use cases where the existing
      enrollment mechanism may not be feasible or optimal, providing a
      framework for integrating suitable alternative enrollment protocols.
      This document also updates the BRSKI reference architecture to
      accommodate these alternative methods, ensuring secure and scalable
      deployment across a range of network environments.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9733" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-supported-scenarios">Supported Scenarios</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology-and-abbreviatio">Terminology and Abbreviations</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-basic-requirements-and-mapp">Basic Requirements and Mapping to Solutions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-solution-options-for-proof-">Solution Options for Proof of Possession</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-solution-options-for-proof-o">Solution Options for Proof of Identity</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-adaptations-to-brski">Adaptations to BRSKI</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-architecture">Architecture</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-exchange">Message Exchange</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-registrar-discovery">Pledge - Registrar Discovery</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-registrar-masa-vouch">Pledge - Registrar - MASA Voucher Exchange</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-registrar-masa-vouche">Pledge - Registrar - MASA Voucher Status Telemetry</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-registrar-ra-ca-cert">Pledge - Registrar - RA/CA Certificate Enrollment</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.5.1"><xref derivedContent="4.2.5" format="counter" sectionFormat="of" target="section-4.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pledge-registrar-enrollment">Pledge - Registrar Enrollment Status Telemetry</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enhancements-to-the-endpoin">Enhancements to the Endpoint Addressing Scheme of BRSKI</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-instantiation-with-existing">Instantiation with Existing Enrollment Protocols</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-brski-cmp-brski-ae-instanti">BRSKI-CMP: BRSKI-AE Instantiated with CMP</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-support-of-other-enrollment">Support of Other Enrollment Protocols</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-examples">Application Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rolling-stock">Rolling Stock</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-building-automation">Building Automation</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-substation-automation">Substation Automation</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-electric-vehicle-charging-i">Electric Vehicle Charging Infrastructure</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.5">
                <t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent="A.5" format="counter" sectionFormat="of" target="section-appendix.a.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-infrastructure-isolation-po">Infrastructure Isolation Policy</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.6">
                <t indent="0" pn="section-toc.1-1.10.2.6.1"><xref derivedContent="A.6" format="counter" sectionFormat="of" target="section-appendix.a.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sites-with-insufficient-lev">Sites with Insufficient Levels of Operational Security</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Bootstrapping Remote Secure Key Infrastructure (BRSKI) <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> is typically used with Enrollment over Secure
      Transport (EST) <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> as the enrollment protocol for
      operator-specific device certificates, employing HTTP over TLS for
      secure message transfer.  BRSKI-AE is a variant using alternative
      enrollment protocols with authenticated self-contained objects for the
      device certificate enrollment.
      </t>
      <t indent="0" pn="section-1-2">This approach offers several distinct advantages.  It allows for the
      authentication of the origin of requests and responses independently of
      message transfer mechanisms.  This capability facilitates end-to-end
      authentication (i.e., end-to-end proof of origin) across multiple
      transport hops and supports the asynchronous operation of certificate
      enrollment. Consequently, this provides architectural flexibility in
      determining the location and timing for the ultimate authentication and
      authorization of certification requests while ensuring that the
      integrity and authenticity of the enrollment messages are maintained with
      full cryptographic strength.</t>
      <t indent="0" pn="section-1-3">This specification carries over the main characteristics of BRSKI,
      namely:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-4">
        <li pn="section-1-4.1">
          <t indent="0" pn="section-1-4.1.1">The pledge is assumed to have received its Initial Device
          IDentifier (IDevID) <xref target="IEEE_802.1AR-2018" format="default" sectionFormat="of" derivedContent="IEEE_802.1AR-2018"/> credentials
          during its manufacturing.  It uses them to authenticate itself to
          the Manufacturer Authorized Signing Authority (MASA) <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>, to the registrar (which is the access point
          of the target domain), and to possibly further components of the
          domain where it will be operated.</t>
        </li>
        <li pn="section-1-4.2">
          <t indent="0" pn="section-1-4.2.1">The pledge first obtains via the voucher <xref target="RFC8366" format="default" sectionFormat="of" derivedContent="RFC8366"/> exchange a trust anchor for authenticating entities in the
          domain such as the domain registrar.</t>
        </li>
        <li pn="section-1-4.3">
          <t indent="0" pn="section-1-4.3.1">The pledge then obtains its Locally Significant Device IDentifier
          (LDevID) <xref target="IEEE_802.1AR-2018" format="default" sectionFormat="of" derivedContent="IEEE_802.1AR-2018"/>.  To this end, the
          pledge generates a private key, called an "LDevID secret". Then, it
          requests via the domain registrar from the PKI of its new domain a
          domain-specific device certificate, called an "LDevID certificate".
          On success, it receives the LDevID certificate along with its
          certificate chain.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-5">The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID
      certificate enrollment through the use of an alternative protocol to EST
      that:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-6">
        <li pn="section-1-6.1">
          <t indent="0" pn="section-1-6.1.1">supports end-to-end authentication over multiple transport hops and</t>
        </li>
        <li pn="section-1-6.2">
          <t indent="0" pn="section-1-6.2.1">facilitates secure message exchanges over any type of transfer
          mechanism, including asynchronous delivery.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-7">It may be observed that the BRSKI voucher exchange between the
      pledge, registrar, and MASA involves the use of authenticated
      self-contained objects, which inherently possess these properties.</t>
      <t indent="0" pn="section-1-8">The existing well-known URI structure used for BRSKI and EST messages
      is extended by introducing an additional path element that specifies the
      enrollment protocol being employed.</t>
      <t indent="0" pn="section-1-9">This specification allows the registrar to offer multiple enrollment
      protocols, enabling pledges and their developers to select the most
      appropriate one based on the defined overall approach and specific
      endpoints.</t>
      <t indent="0" pn="section-1-10">It may be important to note that <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>
      specifies the use of HTTP over TLS, but variations such as Constrained
      BRSKI <xref target="I-D.ietf-anima-constrained-voucher" format="default" sectionFormat="of" derivedContent="cBRSKI"/>, which uses
      the Constrained Application Protocol (CoAP) over DTLS, are possible as well. In this context, "HTTP" and "TLS"
      are used as references to the most common implementation, though
      variants using CoAP and/or DTLS are implied where applicable, as the
      distinctions are not pertinent here.</t>
      <t indent="0" pn="section-1-11">This specification, together with its referenced documents, is
      sufficient to support BRSKI with the Certificate Management Protocol
      (CMP) <xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480"/> as profiled in the Lightweight CMP
      Profile (LCMPP) <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/>.  Integrating BRSKI with an
      enrollment protocol or profile other than the LCMPP will necessitate
      additional IANA registrations, as detailed in this document.
      Furthermore, additional specifications may be required for the details
      of the protocol or profile, which fall outside the scope of this
      document.</t>
      <section anchor="sup-env" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-supported-scenarios">Supported Scenarios</name>
        <t indent="0" pn="section-1.1-1">BRSKI-AE is designed for use in scenarios such as the following:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-2">
          <li pn="section-1.1-2.1">
            <t indent="0" pn="section-1.1-2.1.1">When pledges and/or the target domain leverage an existing
            certificate enrollment protocol other than EST, such as CMP.</t>
          </li>
          <li pn="section-1.1-2.2">
            <t indent="0" pn="section-1.1-2.2.1">When the application context precludes the use of EST for
            certificate enrollment due to factors such as when:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-2.2.2">
              <li pn="section-1.1-2.2.2.1">
                <t indent="0" pn="section-1.1-2.2.2.1.1">The Registration Authority (RA) is not co-located with the
                registrar and requires end-to-end authentication of
                requesters, which EST does not support over multiple transport
                hops.</t>
              </li>
              <li pn="section-1.1-2.2.2.2">
                <t indent="0" pn="section-1.1-2.2.2.2.1">The RA or Certification Authority (CA) operator mandates
                auditable proof of origin for Certificate Signing Requests
                (CSRs), which cannot be provided by TLS as it only offers
                transient source authentication.</t>
              </li>
              <li pn="section-1.1-2.2.2.3">
                <t indent="0" pn="section-1.1-2.2.2.3.1">Certificates are requested for key types, such as Key
                Encapsulation Mechanism (KEM) keys, that do not support
                signing or other single-shot proof-of-possession methods as
                those described in <xref target="RFC6955" format="default" sectionFormat="of" derivedContent="RFC6955"/>.  EST, which
                relies on CSRs in PKCS #10 format <xref target="RFC2986" format="default" sectionFormat="of" derivedContent="RFC2986"/>,
                does not accommodate these key types because it necessitates
                proof-of-possession methods that operate within a single
                message, whereas proof of possession for KEM keys requires
                prior receipt of a fresh challenge value.</t>
              </li>
              <li pn="section-1.1-2.2.2.4">
                <t indent="0" pn="section-1.1-2.2.2.4.1">The pledge implementation employs security libraries that
                do not support EST or uses a TLS library lacking support for
                the "tls-unique" value <xref target="RFC5929" format="default" sectionFormat="of" derivedContent="RFC5929"/>, which EST
                requires for the strong binding of source authentication.</t>
              </li>
            </ul>
          </li>
          <li pn="section-1.1-2.3">
            <t indent="0" pn="section-1.1-2.3.1">When full RA functionality is not available on-site within the
            target domain, and connectivity to an off-site RA may be
            intermittent or entirely offline.
            </t>
          </li>
          <li pn="section-1.1-2.4">
            <t indent="0" pn="section-1.1-2.4.1">When authoritative actions by a local RA at the registrar are
            insufficient for fully and reliably authorizing pledge
            certification requests, potentially due to a lack of access to
            necessary data or inadequate security measures, such as the local
            storage of private keys.
            </t>
          </li>
        </ul>
        <t indent="0" pn="section-1.1-3">Bootstrapping may be managed in various ways depending on the
        application domain.  <xref target="app-examples" format="default" sectionFormat="of" derivedContent="Appendix A"/> provides
        illustrative examples from different industrial control system
        environments and operational contexts that motivate the support of
        alternative enrollment protocols.</t>
      </section>
    </section>
    <section anchor="terminology-and-abbreviations" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-terminology-and-abbreviatio">Terminology and Abbreviations</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
      <t indent="0" pn="section-2-2">This document relies on the terminology defined in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>, <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, and <xref target="IEEE_802.1AR-2018" format="default" sectionFormat="of" derivedContent="IEEE_802.1AR-2018"/>, which is partly repeated here. Several
	further terms are also described here.</t>
      <t indent="0" pn="section-2-3">To be independent of the terminology of a specific enrollment
	protocol, this document utilizes generic terminology regarding PKI
	management operations.</t>
      <t indent="0" pn="section-2-4">The following terminology is used in this document:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-5">
        <dt pn="section-2-5.1">asynchronous:</dt>
        <dd pn="section-2-5.2">the time-wise interrupted delivery of messages, here, between a
        pledge and some backend system (e.g., an RA).</dd>
        <dt pn="section-2-5.3">attribute request:</dt>
        <dd pn="section-2-5.4">a message requesting content to be included in the certification request.</dd>
        <dt pn="section-2-5.5">attribute response:</dt>
        <dd pn="section-2-5.6">a message providing the answer to the attribute request.</dd>
        <dt pn="section-2-5.7">authenticated self-contained object:</dt>
        <dd pn="section-2-5.8">a data structure that is cryptographically bound to the identity
        of its originator by an attached digital signature on the actual
        object, using a private key of the originator such as the IDevID
        secret.</dd>
        <dt pn="section-2-5.9">backend:</dt>
        <dd pn="section-2-5.10">the placement of a domain component separately from the domain
        registrar; it may be on-site or off-site.</dd>
        <dt pn="section-2-5.11">CA certs request:</dt>
        <dd pn="section-2-5.12">a message requesting CA certificates.</dd>
        <dt pn="section-2-5.13">CA certs response:</dt>
        <dd pn="section-2-5.14">a message providing the answer to a CA certs request.</dd>
        <dt pn="section-2-5.15">certificate confirm:</dt>
        <dd pn="section-2-5.16">a message stating to the backend PKI that the requester of a
	certificate received the new certificate and accepted it.</dd>
        <dt pn="section-2-5.17">certification request:</dt>
        <dd pn="section-2-5.18">a message requesting a certificate with proof of identity.</dd>
        <dt pn="section-2-5.19">certification response:</dt>
        <dd pn="section-2-5.20">a message providing the answer to a certification request.</dd>
        <dt pn="section-2-5.21">local RA:</dt>
        <dd pn="section-2-5.22">the same as LRA.</dd>
        <dt pn="section-2-5.23">off-site:</dt>
        <dd pn="section-2-5.24">the locality of a component, service, or functionality (such as RA
	or CA) that is not at the site of the registrar.  This may be a
	central site or a cloud service, to which connection may be
	intermittent.</dd>
        <dt pn="section-2-5.25">on-site:</dt>
        <dd pn="section-2-5.26">the locality of a component, service, or functionality at the site of
        the registrar.</dd>
        <dt pn="section-2-5.27">PKI/registrar confirm:</dt>
        <dd pn="section-2-5.28">an acknowledgment of the PKI on the certificate confirm.</dd>
        <dt pn="section-2-5.29">pledge:</dt>
        <dd pn="section-2-5.30">a device that is to be bootstrapped into a target domain.  It
        requests an LDevID using IDevID credentials installed by its
        manufacturer.</dd>
        <dt pn="section-2-5.31">registrar:</dt>
        <dd pn="section-2-5.32">short for domain registrar.</dd>
        <dt pn="section-2-5.33">site:</dt>
        <dd pn="section-2-5.34">the locality where an entity such as a pledge, registrar, or PKI
        component is deployed.  The target domain may have multiple sites.</dd>
        <dt pn="section-2-5.35">synchronous:</dt>
        <dd pn="section-2-5.36">the time-wise uninterrupted delivery of messages, here, between a
        pledge and a registrar or backend system (e.g., the MASA).</dd>
        <dt pn="section-2-5.37">target domain:</dt>
        <dd pn="section-2-5.38">the domain that a pledge is going to be bootstrapped into.</dd>
      </dl>
      <t indent="0" pn="section-2-6">The following abbreviations are used in this document:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-7">
        <dt pn="section-2-7.1">BRSKI:</dt>
        <dd pn="section-2-7.2">Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/></dd>
        <dt pn="section-2-7.3">BRSKI-AE:</dt>
        <dd pn="section-2-7.4">BRSKI with Alternative Enrollment. Refers to a
        variation of BRSKI <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> in which BRSKI-EST, the
        enrollment protocol between the pledge and the registrar, is replaced
        by enrollment protocols that support end-to-end authentication of the
        pledge to the RA, such as CMP.</dd>
        <dt pn="section-2-7.5">CA:</dt>
        <dd pn="section-2-7.6">Certification Authority</dd>
        <dt pn="section-2-7.7">CMC:</dt>
        <dd pn="section-2-7.8">Certificate Management over CMS</dd>
        <dt pn="section-2-7.9">CMP:</dt>
        <dd pn="section-2-7.10">Certificate Management Protocol <xref target="RFC4210" format="default" sectionFormat="of" derivedContent="RFC4210"/> <xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480"/></dd>
        <dt pn="section-2-7.11">CMS:</dt>
        <dd pn="section-2-7.12">Cryptographic Message Syntax</dd>
        <dt pn="section-2-7.13">CRMF:</dt>
        <dd pn="section-2-7.14">Certificate Request Message Format</dd>
        <dt pn="section-2-7.15">CSR:</dt>
        <dd pn="section-2-7.16">Certificate Signing Request</dd>
        <dt pn="section-2-7.17">EST:</dt>
        <dd pn="section-2-7.18">Enrollment over Secure Transport <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/></dd>
        <dt pn="section-2-7.19">IDevID:</dt>
        <dd pn="section-2-7.20">Initial Device IDentifier (of a pledge, provided by
        the manufacturer and comprising of a private key and the related X.509
        certificate with its chain).</dd>
        <dt pn="section-2-7.21">LCMPP:</dt>
        <dd pn="section-2-7.22">Lightweight CMP Profile <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/></dd>
        <dt pn="section-2-7.23">LDevID:</dt>
        <dd pn="section-2-7.24">Locally Significant Device IDentifier (of a pledge, provided by
	its target domain and comprising of a private key and the related X.509
	certificate with its chain).</dd>
        <dt pn="section-2-7.25">LRA:</dt>
        <dd pn="section-2-7.26">Local Registration Authority. A subordinate RA that is close to
        entities being enrolled and separate from a subsequent RA.  In
        BRSKI-AE, it is needed if a backend RA is used; in this case, the LRA
        is co-located with the registrar.</dd>
        <dt pn="section-2-7.27">MASA:</dt>
        <dd pn="section-2-7.28">Manufacturer Authorized Signing Authority. Provides vouchers.</dd>
        <dt pn="section-2-7.29">RA:</dt>
        <dd pn="section-2-7.30">Registration Authority. The PKI component to which a CA typically
        delegates certificate management functions such as authenticating
        pledges and performing authorization checks on certification
        requests.</dd>
        <dt pn="section-2-7.31">SCEP:</dt>
        <dd pn="section-2-7.32">Simple Certificate Enrolment Protocol</dd>
      </dl>
    </section>
    <section anchor="req-sol" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-basic-requirements-and-mapp">Basic Requirements and Mapping to Solutions</name>
      <t indent="0" pn="section-3-1">Based on the intended target scenarios described in <xref target="sup-env" format="default" sectionFormat="of" derivedContent="Section 1.1"/> and the application examples described in <xref target="app-examples" format="default" sectionFormat="of" derivedContent="Appendix A"/>, the following requirements are derived to
      support authenticated self-contained objects as containers carrying
      certification requests.</t>
      <t indent="0" pn="section-3-2">The following properties are required for a certification request:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-3">
        <li pn="section-3-3.1">
          <t indent="0" pn="section-3-3.1.1">Proof of possession: demonstrates access to the private key
          corresponding to the public key contained in a certification
          request.  This is typically achieved by a self-signature using the
          corresponding private key but can also be achieved indirectly; see
          <xref section="4.3" sectionFormat="comma" target="RFC4210" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4210#section-4.3" derivedContent="RFC4210"/>.</t>
        </li>
        <li pn="section-3-3.2">
          <t indent="0" pn="section-3-3.2.1">Proof of identity (also called "proof of origin"): provides data
          origin authentication of the certification request.  Typically, this
          is achieved by a signature using the pledge IDevID secret over some
          data, which needs to include a sufficiently strong identifier of the
          pledge, such as the device serial number typically included in the
          subject of the IDevID certificate.</t>
        </li>
      </ul>
      <t indent="0" pn="section-3-4">The remainder of this section gives a non-exhaustive list of solution
      examples, based on existing technology described in IETF documents.</t>
      <section anchor="solutions-PoP" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-solution-options-for-proof-">Solution Options for Proof of Possession</name>
        <t indent="0" pn="section-3.1-1">Certificate Signing Request (CSR) objects are data structures
        protecting only the integrity of the contained data and providing
        proof of possession for a (locally generated) private key.  Important
        types of CSR data structures are:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-2">
          <li pn="section-3.1-2.1">PKCS #10 <xref target="RFC2986" format="default" sectionFormat="of" derivedContent="RFC2986"/>: This very common form of
            CSR is self-signed to protect its integrity and to prove
            possession of the private key that corresponds to the public key
            included in the request.</li>
          <li pn="section-3.1-2.2">Certificate Request Message Format (CRMF) <xref target="RFC4211" format="default" sectionFormat="of" derivedContent="RFC4211"/>: This less common but more general CSR format
            supports several ways of integrity protection and proof of
            possession.  Typically a self-signature is used, which is
            generated over (part of) the structure with the private key
            corresponding to the included public key.  CRMF also supports
            further proof-of-possession methods for types of keys that do not
            have signing capability. For details, see <xref section="4" sectionFormat="comma" target="RFC4211" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4211#section-4" derivedContent="RFC4211"/>.</li>
        </ul>
        <t indent="0" pn="section-3.1-3">It should be noted that the integrity protection of CSRs includes
        the public key because it is part of the data signed by the
        corresponding private key.  Yet, this signature does not provide data
        origin authentication, (i.e., proof of identity of the requester)
        because the key pair involved is new and therefore does not yet have a
        confirmed identity associated with it.
        </t>
      </section>
      <section anchor="solutions-PoI" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-solution-options-for-proof-o">Solution Options for Proof of Identity</name>
        <t indent="0" pn="section-3.2-1">Binding a Certificate Signing Request (CSR) to an existing
        authenticated credential (which in the BRSKI context is the IDevID certificate)
        enables proof of origin, which in turn supports an authorization
        decision on the CSR.</t>
        <t indent="0" pn="section-3.2-2">The binding of data origin authentication to the CSR is typically
        delegated to the protocol used for certificate management.  This
        binding may be achieved through security options in an underlying
        transport protocol such as TLS if the authorization of the
        certification request is (sufficiently) done at the next communication
        hop.  Depending on the key type, the binding can also be done in a
        stronger, transport-independent way by wrapping the CSR with a
        signature.</t>
        <t indent="0" pn="section-3.2-3">This requirement is addressed by existing enrollment protocols in
        various ways, such as:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-4">
          <li pn="section-3.2-4.1">
            <t indent="0" pn="section-3.2-4.1.1">EST <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> and its variant EST-coaps <xref target="RFC9148" format="default" sectionFormat="of" derivedContent="RFC9148"/> utilize PKCS #10 to encode CSRs.  While such
            a CSR has not been designed to include proof of origin, there is a
            limited, indirect way of binding it to the source authentication
            of the underlying TLS session.  This is achieved by including in
            the CSR the "tls-unique" value <xref target="RFC5929" format="default" sectionFormat="of" derivedContent="RFC5929"/> resulting
            from the TLS handshake.  As this is optionally supported by the
            EST <tt>"/simpleenroll"</tt> endpoint used in BRSKI, and the TLS
            handshake employed in BRSKI includes certificate-based client
            authentication of the pledge with its IDevID credentials, the
            proof of pledge identity being an authenticated TLS client can be
            bound to the CSR.</t>
            <t indent="0" pn="section-3.2-4.1.2">Yet, this binding is only valid in the context of the TLS
            session established with the registrar acting as the EST server
            and typically also as an RA.  So even such a cryptographic binding
            of the authenticated pledge identity to the CSR is not visible nor
            verifiable to authorization points outside the registrar, such as
            a (second) RA in the backend.  What the registrar needs to do is
            authenticate and pre-authorize the pledge and indicate this to the
            (second) RA. This is done by signing the forwarded certification
            request with its private key and a related certificate that has
            the id-kp-cmcRA extended key usage attribute.</t>
            <t indent="0" pn="section-3.2-4.1.3"><xref section="2.5" sectionFormat="comma" target="RFC7030" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-2.5" derivedContent="RFC7030"/>
            sketches wrapping CSRs formatted per PKCS #10 with a Full PKI Request
            message sent to the <tt>"/fullcmc"</tt> endpoint.  This would
            allow for source authentication at the message level, such that
            the registrar could forward it to external RAs in a meaningful
            way.  This approach is so far not sufficiently described and
            likely has not been implemented.</t>
          </li>
          <li pn="section-3.2-4.2">
            <t indent="0" pn="section-3.2-4.2.1">The Simple Certificate Enrolment Protocol (SCEP) <xref target="RFC8894" format="default" sectionFormat="of" derivedContent="RFC8894"/> supports using a shared secret (passphrase) or
            an existing certificate to protect CSRs based on SCEP Secure
            Message Objects using Cryptographic Message Syntax (CMS) wrapping <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>. Note
            that the wrapping using an existing IDevID in SCEP is referred to
            as "renewal".  This way, SCEP does not rely on the security of the
            underlying message transfer.</t>
          </li>
          <li pn="section-3.2-4.3">
            <t indent="0" pn="section-3.2-4.3.1">CMP <xref target="RFC4210" format="default" sectionFormat="of" derivedContent="RFC4210"/> <xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480"/> supports
            using a shared secret (passphrase) or an existing certificate,
            which may be an IDevID credential, to authenticate certification
            requests via the PKIProtection structure in a PKIMessage.  The
            certification request is typically encoded utilizing CRMF, while
            PKCS #10 is supported as an alternative.  Thus, CMP does not rely
            on the security of the underlying message transfer.</t>
          </li>
          <li pn="section-3.2-4.4">
            <t indent="0" pn="section-3.2-4.4.1">Certificate Management over CMS (CMC) <xref target="RFC5272" format="default" sectionFormat="of" derivedContent="RFC5272"/>
            also supports utilizing a shared secret (passphrase) or an
            existing certificate to protect certification requests, which can
            be either in a CRMF or PKCS #10 structure.  The proof of identity
            can be provided as part of a Full CMC Request based on CMS <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/> and signed with an existing IDevID secret.
            Thus, CMC does not rely on the security of the underlying message
            transfer.</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.2-5">To sum up, EST does not meet the requirements for authenticated
        self-contained objects, but SCEP, CMP, and CMC do. This document
        primarily focuses on CMP as it has more industry adoption than CMC and
        SCEP has issues not detailed here.</t>
      </section>
    </section>
    <section anchor="uc1" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-adaptations-to-brski">Adaptations to BRSKI</name>
      <t indent="0" pn="section-4-1">To enable using alternative certificate enrollment protocols
      supporting end-to-end authentication, asynchronous enrollment, and more
      general system architectures, BRSKI-AE provides some generalizations on
      BRSKI <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.  This way, authenticated self-contained
      objects such as those described in <xref target="req-sol" format="default" sectionFormat="of" derivedContent="Section 3"/> above can be
      used for certificate enrollment, and RA functionality can be deployed
      freely in the target domain.  Parts of the RA functionality can even be
      distributed over several nodes.</t>
      <t indent="0" pn="section-4-2">The enhancements are kept to a minimum to ensure the reuse of already
      defined architecture elements and interactions.  In general, the
      communication follows the BRSKI model and utilizes the existing BRSKI
      architecture elements.  In particular, the pledge initiates
      communication with the domain registrar and interacts with the MASA as
      usual for voucher request and response processing.</t>
      <section anchor="architecture" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-architecture">Architecture</name>
        <t indent="0" pn="section-4.1-1">The key element of BRSKI-AE is that the authorization of a
        certification request <bcp14>MUST</bcp14> be performed based on an
        authenticated self-contained object.  The certification request is
        bound in a self-contained way to a proof of origin based on the IDevID
        credentials.  Consequently, the certification request
        <bcp14>MAY</bcp14> be transferred using any mechanism or
        protocol. Authentication and authorization of the certification
        request can be done by the domain registrar and/or by backend domain
        components.  As mentioned in <xref target="sup-env" format="default" sectionFormat="of" derivedContent="Section 1.1"/>, these
        components may be offline or off-site.  The registrar and other
        on-site domain components may have no or only temporary (intermittent)
        connectivity to them.</t>
        <t indent="0" pn="section-4.1-2">This leads to generalizations in the placement and enhancements of
        the logical elements as shown in <xref target="uc1figure" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
        <figure anchor="uc1figure" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-architecture-overview-using">Architecture Overview Using Backend PKI Components</name>
          <artset pn="section-4.1-3.1">
            <artwork type="svg" align="left" pn="section-4.1-3.1.1">
	    <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="544" width="544" viewBox="0 0 544 544" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                <path d="M 8,192 L 8,320" fill="none" stroke="black"/>
                <path d="M 32,32 L 32,184" fill="none" stroke="black"/>
                <path d="M 32,448 L 32,496" fill="none" stroke="black"/>
                <path d="M 80,192 L 80,320" fill="none" stroke="black"/>
                <path d="M 112,448 L 112,496" fill="none" stroke="black"/>
                <path d="M 152,224 L 152,288" fill="none" stroke="black"/>
                <path d="M 160,448 L 160,496" fill="none" stroke="black"/>
                <path d="M 216,224 L 216,288" fill="none" stroke="black"/>
                <path d="M 304,224 L 304,288" fill="none" stroke="black"/>
                <path d="M 336,16 L 336,128" fill="none" stroke="black"/>
                <path d="M 376,296 L 376,440" fill="none" stroke="black"/>
                <path d="M 424,224 L 424,288" fill="none" stroke="black"/>
                <path d="M 456,56 L 456,128" fill="none" stroke="black"/>
                <path d="M 472,136 L 472,240" fill="none" stroke="black"/>
                <path d="M 504,448 L 504,496" fill="none" stroke="black"/>
                <path d="M 536,16 L 536,128" fill="none" stroke="black"/>
                <path d="M 336,16 L 536,16" fill="none" stroke="black"/>
                <path d="M 32,32 L 144,32" fill="none" stroke="black"/>
                <path d="M 224,32 L 328,32" fill="none" stroke="black"/>
                <path d="M 336,48 L 536,48" fill="none" stroke="black"/>
                <path d="M 336,128 L 536,128" fill="none" stroke="black"/>
                <path d="M 8,192 L 80,192" fill="none" stroke="black"/>
                <path d="M 152,224 L 216,224" fill="none" stroke="black"/>
                <path d="M 304,224 L 424,224" fill="none" stroke="black"/>
                <path d="M 432,240 L 472,240" fill="none" stroke="black"/>
                <path d="M 88,256 L 144,256" fill="none" stroke="black"/>
                <path d="M 224,256 L 296,256" fill="none" stroke="black"/>
                <path d="M 152,288 L 216,288" fill="none" stroke="black"/>
                <path d="M 304,288 L 424,288" fill="none" stroke="black"/>
                <path d="M 8,320 L 80,320" fill="none" stroke="black"/>
                <path d="M 32,448 L 112,448" fill="none" stroke="black"/>
                <path d="M 160,448 L 504,448" fill="none" stroke="black"/>
                <path d="M 120,464 L 160,464" fill="none" stroke="black"/>
                <path d="M 112,480 L 152,480" fill="none" stroke="black"/>
                <path d="M 32,496 L 112,496" fill="none" stroke="black"/>
                <path d="M 160,496 L 504,496" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="480,136 468,130.4 468,141.6" fill="black" transform="rotate(270,472,136)"/>
                <polygon class="arrowhead" points="440,240 428,234.4 428,245.6" fill="black" transform="rotate(180,432,240)"/>
                <polygon class="arrowhead" points="384,440 372,434.4 372,445.6" fill="black" transform="rotate(90,376,440)"/>
                <polygon class="arrowhead" points="384,296 372,290.4 372,301.6" fill="black" transform="rotate(270,376,296)"/>
                <polygon class="arrowhead" points="304,256 292,250.4 292,261.6" fill="black" transform="rotate(0,296,256)"/>
                <polygon class="arrowhead" points="232,256 220,250.4 220,261.6" fill="black" transform="rotate(180,224,256)"/>
                <polygon class="arrowhead" points="160,480 148,474.4 148,485.6" fill="black" transform="rotate(0,152,480)"/>
                <polygon class="arrowhead" points="152,256 140,250.4 140,261.6" fill="black" transform="rotate(0,144,256)"/>
                <polygon class="arrowhead" points="128,464 116,458.4 116,469.6" fill="black" transform="rotate(180,120,464)"/>
                <polygon class="arrowhead" points="96,256 84,250.4 84,261.6" fill="black" transform="rotate(180,88,256)"/>
                <polygon class="arrowhead" points="40,184 28,178.4 28,189.6" fill="black" transform="rotate(90,32,184)"/>
                <g class="text">
                  <text x="184" y="36">Drop-Ship</text>
                  <text x="404" y="36">Vendor Service</text>
                  <text x="400" y="68">M anufacturer</text>
                  <text x="392" y="84">A uthorized</text>
                  <text x="496" y="84">Ownership</text>
                  <text x="380" y="100">S igning</text>
                  <text x="488" y="100">Tracker</text>
                  <text x="388" y="116">A uthority</text>
                  <text x="288" y="196">.........................................</text>
                  <text x="128" y="212">.</text>
                  <text x="448" y="212">.</text>
                  <text x="508" y="212">BRSKI-</text>
                  <text x="128" y="228">.</text>
                  <text x="448" y="228">.</text>
                  <text x="500" y="228">MASA</text>
                  <text x="44" y="244">Pledge</text>
                  <text x="128" y="244">.</text>
                  <text x="180" y="244">Join</text>
                  <text x="340" y="244">Domain</text>
                  <text x="184" y="260">Proxy</text>
                  <text x="364" y="260">Registrar w/</text>
                  <text x="448" y="260">.</text>
                  <text x="128" y="276">.</text>
                  <text x="184" y="276">.......</text>
                  <text x="352" y="276">LRA or RA</text>
                  <text x="448" y="276">.</text>
                  <text x="44" y="292">IDevID</text>
                  <text x="128" y="292">.</text>
                  <text x="448" y="292">.</text>
                  <text x="176" y="308">BRSKI-AE over TLS</text>
                  <text x="448" y="308">.</text>
                  <text x="180" y="324">using, e.g., LCMPP</text>
                  <text x="448" y="324">.</text>
                  <text x="128" y="340">.</text>
                  <text x="448" y="340">.</text>
                  <text x="248" y="356">...............................</text>
                  <text x="416" y="356">.........</text>
                  <text x="232" y="372">on-site (local) domain components</text>
                  <text x="432" y="388">e.g., LCMPP</text>
                  <text x="192" y="420">.............................................</text>
                  <text x="452" y="420">..................</text>
                  <text x="144" y="436">. Public-Key Infrastructure (PKI)</text>
                  <text x="520" y="436">.</text>
                  <text x="16" y="452">.</text>
                  <text x="520" y="452">.</text>
                  <text x="16" y="468">.</text>
                  <text x="276" y="468">Registration Authority</text>
                  <text x="520" y="468">.</text>
                  <text x="16" y="484">.</text>
                  <text x="76" y="484">CA</text>
                  <text x="332" y="484">RA (unless part of Domain Registrar)</text>
                  <text x="520" y="484">.</text>
                  <text x="16" y="500">.</text>
                  <text x="520" y="500">.</text>
                  <text x="268" y="516">................................................................</text>
                  <text x="264" y="532">backend (central or off-site) domain components</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="left" pn="section-4.1-3.1.2">
                                         +------------------------+
   +--------------Drop-Ship--------------| Vendor Service         |
   |                                     +------------------------+
   |                                     | M anufacturer|         |
   |                                     | A uthorized  |Ownership|
   |                                     | S igning     |Tracker  |
   |                                     | A uthority   |         |
   |                                     +--------------+---------+
   |                                                      ^
   |                                                      |
   V                                                      | BRSKI-
+--------+     .........................................  | MASA
|        |     .                                       .  |
|        |     .  +-------+          +--------------+  .  |
| Pledge |     .  | Join  |          | Domain       |&lt;----+
|        |&lt;------&gt;| Proxy |&lt;--------&gt;| Registrar    |  .
|        |     .  |       |          | w/ LRA or RA |  .
| IDevID |     .  +-------+          +--------------+  .
|        |   BRSKI-AE over TLS                ^        .
+--------+   using, e.g., LCMPP               |        .
               .                              |        .
               ...............................|.........
            on-site (local) domain components |
                                              |
                                              | e.g., LCMPP
                                              |
 .............................................|...............
 . Public-Key Infrastructure (PKI)            v              .
 . +---------+     +---------------------------------------+ .
 . |         |&lt;----+   Registration Authority RA           | .
 . |    CA   +----&gt;|   (unless part of Domain Registrar)   | .
 . +---------+     +---------------------------------------+ .
 .............................................................
         backend (central or off-site) domain components
</artwork>
          </artset>
        </figure>
        <t indent="0" pn="section-4.1-4">The architecture overview in <xref target="uc1figure" format="default" sectionFormat="of" derivedContent="Figure 1"/> has the
        same logical elements as BRSKI but with a more flexible placement of
        the authentication and authorization checks on certification requests.
        Depending on the application scenario, the registrar
        <bcp14>MAY</bcp14> still do all of these checks (as is the case in
        BRSKI) or only do part of them.</t>
        <t indent="0" pn="section-4.1-5">The following list describes the on-site components in the target
        domain of the pledge shown in <xref target="uc1figure" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-6">
          <li pn="section-4.1-6.1">
            <t indent="0" pn="section-4.1-6.1.1">Join Proxy: This has the same requirements as in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> (see
            <xref section="4" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-4" derivedContent="RFC8995"/>).</t>
          </li>
          <li pn="section-4.1-6.2">
            <t indent="0" pn="section-4.1-6.2.1">Domain Registrar (including LRA or RA functionality): In
            BRSKI-AE, the domain registrar has mostly the same functionality
            as in BRSKI, namely to act as the gatekeeper of the domain for
            onboarding new devices and to facilitate the communication of
            pledges with their MASA and the domain PKI.  Yet, there are some
            generalizations and specific requirements:</t>
            <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-6.2.2"><li pn="section-4.1-6.2.2.1" derivedCounter="1.">
                <t indent="0" pn="section-4.1-6.2.2.1.1">The registrar <bcp14>MUST</bcp14> support at least one
            certificate enrollment protocol with authenticated self-contained
            objects for certification requests.  To this end, the URI scheme
            for addressing endpoints at the registrar is generalized (see
            <xref target="addressing" format="default" sectionFormat="of" derivedContent="Section 4.3"/>).</t>
              </li>
              <li pn="section-4.1-6.2.2.2" derivedCounter="2.">
                <t indent="0" pn="section-4.1-6.2.2.2.1">Rather than having full RA functionality, the registrar
		<bcp14>MAY</bcp14> act as a Local Registration Authority (LRA)
		and delegate part of its involvement in certificate enrollment
		to a backend RA.  In such scenarios, the registrar optionally
		checks certification requests it receives from pledges and
		forwards them to the backend RA, which performs the remaining
		parts of the enrollment request validation and authorization.
		Note that to this end, the backend RA may need information
		regarding the authorization of pledges from the registrar or
		from other sources.  On the way back, the registrar forwards
		responses by the PKI to the pledge on the same channel.</t>
                <t indent="0" pn="section-4.1-6.2.2.2.2">To support end-to-end authentication of the pledge across
                the registrar to the backend RA, the certification request
                signed by the pledge needs to be upheld and forwarded by the
                registrar.  Therefore, for its communication with the PKI, the
                registrar cannot use an enrollment protocol that is different
                from the enrollment protocol used between the pledge and the
                registrar.</t>
              </li>
              <li pn="section-4.1-6.2.2.3" derivedCounter="3.">
                <t indent="0" pn="section-4.1-6.2.2.3.1">The use of a certificate enrollment protocol with
                authenticated self-contained objects gives freedom with how to
                transfer enrollment messages between the pledge and an RA.
                BRSKI demands that the RA accept certification requests for
                LDevIDs only with the consent of the registrar.  BRSKI-AE also
                guarantees this in the case that the RA is not part of the
                registrar, even if the message exchange with backend systems
                is unprotected and involves further transport hops.  See <xref target="sec-consider" format="default" sectionFormat="of" derivedContent="Section 7"/> for details on how this can be
                achieved.</t>
              </li>
            </ol>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-7">Despite the above generalizations of the enrollment phase, the final
       step of BRSKI, namely the enrollment status telemetry, is kept as it
       is.</t>
        <t indent="0" pn="section-4.1-8">The following list describes the components provided by the vendor
        or manufacturer outside the target domain.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-9">
          <li pn="section-4.1-9.1">
            <t indent="0" pn="section-4.1-9.1.1">MASA: This has the functionality as described in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.  The voucher exchange with the MASA via the
            domain registrar is performed as described in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</t>
          </li>
        </ul>
        <aside pn="section-4.1-10">
          <t indent="0" pn="section-4.1-10.1">Note: The definition of the interaction with the MASA in <xref section="5" sectionFormat="of" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5" derivedContent="RFC8995"/> implies that it
	  may be synchronous (using voucher requests with nonces) or
	  asynchronous (using nonceless voucher requests).</t>
        </aside>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-11">
          <li pn="section-4.1-11.1">
            <t indent="0" pn="section-4.1-11.1.1">Ownership Tracker: This is as defined in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-12">The following list describes backend target domain components,
        which may be located on-site or off-site in the target domain.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-13">
          <li pn="section-4.1-13.1">
            <t indent="0" pn="section-4.1-13.1.1">RA: This performs centralized certificate management functions
            as a PKI for the domain operator.  In case
            these functions are not entirely performed by the domain
            registrar, it performs the final validation and authorization of
            certification requests.  Otherwise, the RA co-located with the
            domain registrar directly connects to the CA.</t>
          </li>
          <li pn="section-4.1-13.2">
            <t indent="0" pn="section-4.1-13.2.1">CA (also called "domain CA"): This generates domain-specific
            certificates according to certification requests that have been
            authenticated and authorized by the registrar and/or an extra
            RA.</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.1-14">Based on the diagram in <xref section="2.1" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-2.1" derivedContent="RFC8995"/> and the architectural changes, the original
        protocol flow is divided into several phases showing commonalities and
        differences with the original approach as follows.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-15">
          <li pn="section-4.1-15.1">
            <t indent="0" pn="section-4.1-15.1.1">Discover: This is mostly as in step (1) of <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>. For details, see
            <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>.</t>
          </li>
          <li pn="section-4.1-15.2">
            <t indent="0" pn="section-4.1-15.2.1">Identify: This is the same as in step (2) of <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</t>
          </li>
          <li pn="section-4.1-15.3">
            <t indent="0" pn="section-4.1-15.3.1">Voucher exchange: This is the same as in steps (3) and (4) of <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</t>
          </li>
          <li pn="section-4.1-15.4">
            <t indent="0" pn="section-4.1-15.4.1">Voucher status telemetry: This is the same as directly after step (4) in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</t>
          </li>
          <li pn="section-4.1-15.5">
            <t indent="0" pn="section-4.1-15.5.1">Certificate enrollment phase: The use of EST in step (5) is
            changed to employing a certificate enrollment protocol that uses
            an authenticated self-contained object for requesting the LDevID
            certificate.</t>
            <t indent="0" pn="section-4.1-15.5.2">It is <bcp14>REQUIRED</bcp14> to use the (D)TLS channel
            established between the pledge and registrar to transport the
            certificate enrollment request and response messages.  To this
            end, the enrollment protocol, the pledge, and the registrar need
            to support the use of this existing channel for certificate
            enrollment.  Due to this architecture, the pledge does not need to
            establish additional connections for certificate enrollment and
            the registrar retains full control over the certificate enrollment
            traffic.</t>
          </li>
          <li pn="section-4.1-15.6">
            <t indent="0" pn="section-4.1-15.6.1">Enrollment status telemetry: This is the final exchange of step (5) of <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</t>
          </li>
        </ul>
      </section>
      <section anchor="message_ex" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-message-exchange">Message Exchange</name>
        <t indent="0" pn="section-4.2-1">The behavior of a pledge described in <xref section="2.1" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-2.1" derivedContent="RFC8995"/> is kept, with one major
        exception.  After finishing the Imprint step (4), the Enroll step (5)
        <bcp14>MUST</bcp14> be performed with an enrollment protocol utilizing
        authenticated self-contained objects, as explained in <xref target="req-sol" format="default" sectionFormat="of" derivedContent="Section 3"/>.

        <xref target="exist_prot" format="default" sectionFormat="of" derivedContent="Section 5"/> discusses selected suitable enrollment
        protocols and applicable options.</t>
        <t indent="0" pn="section-4.2-2">An abstract overview of the BRSKI-AE protocol can be found in the
        graphics on slide 4 of <xref target="BRSKI-AE-overview" format="default" sectionFormat="of" derivedContent="BRSKI-AE-overview"/>.</t>
        <section anchor="discovery" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-pledge-registrar-discovery">Pledge - Registrar Discovery</name>
          <t indent="0" pn="section-4.2.1-1">Discovery as specified in <xref section="4" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-4" derivedContent="RFC8995"/> does not support the discovery of registrars with
          enhanced feature sets.  A pledge cannot find out in this way whether
          discovered registrars support the certificate enrollment protocol it
          expects, such as CMP.</t>
          <t indent="0" pn="section-4.2.1-2">As a more general solution, the BRSKI discovery mechanism can be
          extended to provide up-front information on the capabilities of
          registrars.  For further discussion, see <xref target="I-D.ietf-anima-brski-discovery" format="default" sectionFormat="of" derivedContent="BRSKI-discovery"/>.</t>
          <t indent="0" pn="section-4.2.1-3">In the absence of such a generally applicable solution, BRSKI-AE
          deployments may use their particular way of doing discovery.  <xref target="brski-cmp-instance" format="default" sectionFormat="of" derivedContent="Section 5.1"/> defines a minimalist approach that
          <bcp14>MAY</bcp14> be used for CMP.</t>
        </section>
        <section anchor="pledge-registrar-masa-voucher-exchange" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2">
          <name slugifiedName="name-pledge-registrar-masa-vouch">Pledge - Registrar - MASA Voucher Exchange</name>
          <t indent="0" pn="section-4.2.2-1">The voucher exchange is performed as specified in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>.</t>
        </section>
        <section anchor="pledge-registrar-masa-voucher-status-telemetry" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.3">
          <name slugifiedName="name-pledge-registrar-masa-vouche">Pledge - Registrar - MASA Voucher Status Telemetry</name>
          <t indent="0" pn="section-4.2.3-1">The voucher status telemetry is performed as specified in <xref section="5.7" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5.7" derivedContent="RFC8995"/>.</t>
        </section>
        <section anchor="pledge-registrar-raca-certificate-enrollment" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.4">
          <name slugifiedName="name-pledge-registrar-ra-ca-cert">Pledge - Registrar - RA/CA Certificate Enrollment</name>
          <t indent="0" pn="section-4.2.4-1">The specification in this section replaces the EST integration
          for PKI bootstrapping described in <xref section="5.9" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5.9" derivedContent="RFC8995"/> (while <xref section="5.9.4" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5.9.4" derivedContent="RFC8995"/> remains as
          the final phase; see below).</t>
          <t indent="0" pn="section-4.2.4-2">The certificate enrollment phase may involve the transmission of
          several messages.  Details can depend on the application scenario,
          the employed enrollment protocol, and other factors.
          </t>
          <t indent="0" pn="section-4.2.4-3">The only message exchange <bcp14>REQUIRED</bcp14> is for the
          actual certification request and response.  Further message
          exchanges <bcp14>MAY</bcp14> be performed as needed.</t>
          <aside pn="section-4.2.4-4">
            <t indent="0" pn="section-4.2.4-4.1">Note: The message exchanges marked <bcp14>OPTIONAL</bcp14> in
	    <xref target="enrollfigure" format="default" sectionFormat="of" derivedContent="Figure 2"/> below cover all those supported by
	    the use of EST in BRSKI.  The last <bcp14>OPTIONAL</bcp14> one,
	    namely certificate confirmation, is not supported by EST but by
	    CMP and other enrollment protocols.</t>
          </aside>
          <figure anchor="enrollfigure" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="name-certificate-enrollment-mess">Certificate Enrollment Message Flow</name>
            <artset pn="section-4.2.4-5.1">
              <artwork type="svg" align="left" pn="section-4.2.4-5.1.1">
		<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="576" width="560" viewBox="0 0 560 576" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                  <path d="M 8,32 L 8,96" fill="none" stroke="black"/>
                  <path d="M 16,104 L 16,560" fill="none" stroke="black"/>
                  <path d="M 64,32 L 64,96" fill="none" stroke="black"/>
                  <path d="M 280,32 L 280,96" fill="none" stroke="black"/>
                  <path d="M 320,104 L 320,560" fill="none" stroke="black"/>
                  <path d="M 360,32 L 360,96" fill="none" stroke="black"/>
                  <path d="M 480,32 L 480,96" fill="none" stroke="black"/>
                  <path d="M 544,104 L 544,560" fill="none" stroke="black"/>
                  <path d="M 552,32 L 552,96" fill="none" stroke="black"/>
                  <path d="M 8,32 L 64,32" fill="none" stroke="black"/>
                  <path d="M 280,32 L 360,32" fill="none" stroke="black"/>
                  <path d="M 480,32 L 552,32" fill="none" stroke="black"/>
                  <path d="M 8,96 L 64,96" fill="none" stroke="black"/>
                  <path d="M 280,96 L 360,96" fill="none" stroke="black"/>
                  <path d="M 480,96 L 552,96" fill="none" stroke="black"/>
                  <path d="M 24,144 L 72,144" fill="none" stroke="black"/>
                  <path d="M 256,144 L 312,144" fill="none" stroke="black"/>
                  <path d="M 328,176 L 344,176" fill="none" stroke="black"/>
                  <path d="M 496,176 L 536,176" fill="none" stroke="black"/>
                  <path d="M 328,192 L 344,192" fill="none" stroke="black"/>
                  <path d="M 504,192 L 536,192" fill="none" stroke="black"/>
                  <path d="M 24,208 L 72,208" fill="none" stroke="black"/>
                  <path d="M 264,208 L 312,208" fill="none" stroke="black"/>
                  <path d="M 24,272 L 72,272" fill="none" stroke="black"/>
                  <path d="M 264,272 L 312,272" fill="none" stroke="black"/>
                  <path d="M 328,304 L 344,304" fill="none" stroke="black"/>
                  <path d="M 504,304 L 536,304" fill="none" stroke="black"/>
                  <path d="M 328,320 L 344,320" fill="none" stroke="black"/>
                  <path d="M 512,320 L 536,320" fill="none" stroke="black"/>
                  <path d="M 24,336 L 72,336" fill="none" stroke="black"/>
                  <path d="M 272,336 L 312,336" fill="none" stroke="black"/>
                  <path d="M 24,384 L 72,384" fill="none" stroke="black"/>
                  <path d="M 296,384 L 312,384" fill="none" stroke="black"/>
                  <path d="M 328,416 L 344,416" fill="none" stroke="black"/>
                  <path d="M 520,416 L 536,416" fill="none" stroke="black"/>
                  <path d="M 328,432 L 344,432" fill="none" stroke="black"/>
                  <path d="M 520,432 L 536,432" fill="none" stroke="black"/>
                  <path d="M 24,448 L 64,448" fill="none" stroke="black"/>
                  <path d="M 296,448 L 312,448" fill="none" stroke="black"/>
                  <path d="M 24,496 L 72,496" fill="none" stroke="black"/>
                  <path d="M 280,496 L 312,496" fill="none" stroke="black"/>
                  <path d="M 328,528 L 344,528" fill="none" stroke="black"/>
                  <path d="M 512,528 L 536,528" fill="none" stroke="black"/>
                  <path d="M 328,544 L 344,544" fill="none" stroke="black"/>
                  <path d="M 456,544 L 536,544" fill="none" stroke="black"/>
                  <path d="M 24,560 L 72,560" fill="none" stroke="black"/>
                  <path d="M 296,560 L 312,560" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="544,528 532,522.4 532,533.6" fill="black" transform="rotate(0,536,528)"/>
                  <polygon class="arrowhead" points="544,416 532,410.4 532,421.6" fill="black" transform="rotate(0,536,416)"/>
                  <polygon class="arrowhead" points="544,304 532,298.4 532,309.6" fill="black" transform="rotate(0,536,304)"/>
                  <polygon class="arrowhead" points="544,176 532,170.4 532,181.6" fill="black" transform="rotate(0,536,176)"/>
                  <polygon class="arrowhead" points="336,544 324,538.4 324,549.6" fill="black" transform="rotate(180,328,544)"/>
                  <polygon class="arrowhead" points="336,432 324,426.4 324,437.6" fill="black" transform="rotate(180,328,432)"/>
                  <polygon class="arrowhead" points="336,320 324,314.4 324,325.6" fill="black" transform="rotate(180,328,320)"/>
                  <polygon class="arrowhead" points="336,192 324,186.4 324,197.6" fill="black" transform="rotate(180,328,192)"/>
                  <polygon class="arrowhead" points="320,496 308,490.4 308,501.6" fill="black" transform="rotate(0,312,496)"/>
                  <polygon class="arrowhead" points="320,384 308,378.4 308,389.6" fill="black" transform="rotate(0,312,384)"/>
                  <polygon class="arrowhead" points="320,272 308,266.4 308,277.6" fill="black" transform="rotate(0,312,272)"/>
                  <polygon class="arrowhead" points="320,144 308,138.4 308,149.6" fill="black" transform="rotate(0,312,144)"/>
                  <polygon class="arrowhead" points="32,560 20,554.4 20,565.6" fill="black" transform="rotate(180,24,560)"/>
                  <polygon class="arrowhead" points="32,448 20,442.4 20,453.6" fill="black" transform="rotate(180,24,448)"/>
                  <polygon class="arrowhead" points="32,336 20,330.4 20,341.6" fill="black" transform="rotate(180,24,336)"/>
                  <polygon class="arrowhead" points="32,208 20,202.4 20,213.6" fill="black" transform="rotate(180,24,208)"/>
                  <g class="text">
                    <text x="36" y="52">Pledge</text>
                    <text x="308" y="52">Domain</text>
                    <text x="516" y="52">Operator</text>
                    <text x="320" y="68">Registrar</text>
                    <text x="504" y="68">RA/CA</text>
                    <text x="304" y="84">(JRC)</text>
                    <text x="504" y="84">(PKI)</text>
                    <text x="56" y="132">[OPTIONAL</text>
                    <text x="128" y="132">request</text>
                    <text x="172" y="132">of</text>
                    <text x="196" y="132">CA</text>
                    <text x="264" y="132">certificates]</text>
                    <text x="92" y="148">CA</text>
                    <text x="128" y="148">Certs</text>
                    <text x="184" y="148">Request</text>
                    <text x="232" y="148">(1)</text>
                    <text x="368" y="164">[OPTIONAL</text>
                    <text x="456" y="164">forwarding]</text>
                    <text x="364" y="180">CA</text>
                    <text x="400" y="180">Certs</text>
                    <text x="456" y="180">Request</text>
                    <text x="364" y="196">CA</text>
                    <text x="400" y="196">Certs</text>
                    <text x="460" y="196">Response</text>
                    <text x="92" y="212">CA</text>
                    <text x="128" y="212">Certs</text>
                    <text x="188" y="212">Response</text>
                    <text x="240" y="212">(2)</text>
                    <text x="56" y="244">[OPTIONAL</text>
                    <text x="128" y="244">request</text>
                    <text x="172" y="244">of</text>
                    <text x="228" y="244">attributes</text>
                    <text x="36" y="260">to</text>
                    <text x="80" y="260">include</text>
                    <text x="124" y="260">in</text>
                    <text x="192" y="260">Certification</text>
                    <text x="284" y="260">Request]</text>
                    <text x="120" y="276">Attribute</text>
                    <text x="192" y="276">Request</text>
                    <text x="240" y="276">(3)</text>
                    <text x="368" y="292">[OPTIONAL</text>
                    <text x="456" y="292">forwarding]</text>
                    <text x="392" y="308">Attribute</text>
                    <text x="464" y="308">Request</text>
                    <text x="392" y="324">Attribute</text>
                    <text x="468" y="324">Response</text>
                    <text x="120" y="340">Attribute</text>
                    <text x="196" y="340">Response</text>
                    <text x="248" y="340">(4)</text>
                    <text x="56" y="372">[REQUIRED</text>
                    <text x="152" y="372">certification</text>
                    <text x="244" y="372">request]</text>
                    <text x="136" y="388">Certification</text>
                    <text x="224" y="388">Request</text>
                    <text x="272" y="388">(5)</text>
                    <text x="368" y="404">[OPTIONAL</text>
                    <text x="456" y="404">forwarding]</text>
                    <text x="400" y="420">Certification</text>
                    <text x="488" y="420">Request</text>
                    <text x="400" y="436">Certification</text>
                    <text x="480" y="436">Resp.</text>
                    <text x="128" y="452">Certification</text>
                    <text x="220" y="452">Response</text>
                    <text x="272" y="452">(6)</text>
                    <text x="56" y="484">[OPTIONAL</text>
                    <text x="144" y="484">certificate</text>
                    <text x="248" y="484">confirmation]</text>
                    <text x="128" y="500">Certificate</text>
                    <text x="208" y="500">Confirm</text>
                    <text x="256" y="500">(7)</text>
                    <text x="368" y="516">[OPTIONAL</text>
                    <text x="456" y="516">forwarding]</text>
                    <text x="400" y="532">Certificate</text>
                    <text x="480" y="532">Confirm</text>
                    <text x="368" y="548">PKI</text>
                    <text x="416" y="548">Confirm</text>
                    <text x="136" y="564">PKI/Registrar</text>
                    <text x="224" y="564">Confirm</text>
                    <text x="272" y="564">(8)</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art" align="left" pn="section-4.2.4-5.1.2">
+------+                          +---------+              +--------+
|Pledge|                          |Domain   |              |Operator|
|      |                          |Registrar|              |RA/CA   |
|      |                          |(JRC)    |              |(PKI)   |
+------+                          +---------+              +--------+
 |                                     |                           |
 |[OPTIONAL request of CA certificates]|                           |
 |------- CA Certs Request (1) -------&gt;|                           |
 |                                     | [OPTIONAL forwarding]     |
 |                                     |--- CA Certs Request -----&gt;|
 |                                     |&lt;-- CA Certs Response -----|
 |&lt;------ CA Certs Response (2) -------|                           |
 |                                     |                           |
 |[OPTIONAL request of attributes      |                           |
 | to include in Certification Request]|                           |
 |------- Attribute Request (3) ------&gt;|                           |
 |                                     | [OPTIONAL forwarding]     |
 |                                     |--- Attribute Request ----&gt;|
 |                                     |&lt;-- Attribute Response ----|
 |&lt;------ Attribute Response (4) ------|                           |
 |                                     |                           |
 |[REQUIRED certification request]     |                           |
 |------- Certification Request (5) --&gt;|                           |
 |                                     | [OPTIONAL forwarding]     |
 |                                     |---Certification Request--&gt;|
 |                                     |&lt;--Certification Resp.  ---|
 |&lt;----- Certification Response (6) ---|                           |
 |                                     |                           |
 |[OPTIONAL certificate confirmation]  |                           |
 |------- Certificate Confirm (7) ----&gt;|                           |
 |                                     | [OPTIONAL forwarding]     |
 |                                     |--- Certificate Confirm---&gt;|
 |                                     |&lt;-- PKI Confirm -----------|
 |&lt;------ PKI/Registrar Confirm (8) ---|                           |
</artwork>
            </artset>
          </figure>
          <t indent="0" pn="section-4.2.4-6">It may be noted that connections between the registrar and the
          PKI components of the operator (RA, CA, etc.) may be intermittent or
          offline.  Messages should be sent as soon as sufficient transfer
          capacity is available.</t>
          <t indent="0" pn="section-4.2.4-7">The label '<tt>[OPTIONAL forwarding]</tt>' in <xref target="enrollfigure" format="default" sectionFormat="of" derivedContent="Figure 2"/> means that on receiving a request message of
          the given type from a pledge, the registrar <bcp14>MAY</bcp14>
          answer the request directly.  In this case, it <bcp14>MUST</bcp14>
          authenticate its responses with the same credentials as used for
          authenticating itself at the TLS level for the voucher exchange.
          Otherwise, the registrar <bcp14>MUST</bcp14> forward the request to
          the RA and forward any resulting response back to the pledge.</t>
          <t indent="0" pn="section-4.2.4-8">The decision of whether to forward a request or to answer it
	  directly can depend on various static and dynamic factors. They
	  include the application scenario, the capabilities of the registrar,
	  the capabilities of the local RA possibly co-located with the
	  registrar, the enrollment protocol being used, and the specific
	  contents of the request.</t>
          <t indent="0" pn="section-4.2.4-9">Note that there are several options for how the registrar could be able to
	  directly answer requests for CA certificates or for certification request
	  attributes.  It could cache responses obtained from the domain PKI and later
	  use their contents for responding to requests asking for the same data.  The
	  contents could also be explicitly provisioned at the registrar.</t>
          <t indent="0" pn="section-4.2.4-10">Further note that certification requests typically need to be
	  handled by the backend PKI, but the registrar can answer them
	  directly with an error response in case it determines that such a
	  request should be rejected, for instance, because it is not properly
	  authenticated or authorized.  Also, certificate confirmation
	  messages will usually be forwarded to the backend PKI, but if the
	  registrar knows that they are not needed or wanted there, it can
	  acknowledge such messages directly.</t>
          <t indent="0" pn="section-4.2.4-11">The following list provides an abstract description of the flow
	  depicted in <xref target="enrollfigure" format="default" sectionFormat="of" derivedContent="Figure 2"/>.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.4-12">
            <li pn="section-4.2.4-12.1">
              <t indent="0" pn="section-4.2.4-12.1.1">CA Certs Request (1): The pledge optionally requests the latest relevant
	      CA certificates. This ensures that the pledge has the
	      complete set of current CA certificates beyond the
	      pinned-domain-cert (which is contained in the voucher
	      and which may be just the domain registrar certificate).</t>
            </li>
            <li pn="section-4.2.4-12.2">
              <t indent="0" pn="section-4.2.4-12.2.1">CA Certs Response (2): This <bcp14>MUST</bcp14> contain any intermediate CA certificates
	      that the pledge may need to validate certificates
	      and <bcp14>MAY</bcp14> contain the LDevID trust anchor.</t>
            </li>
            <li pn="section-4.2.4-12.3">
              <t indent="0" pn="section-4.2.4-12.3.1">Attribute Request (3): Typically, the automated bootstrapping
              occurs without local administrative configuration of the pledge.
              Nevertheless, there are cases in which the pledge may also
              include additional attributes
              that are specific to the target domain in the Certification Request (5). To get these attributes
              in advance, the attribute request may be used.</t>
            </li>
            <li pn="section-4.2.4-12.4">
              <t indent="0" pn="section-4.2.4-12.4.1">Attribute Response (4): This <bcp14>MUST</bcp14> contain the
              attributes requested in (3) to be included in the subsequent
              Certification Request (5).</t>
              <t indent="0" pn="section-4.2.4-12.4.2">For example, <xref section="6.11.7.2" sectionFormat="comma" target="RFC8994" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8994#section-6.11.7.2" derivedContent="RFC8994"/> specifies how the attribute request is used
              to signal to the pledge the '<tt>acp-node-name</tt>' field required for
              enrollment into an Autonomic Control Plane (ACP) domain.</t>
            </li>
            <li pn="section-4.2.4-12.5">
              <t indent="0" pn="section-4.2.4-12.5.1">Certification Request (5): This <bcp14>MUST</bcp14> contain
              the authenticated self-contained object ensuring both the proof
              of possession of the corresponding private key and the proof of
              identity of the requester.</t>
            </li>
            <li pn="section-4.2.4-12.6">
              <t indent="0" pn="section-4.2.4-12.6.1">Certification Response (6): On success, this <bcp14>MUST</bcp14> contain
              the requested certificate and <bcp14>MAY</bcp14>
              include further information, like certificates of intermediate
              CAs and any additional trust anchors.</t>
            </li>
            <li pn="section-4.2.4-12.7">
              <t indent="0" pn="section-4.2.4-12.7.1">Certificate Confirm (7): This is an optional confirmation that is sent after
              the requested certificate has been received and validated.  If
              sent, it <bcp14>MUST</bcp14> contain a positive or negative
              confirmation by the pledge to the PKI whether the certificate
              was successfully enrolled and fits its needs.</t>
            </li>
            <li pn="section-4.2.4-12.8">
              <t indent="0" pn="section-4.2.4-12.8.1">PKI/Registrar Confirm (8): This is an acknowledgment by the PKI that
              <bcp14>MUST</bcp14> be sent on reception of the Certificate
              Confirm.</t>
            </li>
          </ul>
          <t indent="0" pn="section-4.2.4-13">The generic messages described above may be implemented using any
          certificate enrollment protocol that supports authenticated
          self-contained objects for the certification request as described in
          <xref target="req-sol" format="default" sectionFormat="of" derivedContent="Section 3"/>.  Examples are available in <xref target="exist_prot" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
          <aside pn="section-4.2.4-14">
            <t indent="0" pn="section-4.2.4-14.1">Note that the optional certificate confirmation by the pledge
	    to the PKI described above is independent of the mandatory
	    enrollment status telemetry done between the pledge and the
	    registrar in the final phase of BRSKI-AE, which is described
	    next.</t>
          </aside>
        </section>
        <section anchor="pledge-registrar-enrollment-status-telemetry" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.5">
          <name slugifiedName="name-pledge-registrar-enrollment">Pledge - Registrar Enrollment Status Telemetry</name>
          <t indent="0" pn="section-4.2.5-1">The enrollment status telemetry is performed as specified in
          <xref section="5.9.4" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5.9.4" derivedContent="RFC8995"/>.</t>
          <t indent="0" pn="section-4.2.5-2">In <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/>, this is described as part of the certificate enrollment
          step, but due to the generalization of the enrollment protocol
          described in this document, it is regarded as a separate phase
          here.</t>
        </section>
      </section>
      <section anchor="addressing" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-enhancements-to-the-endpoin">Enhancements to the Endpoint Addressing Scheme of BRSKI</name>
        <t indent="0" pn="section-4.3-1">BRSKI-AE extends the addressing scheme outlined in <xref section="5" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5" derivedContent="RFC8995"/> to support
        alternative enrollment protocols that utilize authenticated,
        self-contained objects for certification requests (also see <xref target="exist_prot" format="default" sectionFormat="of" derivedContent="Section 5"/>).  These extensions are designed to be
        compatible with existing Registration Authorities (RAs) and
        Certification Authorities (CAs) that already support such enrollment
        protocols, enabling their use without requiring any modifications.</t>
        <t indent="0" pn="section-4.3-2">The addressing scheme in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> for certification requests,
        related CA certificates, and CSR attributes retrieval functions uses the
        definition from EST <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>.  An example of
        simple enrollment is: <tt>"/.well-known/est/simpleenroll"</tt>.  This
        approach is generalized to the following notation:
        <tt>"/.well-known/&lt;enrollment-protocol&gt;/&lt;request&gt;"</tt> in
        which "<tt>&lt;enrollment-protocol&gt;</tt>" refers to a certificate
        enrollment protocol.  Note that here, enrollment is considered a
        message sequence that contains at least a certification request and a
        certification response.  The following conventions are used to provide
        maximal compatibility with BRSKI:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-3">
          <li pn="section-4.3-3.1">
            <t indent="0" pn="section-4.3-3.1.1">"<tt>&lt;enrollment-protocol&gt;</tt>": This <bcp14>MUST</bcp14>
            reference the protocol being used.  Existing values include
            '<tt>est</tt>' <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> as in <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC8995"/> and
            '<tt>cmp</tt>' as in <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/> and <xref target="brski-cmp-instance" format="default" sectionFormat="of" derivedContent="Section 5.1"/> below.  Values for other existing
            protocols such as CMC and SCEP, as well as newly defined
            protocols, are outside the scope of this document.  For use of the
            "<tt>&lt;enrollment-protocol&gt;</tt>" and "<tt>&lt;request&gt;</tt>"
            URI components, they would need to be specified in a suitable RFC
            and placed into the "Well-Known URIs" registry, just as EST in <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>.</t>
          </li>
          <li pn="section-4.3-3.2">
            <t indent="0" pn="section-4.3-3.2.1">"<tt>&lt;request&gt;</tt>":  If present, this path component
            <bcp14>MUST</bcp14> describe the operation requested depending on
            the enrollment protocol being used.  Enrollment protocols are
            expected to define their request endpoints, as is done by existing
            protocols (also see <xref target="exist_prot" format="default" sectionFormat="of" derivedContent="Section 5"/>).</t>
          </li>
        </ul>
        <t indent="0" pn="section-4.3-4">Well-known URIs for various endpoints on the domain registrar are
	already defined as part of the base BRSKI specification or indirectly
	by EST.  In addition, alternative enrollment endpoints
	<bcp14>MAY</bcp14> be supported by the registrar.</t>
        <t indent="0" pn="section-4.3-5">A pledge <bcp14>SHOULD</bcp14> use the endpoints defined for the
        enrollment protocol(s) that it can use.  It will recognize whether the
        protocol it uses and the specific request it wants to perform are
        understood and supported by the domain registrar. This is done by
        sending the request to the respective endpoint according to the above
        addressing scheme and then evaluating the HTTP status code of the
        response.  If the pledge uses endpoints that are not standardized, it
        risks that the registrar does not recognize a request and thus may
        reject it even if the registrar supports the intended protocol and
        operation.</t>
        <t indent="0" pn="section-4.3-6">The following list of endpoints provides an illustrative example of
        a domain registrar supporting several options for EST as well as for
        CMP to be used in BRSKI-AE. The listing contains the supported
        endpoints to which the pledge may connect for bootstrapping. This
        includes the voucher handling as well as the enrollment endpoints.
        The CMP-related enrollment endpoints are defined as well-known URIs in
        CMP Updates <xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480"/> and the Lightweight CMP Profile
        <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/>.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-7">
          <li pn="section-4.3-7.1">/.well-known/brski/voucherrequest</li>
          <li pn="section-4.3-7.2">/.well-known/brski/voucher_status</li>
          <li pn="section-4.3-7.3">/.well-known/brski/enrollstatus</li>
          <li pn="section-4.3-7.4">/.well-known/est/cacerts</li>
          <li pn="section-4.3-7.5">/.well-known/est/csrattrs</li>
          <li pn="section-4.3-7.6">/.well-known/est/fullcmc</li>
          <li pn="section-4.3-7.7">/.well-known/cmp/getcacerts</li>
          <li pn="section-4.3-7.8">/.well-known/cmp/getcertreqtemplate</li>
          <li pn="section-4.3-7.9">/.well-known/cmp/initialization</li>
          <li pn="section-4.3-7.10">/.well-known/cmp/pkcs10</li>
        </ul>
      </section>
    </section>
    <section anchor="exist_prot" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-instantiation-with-existing">Instantiation with Existing Enrollment Protocols</name>
      <t indent="0" pn="section-5-1">This section maps the generic requirements to support proof of
      possession and proof of identity to selected existing certificate
      enrollment protocols and specifies further aspects of using such
      enrollment protocols in BRSKI-AE.</t>
      <section anchor="brski-cmp-instance" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-brski-cmp-brski-ae-instanti">BRSKI-CMP: BRSKI-AE Instantiated with CMP</name>
        <t indent="0" pn="section-5.1-1">In this document, references to CMP follow the Lightweight CMP
        Profile (LCMPP) from <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/> rather than <xref target="RFC4210" format="default" sectionFormat="of" derivedContent="RFC4210"/> and <xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480"/>, as the subset of CMP
        defined in the LCMPP sufficiently meets the required functionality.</t>
        <t indent="0" pn="section-5.1-2">Adherence to the LCMPP <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/> is
        <bcp14>REQUIRED</bcp14> when using CMP.  The following specific
        requirements apply (refer to <xref target="enrollfigure" format="default" sectionFormat="of" derivedContent="Figure 2"/>):</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-3">
          <li pn="section-5.1-3.1">
            <t indent="0" pn="section-5.1-3.1.1">The validation of server response messages performed by the CMP
            client within the pledge <bcp14>MUST</bcp14> be based on the trust
            anchor established beforehand via the BRSKI voucher, i.e., on the
            pinned-domain-cert.</t>
            <t indent="0" pn="section-5.1-3.1.2">Note that the integrity and authenticity checks on the RA/CA by
            the CMP client can be stronger than for EST because they do not
            need to be performed hop-by-hop but are usually end-to-end.</t>
          </li>
          <li pn="section-5.1-3.2">
            <t indent="0" pn="section-5.1-3.2.1">CA Certs Request (1) and Response (2): Requesting CA
            certificates is <bcp14>OPTIONAL</bcp14>. If supported, it
            <bcp14>SHALL</bcp14> be implemented as specified in <xref section="4.3.1" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-4.3.1" derivedContent="RFC9483"/>.</t>
          </li>
          <li pn="section-5.1-3.3">
            <t indent="0" pn="section-5.1-3.3.1">Attribute Request (3) and Response (4): Requesting
            certification request attributes is <bcp14>OPTIONAL</bcp14>.  If
            supported, it <bcp14>SHALL</bcp14> be implemented as specified in
            <xref section="4.3.3" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-4.3.3" derivedContent="RFC9483"/>.</t>
            <t indent="0" pn="section-5.1-3.3.2">Alternatively, the registrar <bcp14>MAY</bcp14> modify the
            requested certificate contents as specified in <xref section="5.2.3.2" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-5.2.3.2" derivedContent="RFC9483"/>.</t>
          </li>
          <li pn="section-5.1-3.4">
            <t indent="0" pn="section-5.1-3.4.1">Certification Request (5) and Response (6): Certificates
            <bcp14>SHALL</bcp14> be requested and provided as specified in the
            LCMPP from <xref section="4.1.1" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-4.1.1" derivedContent="RFC9483"/> (based on CRMF) or <xref section="4.1.4" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-4.1.4" derivedContent="RFC9483"/> (based on PKCS #10).
            </t>
            <t indent="0" pn="section-5.1-3.4.2">
	      Proof of possession <bcp14>SHALL</bcp14> be provided in a manner
	      suitable for the key type.  Proof of identity
	      <bcp14>SHALL</bcp14> be provided by signature-based protection
	      of the certification request message as outlined in <xref section="3.2" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-3.2" derivedContent="RFC9483"/> using
	      the IDevID secret.</t>
            <t indent="0" pn="section-5.1-3.4.3">
	      When the registrar forwards a certification request from the
	      pledge to a backend RA/CA, it is <bcp14>RECOMMENDED</bcp14> that
	      the registrar wraps the original certification request in a
	      nested message signed with its own credentials, as described in
	      <xref section="5.2.2.1" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-5.2.2.1" derivedContent="RFC9483"/>.  This approach explicitly conveys the
	      registrar's consent to the RA while retaining the original
	      certification request with the proof of origin provided by the
	      pledge's signature. </t>
            <t indent="0" pn="section-5.1-3.4.4">
	      If additional trust anchors beyond the pinned-domain-cert need
	      to be conveyed to the pledge, this <bcp14>SHOULD</bcp14> be done
	      in the '<tt>caPubs</tt>' field of the certification response
	      rather than through a CA Certs Response.</t>
          </li>
          <li pn="section-5.1-3.5">
            <t indent="0" pn="section-5.1-3.5.1">Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit
            confirmation of new certificates to the RA/CA <bcp14>MAY</bcp14>
            be used as specified in <xref section="4.1.1" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-4.1.1" derivedContent="RFC9483"/>.</t>
          </li>
        </ul>
        <aside pn="section-5.1-4">
          <t indent="0" pn="section-5.1-4.1">Note that independent of the certificate confirmation within CMP,
	  enrollment status telemetry with the registrar at the BRSKI level
	  will be performed as described in <xref section="5.9.4" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5.9.4" derivedContent="RFC8995"/>.</t>
        </aside>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-5">
          <li pn="section-5.1-5.1">
            <t indent="0" pn="section-5.1-5.1.1">If delayed delivery of CMP messages is needed (e.g., to support
            enrollment over an asynchronous channel), it <bcp14>SHALL</bcp14>
            be performed as specified in Sections <xref target="RFC9483" section="4.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-4.4" derivedContent="RFC9483"/> and <xref target="RFC9483" section="5.1.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-5.1.2" derivedContent="RFC9483"/> of <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/>.</t>
          </li>
        </ul>
        <t indent="0" pn="section-5.1-6">The mechanisms for exchanging messages between the registrar and
        backend PKI components (i.e., RA and/or CA) are outside the scope of
        this document.  CMP's independence from the message transfer mechanism
        allows for flexibility in choosing the appropriate exchange method
        based on the application scenario.  For the applicable security and
        privacy considerations, refer to Sections <xref target="sec-consider" format="counter" sectionFormat="of" derivedContent="7"/> and
        <xref target="priv-consider" format="counter" sectionFormat="of" derivedContent="8"/>.  Further guidance can be found in
        <xref section="6" sectionFormat="comma" target="RFC9483" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9483#section-6" derivedContent="RFC9483"/>.</t>
        <t indent="0" pn="section-5.1-7">BRSKI-AE with CMP can also be combined with Constrained BRSKI <xref target="I-D.ietf-anima-constrained-voucher" format="default" sectionFormat="of" derivedContent="cBRSKI"/>, using CoAP for
	enrollment message transport as described by CoAP Transfer for CMP <xref target="RFC9482" format="default" sectionFormat="of" derivedContent="RFC9482"/>.  In such scenarios, the EST-specific parts
	of <xref target="I-D.ietf-anima-constrained-voucher" format="default" sectionFormat="of" derivedContent="cBRSKI"/> do not
	apply.</t>
        <t indent="0" pn="section-5.1-8">For BRSKI-AE scenarios where a general solution for discovering
        registrars with CMP support is not available (cf. <xref target="discovery" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>), the following minimalist approach
        <bcp14>MAY</bcp14> be used: Perform discovery as defined in <xref target="RFC8995" sectionFormat="comma" section="B" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#appendix-B" derivedContent="RFC8995"/>, but use the service
        name <tt>"brski-reg-cmp"</tt> (as defined in <xref target="iana-consider" format="default" sectionFormat="of" derivedContent="Section 6"/>) instead of <tt>"brski-registrar"</tt> (as
        defined in <xref section="8.6" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-8.6" derivedContent="RFC8995"/>).  Note that this approach does not support join
        proxies.</t>
      </section>
      <section anchor="support-of-other-enrollment-protocols" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-support-of-other-enrollment">Support of Other Enrollment Protocols</name>
        <t indent="0" pn="section-5.2-1">Further instantiations of BRSKI-AE can be done.  They are left for
        future work.</t>
        <t indent="0" pn="section-5.2-2">In particular, CMC <xref target="RFC5272" format="default" sectionFormat="of" derivedContent="RFC5272"/> (using its in-band
        source authentication options) and SCEP <xref target="RFC8894" format="default" sectionFormat="of" derivedContent="RFC8894"/>
        (using its 'renewal' option) could be used.</t>
        <t indent="0" pn="section-5.2-3">The fullCMC variant of EST sketched in <xref section="2.5" sectionFormat="comma" target="RFC7030" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-2.5" derivedContent="RFC7030"/> might also be used here. For
        EST-fullCMC, further specification is necessary.
        </t>
      </section>
    </section>
    <section anchor="iana-consider" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">IANA has registered the following service name in the <eref target="https://www.iana.org/assignments/service-names-port-numbers" brackets="angle">"Service
      Name and Transport Protocol Port Number Registry"</eref>.</t>
      <dl spacing="compact" newline="false" indent="3" pn="section-6-2">
        <dt pn="section-6-2.1">Service Name:</dt>
        <dd pn="section-6-2.2">brski-reg-cmp</dd>
        <dt pn="section-6-2.3">Transport Protocol(s):</dt>
        <dd pn="section-6-2.4">tcp</dd>
        <dt pn="section-6-2.5">Description:</dt>
        <dd pn="section-6-2.6">Bootstrapping Remote Secure Key
        Infrastructure registrar with CMP capabilities according to the
        Lightweight CMP Profile (LCMPP) <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/></dd>
        <dt pn="section-6-2.7">Assignee:</dt>
        <dd pn="section-6-2.8">IESG &lt;iesg@ietf.org&gt;</dd>
        <dt pn="section-6-2.9">Contact:</dt>
        <dd pn="section-6-2.10">IETF &lt;chair@ietf.org&gt;</dd>
        <dt pn="section-6-2.11">Reference:</dt>
        <dd pn="section-6-2.12">RFC 9733</dd>
      </dl>
      <aside pn="section-6-3">
        <t indent="0" pn="section-6-3.1">Note: We chose the suffix "cmp" here rather than some other
	abbreviation like "lcmpp" mainly because this document defines the
	normative CMP instantiation of BRSKI-AE, which implies adherence to
	the LCMPP is necessary and sufficient.</t>
      </aside>
    </section>
    <section anchor="sec-consider" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">The security considerations laid out in <xref section="11" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-11" derivedContent="RFC8995"/> apply to the discovery and
      voucher exchange as well as for the status exchange information.</t>
      <t indent="0" pn="section-7-2">In particular, even if the registrar delegates part or all of its RA
      role during certificate enrollment to a separate system, it still must
      be made sure that the registrar takes part in the decision on accepting
      or declining a request to join the domain, as required in <xref section="5.3" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5.3" derivedContent="RFC8995"/>.  As this also
      pertains to obtaining a valid domain-specific certificate, it must
      be made sure that a pledge cannot circumvent the registrar in the
      decision of whether it is granted an LDevID certificate by the CA.
      There are various ways to fulfill this, including:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-3">
        <li pn="section-7-3.1">
          <t indent="0" pn="section-7-3.1.1">implicit consent;</t>
        </li>
        <li pn="section-7-3.2">
          <t indent="0" pn="section-7-3.2.1">the registrar signaling its consent to the RA out-of-band before or
          during the enrollment phase, for instance, by entering the pledge
          identity in a database;</t>
        </li>
        <li pn="section-7-3.3">
          <t indent="0" pn="section-7-3.3.1">the registrar providing its consent using an extra message that is
          transferred on the same channel as the enrollment messages, possibly
          in a TLS tunnel; and</t>
        </li>
        <li pn="section-7-3.4">
          <t indent="0" pn="section-7-3.4.1">the registrar explicitly stating its consent by signing the
          authenticated self-contained certificate enrollment request message
          in addition to the pledge.</t>
        </li>
      </ul>
      <aside pn="section-7-4">
        <t indent="0" pn="section-7-4.1">Note: If EST was used, the registrar could give implicit consent on
	a certification request by forwarding the request to a PKI entity
	using a connection authenticated with a certificate containing an
	id-kp-cmcRA extension.</t>
      </aside>
      <t indent="0" pn="section-7-5">When CMP is used, the security considerations laid out in the LCMPP from <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/> apply.</t>
    </section>
    <section anchor="priv-consider" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-8-1">The privacy considerations laid out in <xref section="10" sectionFormat="comma" target="RFC8995" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-10" derivedContent="RFC8995"/> apply as well.</t>
      <t indent="0" pn="section-8-2">Note that CMP messages themselves are not encrypted.  This may give
      eavesdroppers insight into which devices are bootstrapped into the
      domain.  In turn, this might also be used to selectively block the
      enrollment of certain devices.</t>
      <t indent="0" pn="section-8-3">To prevent such issues, the underlying message transport channel can
      be encrypted.  This is already provided by TLS between the pledge and
      the registrar, and for the onward exchange with backend systems,
      encryption may need to be added.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-anima-brski-discovery" to="BRSKI-discovery"/>
    <displayreference target="I-D.ietf-anima-constrained-voucher" to="cBRSKI"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="IEEE_802.1AR-2018" target="https://ieeexplore.ieee.org/document/8423794" quoteTitle="true" derivedAnchor="IEEE_802.1AR-2018">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date year="2018" month="August"/>
          </front>
          <seriesInfo name="IEEE" value="802.1AR-2018"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8995" quoteTitle="true" derivedAnchor="RFC8995">
          <front>
            <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="T. Eckert" initials="T." surname="Eckert"/>
            <author fullname="M. Behringer" initials="M." surname="Behringer"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8995"/>
          <seriesInfo name="DOI" value="10.17487/RFC8995"/>
        </reference>
        <reference anchor="RFC9483" target="https://www.rfc-editor.org/info/rfc9483" quoteTitle="true" derivedAnchor="RFC9483">
          <front>
            <title>Lightweight Certificate Management Protocol (CMP) Profile</title>
            <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
            <author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/>
            <author fullname="S. Fries" initials="S." surname="Fries"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9483"/>
          <seriesInfo name="DOI" value="10.17487/RFC9483"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="BRSKI-AE-overview" target="https://datatracker.ietf.org/meeting/116/materials/slides-116-anima-update-on-brski-ae-alternative-enrollment-protocols-in-brski-00" quoteTitle="true" derivedAnchor="BRSKI-AE-overview">
          <front>
            <title>Update on BRSKI-AE: Alternative Enrollment Protocols in BRSKI</title>
            <author initials="D." surname="von Oheimb" fullname="David von Oheimb" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Fries" fullname="Steffen Fries">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023" month="March"/>
          </front>
          <refcontent>IETF 116 - ANIMA Working Group Presentation</refcontent>
        </reference>
        <reference anchor="I-D.ietf-anima-brski-discovery" target="https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-discovery-05" quoteTitle="true" derivedAnchor="BRSKI-discovery">
          <front>
            <title>BRSKI discovery and variations</title>
            <author initials="T." surname="Eckert" fullname="Toerless Eckert" role="editor">
              <organization showOnFrontPage="true">Futurewei USA</organization>
            </author>
            <author initials="E." surname="Dijk" fullname="Esko Dijk">
              <organization showOnFrontPage="true">IoTconsultancy.nl</organization>
            </author>
            <date month="October" day="21" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-discovery-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-anima-constrained-voucher" target="https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-27" quoteTitle="true" derivedAnchor="cBRSKI">
          <front>
            <title>Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)</title>
            <author initials="M." surname="Richardson" fullname="Michael Richardson">
              <organization showOnFrontPage="true">Sandelman Software Works</organization>
            </author>
            <author initials="P." surname="Van der Stok" fullname="Peter Van der Stok">
              <organization showOnFrontPage="true">vanderstok consultancy</organization>
            </author>
            <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="E." surname="Dijk" fullname="Esko Dijk">
              <organization showOnFrontPage="true">IoTconsultancy.nl</organization>
            </author>
            <date month="March" day="3" year="2025"/>
            <abstract>
              <t indent="0">   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (cBRSKI) protocol, which provides a solution for
   secure zero-touch onboarding of resource-constrained (IoT) devices
   into the network of a domain owner.  This protocol is designed for
   constrained networks, which may have limited data throughput or may
   experience frequent packet loss. cBRSKI is a variant of the BRSKI
   protocol, which uses an artifact signed by the device manufacturer
   called the "voucher" which enables a new device and the owner's
   network to mutually authenticate.  While the BRSKI voucher data is
   encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
   BRSKI voucher data definition is extended with new data types that
   allow for smaller voucher sizes.  The Enrollment over Secure
   Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
   CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
   (CoAPS).  This document Updates RFC 8995 and RFC 9148.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-27"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="IEC-62351-9" target="https://webstore.iec.ch/en/publication/66864" quoteTitle="true" derivedAnchor="IEC-62351-9">
          <front>
            <title>Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment</title>
            <author>
              <organization showOnFrontPage="true">International Electrotechnical Commission</organization>
            </author>
            <date year="2023" month="June"/>
          </front>
          <seriesInfo name="IEC" value="62351-9:2023"/>
        </reference>
        <reference anchor="ISO-IEC-15118-2" target="https://www.iso.org/standard/55366.html" quoteTitle="true" derivedAnchor="ISO-IEC-15118-2">
          <front>
            <title>Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network and application protocol requirements</title>
            <author>
              <organization showOnFrontPage="true">International Organization for Standardization</organization>
            </author>
            <date year="2014" month="April"/>
          </front>
          <seriesInfo name="ISO" value="15118-2:2014"/>
        </reference>
        <reference anchor="NERC-CIP-005-5" target="" quoteTitle="true" derivedAnchor="NERC-CIP-005-5">
          <front>
            <title>Cyber Security - Electronic Security Perimeter</title>
            <author>
              <organization showOnFrontPage="true">North American Electric Reliability Council</organization>
            </author>
            <date year="2013" month="December"/>
          </front>
          <seriesInfo name="CIP" value="005-5"/>
        </reference>
        <reference anchor="OCPP" quoteTitle="true" derivedAnchor="OCPP">
          <front>
            <title>Open Charge Point Protocol 2.0.1 (Draft)</title>
            <author>
              <organization showOnFrontPage="true">Open Charge Alliance</organization>
            </author>
            <date year="2019" month="December"/>
          </front>
        </reference>
        <reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2986" quoteTitle="true" derivedAnchor="RFC2986">
          <front>
            <title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
            <author fullname="M. Nystrom" initials="M." surname="Nystrom"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <date month="November" year="2000"/>
            <abstract>
              <t indent="0">This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2986"/>
          <seriesInfo name="DOI" value="10.17487/RFC2986"/>
        </reference>
        <reference anchor="RFC4210" target="https://www.rfc-editor.org/info/rfc4210" quoteTitle="true" derivedAnchor="RFC4210">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)</title>
            <author fullname="C. Adams" initials="C." surname="Adams"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="T. Kause" initials="T." surname="Kause"/>
            <author fullname="T. Mononen" initials="T." surname="Mononen"/>
            <date month="September" year="2005"/>
            <abstract>
              <t indent="0">This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4210"/>
          <seriesInfo name="DOI" value="10.17487/RFC4210"/>
        </reference>
        <reference anchor="RFC4211" target="https://www.rfc-editor.org/info/rfc4211" quoteTitle="true" derivedAnchor="RFC4211">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="September" year="2005"/>
            <abstract>
              <t indent="0">This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4211"/>
          <seriesInfo name="DOI" value="10.17487/RFC4211"/>
        </reference>
        <reference anchor="RFC5272" target="https://www.rfc-editor.org/info/rfc5272" quoteTitle="true" derivedAnchor="RFC5272">
          <front>
            <title>Certificate Management over CMS (CMC)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="M. Myers" initials="M." surname="Myers"/>
            <date month="June" year="2008"/>
            <abstract>
              <t indent="0">This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</t>
              <t indent="0">1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t>
              <t indent="0">2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</t>
              <t indent="0">CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5272"/>
          <seriesInfo name="DOI" value="10.17487/RFC5272"/>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC5929" target="https://www.rfc-editor.org/info/rfc5929" quoteTitle="true" derivedAnchor="RFC5929">
          <front>
            <title>Channel Bindings for TLS</title>
            <author fullname="J. Altman" initials="J." surname="Altman"/>
            <author fullname="N. Williams" initials="N." surname="Williams"/>
            <author fullname="L. Zhu" initials="L." surname="Zhu"/>
            <date month="July" year="2010"/>
            <abstract>
              <t indent="0">This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).</t>
              <t indent="0">Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5929"/>
          <seriesInfo name="DOI" value="10.17487/RFC5929"/>
        </reference>
        <reference anchor="RFC6955" target="https://www.rfc-editor.org/info/rfc6955" quoteTitle="true" derivedAnchor="RFC6955">
          <front>
            <title>Diffie-Hellman Proof-of-Possession Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="H. Prafullchandra" initials="H." surname="Prafullchandra"/>
            <date month="May" year="2013"/>
            <abstract>
              <t indent="0">This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.</t>
              <t indent="0">This document obsoletes RFC 2875.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6955"/>
          <seriesInfo name="DOI" value="10.17487/RFC6955"/>
        </reference>
        <reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7030" quoteTitle="true" derivedAnchor="RFC7030">
          <front>
            <title>Enrollment over Secure Transport</title>
            <author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin"/>
            <author fullname="P. Yee" initials="P." role="editor" surname="Yee"/>
            <author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/>
            <date month="October" year="2013"/>
            <abstract>
              <t indent="0">This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7030"/>
          <seriesInfo name="DOI" value="10.17487/RFC7030"/>
        </reference>
        <reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8366" quoteTitle="true" derivedAnchor="RFC8366">
          <front>
            <title>A Voucher Artifact for Bootstrapping Protocols</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
            <author fullname="T. Eckert" initials="T." surname="Eckert"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".</t>
              <t indent="0">This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).</t>
              <t indent="0">This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8366"/>
          <seriesInfo name="DOI" value="10.17487/RFC8366"/>
        </reference>
        <reference anchor="RFC8894" target="https://www.rfc-editor.org/info/rfc8894" quoteTitle="true" derivedAnchor="RFC8894">
          <front>
            <title>Simple Certificate Enrolment Protocol</title>
            <author fullname="P. Gutmann" initials="P." surname="Gutmann"/>
            <date month="September" year="2020"/>
            <abstract>
              <t indent="0">This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8894"/>
          <seriesInfo name="DOI" value="10.17487/RFC8894"/>
        </reference>
        <reference anchor="RFC8994" target="https://www.rfc-editor.org/info/rfc8994" quoteTitle="true" derivedAnchor="RFC8994">
          <front>
            <title>An Autonomic Control Plane (ACP)</title>
            <author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/>
            <author fullname="M. Behringer" initials="M." role="editor" surname="Behringer"/>
            <author fullname="S. Bjarnason" initials="S." surname="Bjarnason"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8994"/>
          <seriesInfo name="DOI" value="10.17487/RFC8994"/>
        </reference>
        <reference anchor="RFC9148" target="https://www.rfc-editor.org/info/rfc9148" quoteTitle="true" derivedAnchor="RFC9148">
          <front>
            <title>EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol</title>
            <author fullname="P. van der Stok" initials="P." surname="van der Stok"/>
            <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="S. Raza" initials="S." surname="Raza"/>
            <date month="April" year="2022"/>
            <abstract>
              <t indent="0">Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9148"/>
          <seriesInfo name="DOI" value="10.17487/RFC9148"/>
        </reference>
        <reference anchor="RFC9480" target="https://www.rfc-editor.org/info/rfc9480" quoteTitle="true" derivedAnchor="RFC9480">
          <front>
            <title>Certificate Management Protocol (CMP) Updates</title>
            <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
            <author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/>
            <author fullname="J. Gray" initials="J." surname="Gray"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document contains a set of updates to the syntax of Certificate Management Protocol (CMP) version 2 and its HTTP transfer mechanism. This document updates RFCs 4210, 5912, and 6712.</t>
              <t indent="0">The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments.</t>
              <t indent="0">CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signal the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9480"/>
          <seriesInfo name="DOI" value="10.17487/RFC9480"/>
        </reference>
        <reference anchor="RFC9482" target="https://www.rfc-editor.org/info/rfc9482" quoteTitle="true" derivedAnchor="RFC9482">
          <front>
            <title>Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol</title>
            <author fullname="M. Sahni" initials="M." role="editor" surname="Sahni"/>
            <author fullname="S. Tripathi" initials="S." role="editor" surname="Tripathi"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document specifies the use of the Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9482"/>
          <seriesInfo name="DOI" value="10.17487/RFC9482"/>
        </reference>
        <reference anchor="UNISIG-Subset-137" target="https://www.era.europa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf" quoteTitle="true" derivedAnchor="UNISIG-Subset-137">
          <front>
            <title>ERTMS/ETCS On-line Key Management FFFIS</title>
            <author>
              <organization showOnFrontPage="true">UNISIG</organization>
            </author>
            <date year="2015" month="December"/>
          </front>
          <refcontent>Subset-137, Version 1.0.0</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="app-examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-application-examples">Application Examples</name>
      <t indent="0" pn="section-appendix.a-1">This informative annex provides some details about application examples.</t>
      <section anchor="rolling-stock" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-rolling-stock">Rolling Stock</name>
        <t indent="0" pn="section-appendix.a.1-1">Rolling stock or railroad cars contain a variety of sensors,
        actuators, and controllers. These communicate within the railroad car
        but also exchange information with other railroad cars of the same train and
        with track-side equipment and/or possibly with backend systems.
        These devices are typically unaware of backend system connectivity.
        Enrolling certificates may be done during maintenance cycles of the
        railroad car but can already be prepared during operation.  Such
        asynchronous enrollment will include generating certification
        requests, which are collected and later forwarded for processing
        whenever the railroad car gets connectivity with the backend PKI of
        the operator.  The authorization of the certification request is then
        done based on the operator's asset/inventory information in the
        backend.</t>
        <t indent="0" pn="section-appendix.a.1-2">UNISIG has included a CMP profile for the enrollment of TLS client
        and server X.509 certificates of on-board and track-side
        components in the Subset-137, which specifies the ETRAM/ETCS online
        key management for train control systems <xref target="UNISIG-Subset-137" format="default" sectionFormat="of" derivedContent="UNISIG-Subset-137"/>.</t>
      </section>
      <section anchor="building-automation" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-building-automation">Building Automation</name>
        <t indent="0" pn="section-appendix.a.2-1">In building automation scenarios, a detached building or the
        basement of a building may be equipped with sensors, actuators, and
        controllers that are connected to each other in a local network but
        with only limited or no connectivity to a central building management
        system.  This problem may occur during installation time but also
        during operation.  In such a situation, a service technician collects
        the necessary data and transfers it between the local network and the
        central building management system, e.g., using a laptop or a mobile
        phone.  This data may comprise parameters and settings required in the
        operational phase of the sensors/actuators, like a component
        certificate issued by the operator to authenticate against other
        components and services.</t>
        <t indent="0" pn="section-appendix.a.2-2">The collected data may be provided by a domain registrar already
        existing in the local network. In this case, connectivity to the
        backend PKI may be facilitated by the service technician's laptop.
        Alternatively, the data can also be collected from the pledges
        directly and provided to a domain registrar deployed in a different
        network in preparation for the operational phase.  In this case,
        connectivity to the domain registrar may also be facilitated by the
        service technician's laptop.</t>
      </section>
      <section anchor="substation-automation" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
        <name slugifiedName="name-substation-automation">Substation Automation</name>
        <t indent="0" pn="section-appendix.a.3-1">In electrical substation automation scenarios, a control center
        typically hosts PKI services to issue certificates for Intelligent
        Electronic Devices (IEDs) operated in a substation. Communication
        between the substation and control center is performed through a
        proxy/gateway/DMZ, which terminates protocol flows.  Note that
        <xref target="NERC-CIP-005-5" format="default" sectionFormat="of" derivedContent="NERC-CIP-005-5"/> requires inspection of protocols at
        the boundary of a security perimeter (in this case, the substation).
        In addition, security management in substation automation assumes
        central support of several enrollment protocols to support the various
        capabilities of IEDs from different vendors.  The IEC standard
        IEC62351-9 <xref target="IEC-62351-9" format="default" sectionFormat="of" derivedContent="IEC-62351-9"/> specifies mandatory support of
        two enrollment protocols for the infrastructure side, SCEP <xref target="RFC8894" format="default" sectionFormat="of" derivedContent="RFC8894"/> and EST <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>, while an
        IED may support only one of them.</t>
      </section>
      <section anchor="electric-vehicle-charging-infrastructure" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.4">
        <name slugifiedName="name-electric-vehicle-charging-i">Electric Vehicle Charging Infrastructure</name>
        <t indent="0" pn="section-appendix.a.4-1">For electric vehicle charging infrastructure, protocols have been
        defined for the interaction between the electric vehicle and the
        charging point (e.g., ISO 15118-2 <xref target="ISO-IEC-15118-2" format="default" sectionFormat="of" derivedContent="ISO-IEC-15118-2"/>) as
        well as between the charging point and the charging point operator
        (e.g., OCPP <xref target="OCPP" format="default" sectionFormat="of" derivedContent="OCPP"/>). Depending on the authentication
        model, unilateral or mutual authentication is required. In both cases,
        the charging point uses an X.509 certificate to authenticate itself in
        TLS channels between the electric vehicle and the charging point. The
        management of this certificate depends, among other things, on the selected
        backend connectivity protocol.  In the case of OCPP, this protocol is
        meant to be the only communication protocol between the charging point
        and the backend, carrying all information to control the charging
        operations and maintain the charging point itself. This means that the
        certificate management needs to be handled in-band of OCPP. This
        requires the ability to encapsulate the certificate management
        messages in a transport-independent way.  Authenticated
        self-containment will support this by allowing the transport without a
        separate enrollment protocol, binding the messages to the identity of
        the communicating endpoints.</t>
      </section>
      <section anchor="infrastructure-isolation" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.5">
        <name slugifiedName="name-infrastructure-isolation-po">Infrastructure Isolation Policy</name>
        <t indent="0" pn="section-appendix.a.5-1">The approach described in this section refers to any case in which
        network infrastructure is normally isolated from the Internet as a
        matter of policy, most likely for security reasons. In such a case,
        limited access to external PKI services will be allowed in carefully
        controlled short periods of time (for example, when a batch of new
        devices is deployed) and forbidden or prevented at other times.</t>
      </section>
      <section anchor="sites-with-insufficient-level-of-operational-security" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.6">
        <name slugifiedName="name-sites-with-insufficient-lev">Sites with Insufficient Levels of Operational Security</name>
        <t indent="0" pn="section-appendix.a.6-1">The RA performing (at least part of) the authorization of a
        certification request is a critical PKI component and therefore
        requires higher operational security than components utilizing the
        issued certificates for their security features. CAs may also demand
        higher security in the registration procedures from RAs, which domain
        registrars with co-located RAs may not be able to fulfill.  In
        particular, the CA/Browser forum currently increases the security
        requirements in the certificate issuance procedures for publicly
        trusted certificates, i.e., those placed in trust stores of browsers,
        which may be used to connect with devices in the domain.  In case the
        on-site components of the target domain cannot be operated securely
        enough for the needs of an RA, this service should be transferred to
        an off-site backend component that has a sufficient level of
        security.</t>
      </section>
    </section>
    <section anchor="acknowledgments" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1">We thank <contact fullname="Eliot Lear"/> for his contributions as a
      co-author at an earlier draft stage.</t>
      <t indent="0" pn="section-appendix.b-2">We thank <contact fullname="Brian E. Carpenter"/>, <contact fullname="Michael Richardson"/>, and <contact fullname="Giorgio       Romanenghi"/> for their input and discussion on use cases and call
      flows.</t>
      <t indent="0" pn="section-appendix.b-3">Moreover, we thank <contact fullname="Toerless Eckert"/> (document
      shepherd); <contact fullname="Barry Leiba"/> (SECdir review); <contact fullname="Mahesh Jethanandani"/> (IETF area director); <contact fullname="Meral Shirazipour"/> (Gen-ART reviewer); <contact fullname="Reshad Rahman"/> (YANGDOCTORS reviewer); <contact fullname="Deb Cooley"/>, <contact fullname="Gunter Van de Velde"/>,
      <contact fullname="John Scudder"/>, <contact fullname="Murray       Kucherawy"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Éric Vyncke"/> (IESG reviewers); <contact fullname="Michael       Richardson"/> (ANIMA design team member); and <contact fullname="Rajeev Ranjan"/>, <contact fullname="Rufus Buschart"/>,
      <contact fullname="Andreas Reiter"/>, and <contact fullname="Szofia       Fazekas-Zisch"/> (Siemens colleagues) for their reviews with suggestions
      for improvements.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact initials="E." surname="Lear" fullname="Eliot Lear">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <street>Richtistrasse 7</street>
            <city>Wallisellen</city>
            <code>8304</code>
            <country>Switzerland</country>
          </postal>
          <phone>+41 44 878 9200</phone>
          <email>lear@cisco.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="D." surname="von Oheimb" fullname="David von Oheimb" role="editor">
        <organization abbrev="Siemens" showOnFrontPage="true">Siemens AG</organization>
        <address>
          <postal>
            <street>Otto-Hahn-Ring 6</street>
            <city>Munich</city>
            <code>81739</code>
            <country>Germany</country>
          </postal>
          <email>david.von.oheimb@siemens.com</email>
          <uri>https://www.siemens.com/</uri>
        </address>
      </author>
      <author initials="S." surname="Fries" fullname="Steffen Fries">
        <organization abbrev="Siemens" showOnFrontPage="true">Siemens AG</organization>
        <address>
          <postal>
            <street>Otto-Hahn-Ring 6</street>
            <city>Munich</city>
            <code>81739</code>
            <country>Germany</country>
          </postal>
          <email>steffen.fries@siemens.com</email>
          <uri>https://www.siemens.com/</uri>
        </address>
      </author>
      <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
        <organization abbrev="Siemens" showOnFrontPage="true">Siemens AG</organization>
        <address>
          <postal>
            <street>Otto-Hahn-Ring 6</street>
            <city>Munich</city>
            <code>81739</code>
            <country>Germany</country>
          </postal>
          <email>hendrik.brockhaus@siemens.com</email>
          <uri>https://www.siemens.com/</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
