<?xmlversion="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 2.6.10) -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?rfc compact="yes"?> <?rfc iprnotified="no"?> <?rfc strict="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-anima-brski-ae-13" number="9733" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true"symRefs="true">symRefs="true" version="3" updates="" obsoletes="" xml:lang="en"> <front><title abbrev="BRSKI-AE">BRSKI-AE:<!--[rfced] Please note that the title of the document has been updated as follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review and confirm that this is how you would like "BRSKI-AE" to be expanded both in the title and throughout the rest of this document. Original: BRSKI-AE: Alternative Enrollment Protocols inBRSKI</title>BRSKI Current: BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative Enrollment --> <title abbrev="BRSKI-AE">BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative Enrollment</title> <seriesInfo name="RFC" value="9733"/> <author initials="D."surname="von Oheimb"surname="von Oheimb" fullname="Davidvon Oheimb"von Oheimb" role="editor"> <organization abbrev="Siemens">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">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">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> <dateyear="2024"/> <area>Operations and Management</area> <workgroup>ANIMA WG</workgroup> <keyword>Internet-Draft</keyword>year="2025" month="February"/> <area>OPS</area> <workgroup>anima</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 148?><t>This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known asBRSKI-AE (Alternative Enrollment).<br />BRSKI with Alternative Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use ofEST.Enrollment over Secure Transport (EST). It supports certificate enrollmentprotocols,protocols such asCMP,the Certificate Management Protocol (CMP) that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboardingscenarios.<br />scenarios. The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollmentprotocols.<br />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><note title="About This Document" removeInRFC="true"> <t> Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/"/>. </t> <t> Discussion of this document takes place on the anima Working Group mailing list (<eref target="mailto:anima@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/anima/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/anima/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/anima-wg/anima-brski-ae"/>.</t> </note></front> <middle><?line 164?><sectionanchor="introduction"><name>Introduction</name> <t>BRSKIanchor="introduction"> <name>Introduction</name> <t>Bootstrapping Remote Secure Key Infrastructure (BRSKI) <xref target="RFC8995"/> is typically used with Enrollment over Secure Transport(EST,(EST) <xreftarget="RFC7030"/>)target="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. <!-- This enhancement of BRSKI is named BRSKI-AE, where AE stands for **A**lternative **E**nrollment. (while originally it was used to abbreviate **A**synchronous **E**nrollment)--></t>--> </t> <t>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 certificationrequests,requests while ensuring that the integrity and authenticity of the enrollment messagesisare maintained with full cryptographic strength.</t> <t>This specification carries over the main characteristics of BRSKI, namely:</t><t><list style="symbols"><ul spacing="normal"> <li> <!-- [rfced] We have updated the text below to improve readability. Please review to ensure these changes do not alter your intended meaning. Original: It uses them to authenticate itself to the Manufacturer Authorized Signing Authority (MASA, [RFC8995]), and to the registrar, which is the access point of the target domain, and to possibly further components of the domain where it will be operated. Current: It uses them to authenticate itself to the Manufacturer Authorized Signing Authority (MASA) [RFC8995] and 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>The pledge is assumed to have received its Initial DeviceIDentifier (IDevID,Identifier (IDevID) <xreftarget="IEEE_802.1AR-2018"/>)target="IEEE_802.1AR-2018"/> credentials during its manufacturing. It uses them to authenticate itself to the Manufacturer Authorized Signing Authority(MASA,(MASA) <xreftarget="RFC8995"/>),target="RFC8995"/> andtotheregistrar, whichregistrar (which is the access point of the targetdomain,domain) and to possibly further components of the domain where it will be operated.</t> </li> <li> <t>The pledge first obtains via the voucher exchange <xref target="RFC8366"/>exchangea trust anchor for authenticating entities in the domain such as the domain registrar.</t> </li> <li> <t>The pledge then obtains itsLocally significantLocal DeviceIDentifier (IDevID,Identifier (LDevID) <xreftarget="IEEE_802.1AR-2018"/>).target="IEEE_802.1AR-2018"/>. To this end, the pledge generates a private key, calledLDevID secret, andan "LDevID secret". Then, it requests via the domain registrar from the PKI of its new domain a domain-specific device certificate, calledLDevID certificate.an "LDevID certificate". On success, it receives the LDevID certificate along with its certificate chain.</t></list></t></li> </ul> <t>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><t><list style="symbols"> <t>Supports<ul spacing="normal"> <li> <t>supports end-to-end authentication over multiple transporthops.</t> <t>Facilitateshops and</t> </li> <li> <t>facilitates secure messageexchangeexchanges over any type of transfer mechanism, including asynchronous delivery.</t></list></t></li> </ul> <!--- not really: and * defining a certificate waiting indication and handling, for the case that the certifying component is (temporarily) not available. --> <t>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>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>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>It may be important to note that BRSKI(RFC 8995)<xref target="RFC8995"/> specifies the use of HTTP over TLS, but variations such as Constrained BRSKI <xreftarget="I-D.ietf-anima-constrained-voucher"/>target="I-D.ietf-anima-constrained-voucher"/>, which usesCoAPthe Constrained Application Protocol (CoAP) over DTLS, are possible as well. In this context,'HTTP'"HTTP" and'TLS'"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>This specification, together with its referenced documents, is sufficient to support BRSKI with the Certificate Management Protocol(CMP,(CMP) <xreftarget="RFC9480"/>)target="RFC9480"/> as profiled in the Lightweight CMP Profile(LCMPP,(LCMPP) <xreftarget="RFC9483"/>).target="RFC9483"/>. Integrating BRSKI with an enrollment protocol or profile other than 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> <sectionanchor="sup-env"><name>Supportedanchor="sup-env"> <name>Supported Scenarios</name> <t>BRSKI-AE is designed for use in scenarios such as the following:</t><t><list style="symbols"> <t>Pledges<ul spacing="normal"> <li> <t>When pledges and/or the target domain leverage an existing certificate enrollment protocol other than EST, such as CMP.</t><t>The</li> <li> <t>When the application context precludes the use of EST for certificate enrollment due to factors suchas: <list style="symbols">as when:</t> <ul spacing="normal"> <li> <t>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> <t>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> <t>Certificates are requested for key types, such as Key Encapsulation Mechanism (KEM) keys, that do not support signing or other single-shot proof-of-possessionmethods,methods as those described in <xref target="RFC6955"/>. EST, which relies on CSRs in PKCS #10 format <xreftarget="RFC2986"/> format,target="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> <t>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"/>, which EST requires for the strong binding of source authentication.</t></list></t> <t>Full</li> </ul> </li> <li> <t>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. <!-- in the latter case a message store-and-forward mechanism is needed.--></t> <t>Authoritative--> </t> </li> <li> <t>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. <!-- Final authorization then is done by a RA residing in the backend.--></t> </list></t>--> </t> </li> </ul> <t>Bootstrapping may be managed in various ways depending on the application domain. <xref target="app-examples"/> provides illustrative examples from different industrial control system environments and operational contexts that motivate the support of alternative enrollment protocols.</t> </section> </section> <sectionanchor="terminology"><name>Terminologyanchor="terminology"> <name>Terminology andabbreviations</name> <t>TheAbbreviations</name> <t> 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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>This document relies on the terminology defined in <xref target="RFC8995"/>, <xref target="RFC5280"/>, and <xref target="IEEE_802.1AR-2018"/>, which is partly repeated here.Also severalSeveral further terms are also described here.</t> <t>To be independent of the terminology of a specific enrollment protocol, this document utilizes generic terminology regarding PKI management operations.</t><dl><!-- [rfced] Please review the following questions and changes regarding the terminology list in Section 2: a.) FYI - We have updated some list items to have a 1:1 relationship between abbreviation and expansion. Please carefully review these changes and let us know of any objections. b.) As this list contains a mixture of definitions and abbreviations, may we separate these items into two separate lists for readability? c.) We note that several abbreviations appear in this document that are not included in the terminology list in Section 2 (see some examples below). Please review and let us know if these or any other terms should be added. (Note that we have already added a list item for Certification Authority (CA) as this abbreviation appears in other definitions in this list.) Key Encapsulation Mechanism (KEM) Certificate Request Message Format (CRMF) Simple Certificate Enrolment Protocol (SCEP) Certificate Management over CMS (CMC) Autonomic Control Plane (ACP) --> <dl newline="false" spacing="normal"> <dt>asynchronous:</dt><dd> <t>time-wise<dd>the time-wise interrupted delivery ofmessages,<br /> heremessages, here, between a pledge and some backend system (e.g., anRA)</t> </dd>RA).</dd> <dt>attribute request:</dt><dd> <t>message<dd>a message requesting content to be included in the certificationrequest</t> </dd>request.</dd> <dt>attribute response:</dt><dd> <t>message<dd>a message providing the answer to the attributerequest</t> </dd>request.</dd> <dt>authenticated self-contained object:</dt><dd> <t>a<dd>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 IDevIDsecret.</t> </dd>secret.</dd> <dt>backend:</dt><dd> <t>placement<dd>the placement of a domain component separately from the domain registrar; it may be on-site oroff-site</t> </dd>off-site.</dd> <dt>BRSKI:</dt><dd> <t>Bootstrapping<dd>Bootstrapping Remote Secure Key Infrastructure <xreftarget="RFC8995"/></t> </dd>target="RFC8995"/></dd> <dt>BRSKI-AE:</dt><dd> <t>BRSKI<dd>BRSKI with<strong>A</strong>lternative <strong>E</strong>nrollment,Alternative Enrollment. Refers to a variation of BRSKI <xref target="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 Lightweight CMP (seeLCMPP).</t> </dd>LCMPP).</dd> <dt>CA:</dt> <dd>Certification Authority</dd> <dt>CA certs request:</dt><dd> <t>message<dd>a message requesting CAcertificates</t> </dd>certificates.</dd> <dt>CA certs response:</dt><dd> <t>message<dd>a message providing the answer to a CA certsrequest</t> </dd>request.</dd> <dt>certificate confirm:</dt><dd> <t>message<dd>a message stating to the backend PKI that the requester of a certificate received the new certificate and acceptedit</t> </dd>it.</dd> <dt>certification request:</dt><dd> <t>message<dd>a message requesting a certificate with proof ofidentity</t> </dd>identity.</dd> <dt>certification response:</dt><dd> <t>message<dd>a message providing the answer to a certificationrequest</t> </dd>request.</dd> <dt>CMP:</dt><dd> <t>Certificate<dd>Certificate Management Protocol <xref target="RFC4210"/> <xreftarget="RFC9480"/></t> </dd>target="RFC9480"/></dd> <dt>CSR:</dt><dd> <t>Certificate<dd>Certificate SigningRequest</t> </dd>Request</dd> <dt>EST:</dt><dd> <t>Enrollment<dd>Enrollment over Secure Transport <xreftarget="RFC7030"/></t> </dd>target="RFC7030"/></dd> <dt>IDevID:</dt><dd> <t>Initial<dd>Initial DeviceIDentifier ofIdentifier (of a pledge, provided by the manufacturer and comprising of a private key and the related X.509 certificate with itschain</t> </dd>chain).</dd> <dt>LCMPP:</dt><dd> <t>Lightweight<dd>Lightweight CMP Profile <xreftarget="RFC9483"/></t> </dd>target="RFC9483"/></dd> <dt>LDevID:</dt><dd> <t>Locally significant<dd>Local DeviceIDentifier ofIdentifier (of a pledge, provided by its target domain and comprising of a private key and the related X.509 certificate with itschain</t> </dd> <dt>local RA (LRA):</dt> <dd> <t>achain).</dd> <dt>LRA:</dt> <dd>Local Registration Authority. A subordinate RA that is close to entities being enrolled and separate from a subsequent RA. InBRSKI-AEBRSKI-AE, it is needed if a backend RA isused, andused; in this case, the LRA is co-located with theregistrar.</t> </dd>registrar.</dd> <dt>MASA:</dt><dd> <t>Manufacturer<dd>Manufacturer Authorized SigningAuthority, provides vouchers</t> </dd>Authority. Provides vouchers.</dd> <dt>off-site:</dt><dd> <t>locality<dd>the locality ofcomponent or servicea component, service, orfunctionality, suchfunctionality (such as RA orCA,CA) that is not at the site of the registrar. This may be a central site or a cloud service, to which connection may beintermittent.</t> </dd>intermittent.</dd> <dt>on-site:</dt><dd> <t>locality<dd>the locality of acomponent or servicecomponent, service, or functionality at the site of theregistrar</t> </dd>registrar.</dd> <dt>PKI/registrar confirm:</dt><dd> <t>acknowledgment<dd>an acknowledgment of the PKI on the certificateconfirm</t> </dd>confirm.</dd> <dt>pledge:</dt><dd> <t>device<dd>a device that is to be bootstrapped into a target domain. It requests an LDevID using IDevID credentials installed by itsmanufacturer.</t> </dd>manufacturer.</dd> <dt>RA:</dt><dd> <t>Registration Authority, the<dd>Registration Authority. The PKI component to which a CA typically delegates certificate management functions such as authenticating pledges and performing authorization checks on certificationrequests</t> </dd>requests.</dd> <dt>registrar:</dt><dd> <t>short<dd>short for domainregistrar</t> </dd>registrar.</dd> <dt>site:</dt><dd> <t>the<dd>the locality where anentity,entity such as a pledge, registrar, or PKI component is deployed. The target domain may have multiplesites.</t> </dd>sites.</dd> <dt>synchronous:</dt><dd> <t>time-wise<dd>the time-wise uninterrupted delivery of messages,herehere, between a pledge and a registrar or backend system (e.g., theMASA)</t> </dd>MASA).</dd> <dt>target domain:</dt><dd> <t>the<dd>the domain that a pledge is going to be bootstrappedinto</t> </dd>into.</dd> </dl> </section> <sectionanchor="req-sol"><name>Basicanchor="req-sol"> <name>Basic Requirements and Mapping to Solutions</name> <t>Based on the intended target scenarios described in <xref target="sup-env"/> and the application examples described in <xref target="app-examples"/>, the following requirements are derived to support authenticated self-contained objects as containers carrying certification requests.</t> <t>The following properties are required for a certification request:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>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 achievedindirectly,indirectly; see <xref section="4.3" sectionFormat="comma" target="RFC4210"/>.</t> </li> <li> <t>Proof ofidentity, alsoidentity (also calledproof"proof oforigin: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></list></t></li> </ul> <t>The remainder of this section gives a non-exhaustive list of solution examples, based on existing technology described in IETF documents.</t> <sectionanchor="solutions-PoP"><name>Solutionanchor="solutions-PoP"> <name>Solution Options for Proof of Possession</name> <t>Certificatesigning requestSigning Request (CSR)objects: CSRsobjects 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><t><list style="symbols"> <t>PKCS<ul spacing="normal"> <li>PKCS #10 <xreftarget="RFC2986"/>.target="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 therequest.</t> <t>Certificaterequest.</li> <li>Certificate Request Message Format(CRMF,(CRMF) <xreftarget="RFC4211"/>).target="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. Fordetailsdetails, see <xref section="4" sectionFormat="comma"target="RFC4211"/>.</t> </list></t>target="RFC4211"/>.</li> </ul> <t>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.YetYet, this signature does not provide data origin authentication,i.e.,(i.e., proof of identity of therequesterrequester) because the key pair involved is new and therefore does not yet have a confirmed identity associated with it. <!-- already covered by the next paragraph: This extra property can be achieved by an additional binding to the IDevID of the pledge. This binding to the source authentication supports the authorization decision of the certification request.--></t>--> </t> </section> <sectionanchor="solutions-PoI"><name>Solutionanchor="solutions-PoI"> <name>Solution Options for Proof of Identity</name><t>Binding<!-- [rfced] May we clarify the content in the parenthetical text below? Original: Binding a certificate signing request (CSR) to an existing authenticated credential (the BRSKI context, the IDevID certificate) enables proof of origin... Perhaps: Binding a Certificate Signing Request (CSR) to an existing authenticated credential (such as the BRSKI context or the IDevID certificate) enables proof of origin... --> <t>Binding a Certificate Signing Request (CSR) to an existing authenticated credential (the BRSKI context, the IDevID certificate) enables proof of origin, which in turn supports an authorization decision on the CSR.</t> <t>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>This requirement is addressed by existing enrollment protocols in various ways, such as:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>EST <xreftarget="RFC7030"/>, alsotarget="RFC7030"/> and its variant EST-coaps <xreftarget="RFC9148"/>, utilizestarget="RFC9148"/> utilize PKCS #10 to encodeCertificate Signing Requests (CSRs).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"/> resulting from the TLS handshake. As this is optionally supported by the EST<spanx style="verb">"/simpleenroll"</spanx><tt>"/simpleenroll"</tt> endpoint used inBRSKIBRSKI, 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 theCSR. <vspace blankLines='1'/> YetCSR.</t> <!-- [rfced] FYI - For ease of the reader, we have broken up the following sentences below into two. Please let us know any objections. Original: What the registrar needs to do is to authenticate and pre-authorize the pledge and to indicate this to the (second) RA by signing the forwarded certification request with its private key and a related certificate that has the id-kp- cmcRA extended key usage attribute. ... It will recognize whether the protocol it uses and the specific request it wants to perform are understood and supported by the domain registrar by sending the request to the respective endpoint according to the above addressing scheme and then evaluating the HTTP status code of the response. Current: 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. ... 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. --> <t>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 istoauthenticate and pre-authorize the pledge andtoindicate this to the (second)RARA. 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 usageattribute. <vspace blankLines='1'/> <xrefattribute.</t> <!--[rfced] To avoid the awkward hyphenation of "PKCS #10-formatted CSRs", may we update the text as follows? Original: [RFC7030], Section 2.5 sketches wrapping PKCS #10-formatted CSRs with a Full PKI Request message sent to the "/fullcmc" endpoint. Perhaps: [RFC7030], Section 2.5 sketches wrapping CSRs formatted per PKCS #10 with a Full PKI Request message sent to the "/fullcmc" endpoint. --> <t><xref section="2.5" sectionFormat="comma" target="RFC7030"/> sketches wrapping PKCS #10-formatted CSRs with a Full PKI Request message sent to the<spanx style="verb">"/fullcmc"</spanx><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></list></t></li> <!-- Note that, besides the existing enrollment protocols, there is ongoing work in the ACE WG to define an encapsulation of EST messages in OSCORE, which will result in a TLS-independent way of protecting EST. This approach {{draft.selander-ace-coap-est-oscore}} may be considered as a further variant. --><t><list style="symbols"> <t>SCEP<li> <t>The Simple Certificate Enrolment Protocol (SCEP) <xref target="RFC8894"/> supports using a shared secret (passphrase) or an existing certificate to protect CSRs based on SCEP Secure Message Objects usingCMSCryptographic Message Syntax (CMS) wrapping(<xref target="RFC5652"/>).<xref target="RFC5652"/>. Note that the wrapping using an existing IDevID in SCEP is referred to as'renewal'."renewal". Thiswayway, SCEP does not rely on the security of the underlying message transfer.</t> </li> <li> <t>CMP <xref target="RFC4210"/> <xref target="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><t>CMC</li> <!-- [rfced] We note the use of "FullCMCRequest" in the following sentence; however, RFC 7030 uses the term "Full CMC Request". May we update this instance for consistency with RFC 7030? Original: The proof of identity can be provided as part of a FullCMCRequest, based on CMS [RFC5652] and signed with an existing IDevID secret. Perhaps: The proof of identity can be provided as part of a Full CMC Request based on CMS [RFC5652] and signed with an existing IDevID secret. --> <li> <t>Certificate Management over CMS (CMC) <xref target="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 aFullCMCRequest,FullCMCRequest based on CMS <xref target="RFC5652"/> and signed with an existing IDevID secret. Thus, CMC does not rely on the security of the underlying message transfer.</t></list></t></li> </ul> <t>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> <sectionanchor="uc1"><name>Adaptationsanchor="uc1"> <name>Adaptations to BRSKI</name> <t>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"/>. This way, authenticated self-contained objects such as those described in <xref target="req-sol"/> 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>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> <sectionanchor="architecture"><name>Architecture</name>anchor="architecture"> <name>Architecture</name> <t>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"/>, 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>This leads to generalizations in the placement and enhancements of the logical elements as shown in <xref target="uc1figure"/>.</t> <figuretitle="Architectureanchor="uc1figure"> <name>Architecture Overview Using Backend PKIComponents" anchor="uc1figure"><artset><artworkComponents</name> <artset> <artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="576" width="544" viewBox="0 0 544 576" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,208 L 8,336" fill="none" stroke="black"/> <path d="M 32,48 L 32,200" fill="none" stroke="black"/> <path d="M 32,480 L 32,528" fill="none" stroke="black"/> <path d="M 80,208 L 80,336" fill="none" stroke="black"/> <path d="M 112,480 L 112,528" fill="none" stroke="black"/> <path d="M 152,240 L 152,304" fill="none" stroke="black"/> <path d="M 160,480 L 160,528" fill="none" stroke="black"/> <path d="M 216,240 L 216,304" fill="none" stroke="black"/> <path d="M 304,240 L 304,304" fill="none" stroke="black"/> <path d="M 336,32 L 336,144" fill="none" stroke="black"/> <path d="M 376,312 L 376,472" fill="none" stroke="black"/> <path d="M 424,240 L 424,304" fill="none" stroke="black"/> <path d="M 456,72 L 456,144" fill="none" stroke="black"/> <path d="M 472,152 L 472,256" fill="none" stroke="black"/> <path d="M 480,480 L 480,528" fill="none" stroke="black"/> <path d="M 536,32 L 536,144" fill="none" stroke="black"/> <path d="M 336,32 L 536,32" fill="none" stroke="black"/> <path d="M 32,48 L 144,48" fill="none" stroke="black"/> <path d="M 224,48 L 328,48" fill="none" stroke="black"/> <path d="M 336,64 L 536,64" fill="none" stroke="black"/> <path d="M 336,144 L 536,144" fill="none" stroke="black"/> <path d="M 8,208 L 80,208" fill="none" stroke="black"/> <path d="M 152,240 L 216,240" fill="none" stroke="black"/> <path d="M 304,240 L 424,240" fill="none" stroke="black"/> <path d="M 432,256 L 472,256" fill="none" stroke="black"/> <path d="M 88,272 L 144,272" fill="none" stroke="black"/> <path d="M 224,272 L 296,272" fill="none" stroke="black"/> <path d="M 152,304 L 216,304" fill="none" stroke="black"/> <path d="M 304,304 L 424,304" fill="none" stroke="black"/> <path d="M 8,336 L 80,336" fill="none" stroke="black"/> <path d="M 32,480 L 112,480" fill="none" stroke="black"/> <path d="M 160,480 L 480,480" fill="none" stroke="black"/> <path d="M 120,496 L 160,496" fill="none" stroke="black"/> <path d="M 112,512 L 152,512" fill="none" stroke="black"/> <path d="M 32,528 L 112,528" fill="none" stroke="black"/> <path d="M 160,528 L 480,528" fill="none" stroke="black"/> <polygon class="arrowhead" points="480,152 468,146.4 468,157.6" fill="black" transform="rotate(270,472,152)"/> <polygon class="arrowhead" points="440,256 428,250.4 428,261.6" fill="black" transform="rotate(180,432,256)"/> <polygon class="arrowhead" points="384,472 372,466.4 372,477.6" fill="black" transform="rotate(90,376,472)"/> <polygon class="arrowhead" points="384,312 372,306.4 372,317.6" fill="black" transform="rotate(270,376,312)"/> <polygon class="arrowhead" points="304,272 292,266.4 292,277.6" fill="black" transform="rotate(0,296,272)"/> <polygon class="arrowhead" points="232,272 220,266.4 220,277.6" fill="black" transform="rotate(180,224,272)"/> <polygon class="arrowhead" points="160,512 148,506.4 148,517.6" fill="black" transform="rotate(0,152,512)"/> <polygon class="arrowhead" points="152,272 140,266.4 140,277.6" fill="black" transform="rotate(0,144,272)"/> <polygon class="arrowhead" points="128,496 116,490.4 116,501.6" fill="black" transform="rotate(180,120,496)"/> <polygon class="arrowhead" points="96,272 84,266.4 84,277.6" fill="black" transform="rotate(180,88,272)"/> <polygon class="arrowhead" points="40,200 28,194.4 28,205.6" fill="black" transform="rotate(90,32,200)"/> <g class="text"> <text x="184" y="52">Drop-Ship</text> <text x="372" y="52">Vendor</text> <text x="432" y="52">Service</text> <text x="352" y="84">M</text> <text x="408" y="84">anufacturer</text> <text x="352" y="100">A</text> <text x="400" y="100">uthorized</text> <text x="496" y="100">Ownership</text> <text x="352" y="116">S</text> <text x="388" y="116">igning</text> <text x="488" y="116">Tracker</text> <text x="352" y="132">A</text> <text x="396" y="132">uthority</text> <text x="508" y="196">BRSKI-</text> <text x="288" y="212">.........................................</text> <text x="500" y="212">MASA</text> <text x="128" y="228">.</text> <text x="448" y="228">.</text> <text x="128" y="244">.</text> <text x="448" y="244">.</text> <text x="44" y="260">Pledge</text> <text x="128" y="260">.</text> <text x="180" y="260">Join</text> <text x="340" y="260">Domain</text> <text x="184" y="276">Proxy</text> <text x="352" y="276">Registrar</text> <text x="448" y="276">.</text> <text x="128" y="292">.</text> <text x="324" y="292">w/</text> <text x="352" y="292">LRA</text> <text x="380" y="292">or</text> <text x="404" y="292">RA</text> <text x="448" y="292">.</text> <text x="44" y="308">IDevID</text> <text x="128" y="308">.</text> <text x="448" y="308">.</text> <text x="140" y="324">BRSKI-AE</text> <text x="196" y="324">over</text> <text x="232" y="324">TLS</text> <text x="448" y="324">.</text> <text x="132" y="340">using,</text> <text x="184" y="340">e.g.,</text> <text x="232" y="340">LCMPP</text> <text x="448" y="340">.</text> <text x="128" y="356">.</text> <text x="448" y="356">.</text> <text x="248" y="372">...............................</text> <text x="416" y="372">.........</text> <text x="128" y="388">on-site</text> <text x="192" y="388">(local)</text> <text x="252" y="388">domain</text> <text x="324" y="388">components</text> <text x="408" y="420">e.g.,</text> <text x="456" y="420">LCMPP</text> <text x="192" y="452">.............................................</text> <text x="440" y="452">...............</text> <text x="16" y="468">.</text> <text x="68" y="468">Public-Key</text> <text x="172" y="468">Infrastructure</text> <text x="496" y="468">.</text> <text x="16" y="484">.</text> <text x="496" y="484">.</text> <text x="16" y="500">.</text> <text x="236" y="500">Registration</text> <text x="328" y="500">Authority</text> <text x="380" y="500">RA</text> <text x="496" y="500">.</text> <text x="16" y="516">.</text> <text x="76" y="516">CA</text> <text x="216" y="516">(unless</text> <text x="268" y="516">part</text> <text x="300" y="516">of</text> <text x="340" y="516">Domain</text> <text x="412" y="516">Registrar)</text> <text x="496" y="516">.</text> <text x="16" y="532">.</text> <text x="496" y="532">.</text> <text x="256" y="548">.............................................................</text> <text x="104" y="564">backend</text> <text x="172" y="564">(central</text> <text x="220" y="564">or</text> <text x="272" y="564">off-site)</text> <text x="340" y="564">domain</text> <text x="412" y="564">components</text> </g> </svg></artwork><artwork</artwork> <artwork type="ascii-art" align="left"><![CDATA[ +------------------------+ +--------------Drop-Ship--------------| Vendor Service | | +------------------------+ | | M anufacturer| | | | A uthorized |Ownership| | | S igning |Tracker | | | A uthority | | | +--------------+---------+ | ^ | | V | BRSKI- +--------+ ......................................... | MASA | | . . | | | . +-------+ +--------------+ . | | Pledge | . | Join | | Domain |<----+ | |<------>| Proxy |<-------->| Registrar | . | | . | | | w/ LRA or RA | . | IDevID | . +-------+ +--------------+ . | | BRSKI-AE over TLS ^ . +--------+ using, e.g., LCMPP | . . | . ...............................|......... on-site (local) domain components | | | e.g., LCMPP | .............................................|............... . Public-Key Infrastructure v . . +---------+ +---------------------------------------+ . . | |<----+ Registration Authority RA | . . | CA +---->| (unless part of Domain Registrar) | . . +---------+ +---------------------------------------+ . ............................................................. backend (central or off-site) domain components]]></artwork></artset></figure>]]></artwork> </artset> </figure> <t>The architecture overview in <xref target="uc1figure"/> has the same logical elements asBRSKI,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 inBRSKI),BRSKI) or only do part of them.</t> <t>The following list describes the on-site components in the target domain of the pledge shown in <xref target="uc1figure"/>.</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Join Proxy: This has the same requirements as inBRSKI, seeBRSKI (see <xref section="4" sectionFormat="comma"target="RFC8995"/></t>target="RFC8995"/>).</t> </li> <li> <t>Domain Registrarincluding(including LRA or RAfunctionality: infunctionality): 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.YetYet, there are some generalizations and specificrequirements: <list style="numbers">requirements:</t> <ol spacing="normal" type="1"><li> <t>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"/>).</t> </li> <li> <t>Rather than having full RA functionality, the registrar <bcp14>MAY</bcp14> act as alocal registration authorityLocal 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 thisendend, 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 samechannel. <vspace blankLines='1'/> Tochannel.</t> <t>To support end-to-end authentication of the pledge across the registrar to the backend RA, the certification request signed by the pledge needs to be upheld and forwarded by the registrar. Therefore,the registrar cannot usefor its communication with thePKIPKI, the registrar cannot use an enrollment protocol that is different from the enrollment protocol used between the pledge and the registrar.</t> </li> <li> <t>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 thisalsoin 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"/> for details on how this can be achieved.</t></list></t> </list></t></li> </ol> </li> </ul> <!-- is already covered by paragraph a little further below: Note: As far as (at least part of) the certificate enrollment traffic is routed via the registrar, BRSKI-AE re-uses during the certificate enrollment phase the channel that has been established in the BRSKI steps before between the pledge and the registrar. Consequently, tunneling via this channel needs to be supported by the certificate enrollment protocol. By default, this channel is based on HTTP over TLS, but it may also be based on, for instance, CoAP over DTLS in the context of Constrained BRSKI {{I-D.ietf-anima-constrained-voucher}}. --> <!-- In the latter scenario, the EST-specific parts of that specification do not apply. --> <t>Despite the above generalizationstoof the enrollment phase, the final step of BRSKI, namely the enrollment status telemetry, is kept as it is.</t> <t>The following list describes the components provided by the vendor or manufacturer outside the target domain.</t><t><list style="symbols"><ul spacing="normal"> <li> <t>MASA: This has the functionality as described in BRSKI <xref target="RFC8995"/>. The voucher exchange with the MASA via the domain registrar is performed as described inBRSKI. <vspace blankLines='1'/>BRSKI.</t> <!-- [rfced] In the sentence below, may we update "follows" for clarity? Original: Note: From the definition of the interaction with the MASA in [RFC8995], Section 5 follows that it may be synchronous (using voucher request with nonces) or asynchronous (using nonceless voucher requests). Perhaps: Note: From the definition of the interaction with the MASA in Section 5 of [RFC8995], it may be synchronous (using voucher requests with nonces) or asynchronous (using nonceless voucher requests). --> <t>Note: From the definition of the interaction with the MASA in <xref section="5" sectionFormat="comma" target="RFC8995"/> follows that it may be synchronous (using voucherrequestrequests with nonces) or asynchronous (using nonceless voucher requests).</t> </li> <li> <t>Ownershiptracker:Tracker: This is as defined in BRSKI.</t></list></t></li> </ul> <t>The following list describes backend target domain components, which may be located on-site or off-site in the target domain.</t><t><list style="symbols"><ul spacing="normal"> <!-- [rfced] How may we clarify what "as not already done" and "it" refer to in the text below? Original: * RA: performs centralized certificate management functions as a public-key infrastructure for the domain operator. As far as not already done by the domain registrar, it performs the final validation and authorization of certification requests. Perhaps: * RA: This performs centralized certificate management functions as a public-key infrastructure for the domain operator. As far as what is not already done by the domain registrar, the RA performs the final validation and authorization of certification requests. --> <!-- [rfced] Throughout this document, we note that RFCs 8895 and 9483 are often referred to with shortened titles or nicknames such as "BRSKI" and "LCMPP", respectively. For clarity, because these names also represent protocols, we plan to update these document nicknames to just their RFC number (in order to help the reader distinguish between the RFC itself and the protocol). Please see some examples below and let us know any objections. Originals: In this document, references to CMP follow the Lightweight CMP Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the subset of CMP defined in LCMPP sufficiently meets the required functionality. * MASA: functionality as described in BRSKI [RFC8995]. The voucher exchange with the MASA via the domain registrar is performed as described in BRSKI. * Ownership tracker: This is as defined in BRSKI. Perhaps: In this document, references to CMP follow [RFC9483] rather than [RFC4210] and [RFC9480], as the subset of CMP defined in [RFC9483] sufficiently meets the required functionality. * MASA: This has the functionality as described in [RFC8995]. The voucher exchange with the MASA via the domain registrar is performed as described in [RFC8995]. * Ownership Tracker: This is as defined in [RFC8995]. --> <!-- [rfced] In Section 4.1, should "Discovery phase" and "Identification phase" be updated to "Discover phase" and "Identity phase", respectively, to better match the figure from Section 2.1 of RFC 8995? Original: Based on the diagram in BRSKI [RFC8995], Section 2.1 and the architectural changes, the original protocol flow is divided into several phases showing commonalities and differences to the original approach as follows. * Discovery phase: mostly as in BRSKI step (1). For details see Section 4.2.1. * Identification phase: same as in BRSKI step (2). Perhaps: Based on the diagram in [RFC8995], Section 2.1 and the architectural changes, the original protocol flow is divided into several phases showing commonalities and differences to the original approach as follows. * Discover phase: This is mostly as in step (1) of [RFC8995]. For details see Section 4.2.1. * Identity phase: This is the same as in step (2) of [RFC8995]. --> <li> <t>RA: This performs centralized certificate management functions as a public-key infrastructure for the domain operator. As far as not already done by the domain registrar, it performs the final validation and authorization of certification requests. Otherwise, the RA co-located with the domain registrar directly connects to the CA.</t><t>CA, also</li> <li> <t>CA (also calleddomain CA:"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></list></t></li> </ul> <t>Based on the diagram in BRSKI <xref section="2.1" sectionFormat="comma" target="RFC8995"/> and the architectural changes, the original protocol flow is divided into several phases showing commonalities and differencestowith the original approach as follows.</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Discovery phase: This is mostly as inBRSKIstep(1).(1) of <xref target="RFC8995"/>. Fordetailsdetails, see <xref target="discovery"/>.</t> </li> <li> <t>Identification phase: This is the same as inBRSKIstep(2).</t>(2) of <xref target="RFC8995"/>.</t> </li> <li> <t>Voucher exchange phase: This is the same as inBRSKIsteps (3) and(4).</t>(4) of <xref target="RFC8995"/>.</t> </li> <li> <t>Voucher status telemetry: This is the same asin BRSKIdirectly after step(4).</t>(4) in <xref target="RFC8995"/>.</t> </li> <li> <t>Certificate enrollment phase:theThe use of EST in step (5) is changed to employing a certificate enrollment protocol that uses an authenticated self-contained object for requesting the LDevIDcertificate. <vspace blankLines='1'/>certificate.</t> <!--[rfced] To improve the readability of the following sentence, may we update it as follows? Original: For transporting the certificate enrollment request and response messages, the (D)TLS channel established between pledge and registrar is REQUIRED to use. Perhaps: It is REQUIRED to use the (D)TLS channel established between the pledge and registrar to transport the certificate enrollment request and response messages. --> <t>For transporting the certificate enrollment request and response messages, the (D)TLS channel established between pledge and registrar is <bcp14>REQUIRED</bcp14> to use. To this end, the enrollment protocol, the pledge, and the registrar need to support the use of this existing channel for certificate enrollment. Due to this architecture, the pledge does not need to establish additional connections for certificate enrollment and the registrar retains full control over the certificate enrollment traffic.</t> </li> <li> <t>Enrollment status telemetry: This is the final exchange ofBRSKIstep(5).</t> </list></t>(5) of <xref target="RFC8995"/>.</t> </li> </ul> </section> <sectionanchor="message_ex"><name>Messageanchor="message_ex"> <name>Message Exchange</name> <t>The behavior of a pledge described in BRSKI <xref section="2.1" sectionFormat="comma" target="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"/>. <!-- the certification request MUST be performed using an authenticated self-contained object providing not only proof of possession but also proof of identity (source authentication). --> <!-- [rfced] Should "options applicable" be updated to "applicable options" in the text below? Original: Section 5 discusses selected suitable enrollment protocols and options applicable. Perhaps: Section 5 discusses selected suitable enrollment protocols and applicable options. --> <xref target="exist_prot"/> discusses selected suitable enrollment protocols and options applicable.</t> <t>An abstract overview of the BRSKI-AE protocol can be found at <xreftarget="BRSKI-AE-overview"/>.</t>target="BRSKI-AE-OVERVIEW"/>.</t> <sectionanchor="discovery"><name>Pledgeanchor="discovery"> <name>Pledge - Registrar Discovery</name> <t>Discovery as specified in BRSKI <xref section="4" sectionFormat="comma" target="RFC8995"/> does not support the discovery of registrars with enhanced feature sets. A pledgecan notcannot find out in this way whether discovered registrars support the certificate enrollment protocol it expects, such as CMP.</t> <t>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"/>.</t> <t>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"/> defines a minimalist approach that <bcp14>MAY</bcp14> be used for CMP.</t> </section> <sectionanchor="pledge-registrar-masa-voucher-exchange"><name>Pledgeanchor="pledge-registrar-masa-voucher-exchange"> <name>Pledge - Registrar - MASA Voucher Exchange</name> <t>The voucher exchange is performed as specified in <xref target="RFC8995"/>.</t> </section> <sectionanchor="pledge-registrar-masa-voucher-status-telemetry"><name>Pledgeanchor="pledge-registrar-masa-voucher-status-telemetry"> <name>Pledge - Registrar - MASA Voucher Status Telemetry</name> <t>The voucher status telemetry is performed as specified in <xref section="5.7" sectionFormat="comma" target="RFC8995"/>.</t> </section> <!-- [rfced] As this sentence begins Section 4.2.4, may we clarify what "This" refers to? Additionally, may we make a similar update in Appendix A.5? Original: 4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment This replaces the EST integration for PKI bootstrapping described in [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the final phase, see below). ... A.5. Infrastructure Isolation Policy This refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. Perhaps: 4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment RA/CA certificate enrollment replaces the EST integration for PKI bootstrapping described in Section 5.9 of [RFC8995] (while Section 5.9.4 of [RFC8995] remains as the final phase; see below). ... A.5. Infrastructure Isolation Policy The infrastructure isolation policy refers to any case in which... --> <sectionanchor="pledge-registrar-raca-certificate-enrollment"><name>Pledgeanchor="pledge-registrar-raca-certificate-enrollment"> <name>Pledge - Registrar - RA/CA Certificate Enrollment</name> <t>This replaces the EST integration for PKI bootstrapping described in <xref section="5.9" sectionFormat="comma" target="RFC8995"/> (while <xref section="5.9.4" sectionFormat="comma" target="RFC8995"/> remains as the finalphase,phase; see below).</t> <t>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. <!-- <br> In line with the generalizations described in {{architecture}}, It is RECOMMENDED to transfer these messages via the channel established between the pledge and the registrar.--></t>--> </t> <t>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> <t>Note: The message exchanges marked <bcp14>OPTIONAL</bcp14> inthe below<xref target="enrollfigure"/> below cover all those supported by the use of EST in BRSKI. The last <bcp14>OPTIONAL</bcp14> one, namely certificate confirmation, is not supported byEST,EST but by CMP and other enrollment protocols.</t> <figuretitle="Certificateanchor="enrollfigure"> <name>Certificate Enrollment MessageFlow" anchor="enrollfigure"><artset><artworkFlow</name> <artset> <artwork type="svg"align="left"><svgalign="left"> <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</artwork> <artwork type="ascii-art" align="left"><![CDATA[ +------+ +---------+ +--------+ |Pledge| |Domain | |Operator| | | |Registrar| |RA/CA | | | |(JRC) | |(PKI) | +------+ +---------+ +--------+ | | | |[OPTIONAL request of CA certificates]| | |------- CA Certs Request (1) ------->| | | | [OPTIONAL forwarding] | | |--- CA Certs Request ----->| | |<-- CA Certs Response -----| |<------ CA Certs Response (2) -------| | | | | |[OPTIONAL request of attributes | | | to include in Certification Request]| | |------- Attribute Request (3) ------>| | | | [OPTIONAL forwarding] | | |--- Attribute Request ---->| | |<-- Attribute Response ----| |<------ Attribute Response (4) ------| | | | | |[REQUIRED certification request] | | |------- Certification Request (5) -->| | | | [OPTIONAL forwarding] | | |---Certification Request-->| | |<--Certification Resp. ---| |<----- Certification Response (6) ---| | | | | |[OPTIONAL certificate confirmation] | | |------- Certificate Confirm (7) ---->| | | | [OPTIONAL forwarding] | | |--- Certificate Confirm--->| | |<-- PKI Confirm -----------| |<------ PKI/Registrar Confirm (8) ---| |]]></artwork></artset></figure>]]></artwork> </artset> </figure> <t>It may be noted that connections between the registrar and the PKI components of the operator (RA, CA, etc.) may be intermittent oroff-line.offline. Messages should be sent as soon as sufficient transfer capacity is available.</t> <t>The label<spanx style="verb">[OPTIONAL forwarding]</spanx><tt>[OPTIONAL forwarding]</tt> in <xref target="enrollfigure"/> means that on receivingfrom a pledgea request message of the giventype,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> <!-- [rfced] To improve readability, may we update the list below as follows? Original: They include the application scenario, the capabilities of the registrar and of the local RA possibly co-located with the registrar, the enrollment protocol being used, and the specific contents of the request. Perhaps: 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>The decision of whether to forward a request or to answer it directly can depend on various static and dynamic factors. They include the application scenario, the capabilities of the registrar and of the local RA possibly co-located with the registrar, the enrollment protocol being used, and the specific contents of the request.</t> <t>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>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 ornotauthorized.<!--br--> Also, certificate confirmation messages will usually be forwarded to the backend PKI, but if the registrar knows that they are not needed or wantedtherethere, it can acknowledge such messages directly.</t> <t>The following list provides an abstract description of the flow depicted in <xref target="enrollfigure"/>.</t><t><list style="symbols"><ul spacing="normal"> <li> <t>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> <t>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> <t>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 includein the Certification Request (5)additional attributes that are specific to the targetdomain.domain in the Certification Request (5). To get these attributes in advance, the attribute request may be used.</t> </li> <li> <t>Attribute Response (4): This <bcp14>MUST</bcp14> contain the attributes requested in (3) to be included in the subsequent Certification Request(5). <vspace blankLines='1'/> For(5).</t> <t>For example, <xref section="6.11.7.2" sectionFormat="comma" target="RFC8994"/> specifies how the attribute request is used to signal to the pledge the acp-node-name field required for enrollment into anACPAutonomic Control Plane (ACP) domain.</t> </li> <li> <t>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> <t>Certification Response (6):ThisOn success, this <bcp14>MUST</bcp14> containon successthe requested certificate and <bcp14>MAY</bcp14> include further information, like certificates of intermediate CAs and any additional trust anchors.</t> </li> <li> <t>Certificate Confirm (7):AnThis 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> <t>PKI/Registrar Confirm (8):AnThis is an acknowledgment by the PKI that <bcp14>MUST</bcp14> be sent on reception of the Certificate Confirm.</t></list></t></li> </ul> <t>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"/>. Examples are available in <xref target="exist_prot"/>.</t> <t>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> </section> <sectionanchor="pledge-registrar-enrollment-status-telemetry"><name>Pledgeanchor="pledge-registrar-enrollment-status-telemetry"> <name>Pledge - Registrar Enrollment Status Telemetry</name> <t>The enrollment status telemetry is performed as specified in <xref section="5.9.4" sectionFormat="comma" target="RFC8995"/>.</t> <t>InBRSKIBRSKI, this is described as part of the certificate enrollment step, but due to the generalizationonof the enrollment protocol described in thisdocumentdocument, it is regarded as a separate phase here.</t> </section> </section> <sectionanchor="addressing"><name>Enhancementsanchor="addressing"> <name>Enhancements to the Endpoint Addressing Scheme of BRSKI</name> <t>BRSKI-AE extends the addressing scheme outlined in <xref section="5" sectionFormat="comma"target="RFC8995"/>,target="RFC8995"/> to support alternative enrollment protocols that utilize authenticated, self-contained objects for certification requests--(also seealso<xref target="exist_prot"/>). 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>The addressing scheme in BRSKI for certificationrequests and therequests, related CAcertificatescertificates, and CSR attributes retrieval functions uses the definition from EST <xref target="RFC7030"/>.Here is theAn example of simpleenrollment: <spanx style="verb">"/.well-known/est/simpleenroll"</spanx>.enrollment is: <tt>"/.well-known/est/simpleenroll"</tt>. This approach is generalized to the following notation:<spanx style="verb">"/.well-known/<enrollment-protocol>/<request>"</spanx><tt>"/.well-known/<enrollment-protocol>/<request>"</tt> in which<spanx style="verb"><enrollment-protocol></spanx><tt><enrollment-protocol></tt> refers to a certificate enrollment protocol. Note that here, enrollment is consideredherea 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><t><list style="symbols"> <t><spanx style="verb"><enrollment-protocol></spanx>:<ul spacing="normal"> <li> <t><tt><enrollment-protocol></tt>: This <bcp14>MUST</bcp14> reference the protocol being used. Existing values include'<spanx style="verb">est</spanx>''<tt>est</tt>' <xref target="RFC7030"/> as in BRSKI and'<spanx style="verb">cmp</spanx>''<tt>cmp</tt>' as in <xref target="RFC9483"/> and <xref target="brski-cmp-instance"/> below. Values for other existing protocols such as CMC and SCEP, as well asfornewly definedprotocolsprotocols, are outside the scope of this document. For use of the<spanx style="verb"><enrollment-protocol></spanx><tt><enrollment-protocol></tt> and<spanx style="verb"><request></spanx><tt><request></tt> URI components, they would need to be specified in a suitable RFC and placed into theWell-Known URIs"Well-Known URIs" registry, just as EST in <xref target="RFC7030"/>.</t><t><spanx style="verb"><request></spanx>: if</li> <li> <t><tt><request></tt>: If present, this path component <bcp14>MUST</bcp14>describe,describe the operation requested depending on the enrollment protocol beingused, the operation requested.used. Enrollment protocols are expected to define their request endpoints, as is done by existing protocols(see also(also see <xref target="exist_prot"/>).</t></list></t></li> </ul> <!-- ## Domain Registrar Support of Alternative Enrollment Protocols --> <t>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>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 domainregistrarregistrar. 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 rejectit,it even if the registrar supports the intended protocol and operation.</t> <t>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"/> and the Lightweight CMP Profile <xref target="RFC9483"/>.</t><figure><artwork<!--[rfced] Should the following artwork element be reformatted as a bulleted list, per text from the preceding paragraph? Original: 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. ... /.well-known/brski/voucherrequest /.well-known/brski/voucher_status /.well-known/brski/enrollstatus /.well-known/est/cacerts /.well-known/est/csrattrs /.well-known/est/fullcmc /.well-known/cmp/getcacerts /.well-known/cmp/getcertreqtemplate /.well-known/cmp/initialization /.well-known/cmp/pkcs10 --> <artwork align="left"><![CDATA[ /.well-known/brski/voucherrequest /.well-known/brski/voucher_status /.well-known/brski/enrollstatus /.well-known/est/cacerts /.well-known/est/csrattrs /.well-known/est/fullcmc /.well-known/cmp/getcacerts /.well-known/cmp/getcertreqtemplate /.well-known/cmp/initialization /.well-known/cmp/pkcs10]]></artwork></figure>]]></artwork> </section> </section> <sectionanchor="exist_prot"><name>Instantiationanchor="exist_prot"> <name>Instantiation with Existing Enrollment Protocols</name> <t>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> <sectionanchor="brski-cmp-instance"><name>BRSKI-CMP:anchor="brski-cmp-instance"> <name>BRSKI-CMP: BRSKI-AEinstantiatedInstantiated with CMP</name> <t>In this document, references to CMP follow the Lightweight CMP Profile (LCMPP) <xref target="RFC9483"/> rather than <xref target="RFC4210"/> and <xref target="RFC9480"/>, as the subset of CMP defined in LCMPP sufficiently meets the required functionality.</t> <t>Adherence to the LCMPP <xreftarget="RFC9483"></xref>target="RFC9483"/> is <bcp14>REQUIRED</bcp14> when using CMP. The following specific requirements apply (refer to <xref target="enrollfigure"/>):</t><t><list style="symbols"><ul spacing="normal"> <li> <t>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 thepinned-domain-cert. <vspace blankLines='1'/> Notepinned-domain-cert.</t> <t>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 performedhop-by-hop,hop-by-hop but are usually end-to-end.</t> </li> <li> <t>CA Certs Request (1) and Response(2):<br />(2): Requesting CA certificates is<bcp14>OPTIONAL</bcp14>.<br /><bcp14>OPTIONAL</bcp14>. If supported, it <bcp14>SHALL</bcp14> be implemented as specified in <xref section="4.3.1" sectionFormat="comma" target="RFC9483"/>.</t> </li> <li> <t>Attribute Request (3) and Response(4):<br />(4): Requesting certification request attributes is<bcp14>OPTIONAL</bcp14>.<br /><bcp14>OPTIONAL</bcp14>. If supported, it <bcp14>SHALL</bcp14> be implemented as specified in <xref section="4.3.3" sectionFormat="comma"target="RFC9483"/>. <vspace blankLines='1'/> Alternatively,target="RFC9483"/>.</t> <t>Alternatively, the registrar <bcp14>MAY</bcp14> modify the requested certificate contents as specified in <xref section="5.2.3.2" sectionFormat="comma" target="RFC9483"/>.</t> </li> <li> <t>Certification Request (5) and Response(6):<br />(6): Certificates <bcp14>SHALL</bcp14> be requested and provided as specified in LCMPP <xref section="4.1.1" sectionFormat="comma" target="RFC9483"/> (based on CRMF) or <xref section="4.1.4" sectionFormat="comma" target="RFC9483"/> (based on PKCS #10).<vspace blankLines='1'/></t> <t> 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"/>,target="RFC9483"/> using the IDevIDsecret. <vspace blankLines='1'/>secret.</t> <t> 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"/>. 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.<vspace blankLines='1'/></t> <t> If additional trustanchors,anchors beyond thepinned-domain-cert,pinned-domain-cert need to be conveyed to the pledge, this <bcp14>SHOULD</bcp14> be done in the<spanx style="verb">caPubs</spanx><tt>caPubs</tt> field of the certification response rather than through a CA Certs Response.</t> </li> <li> <t>Certificate Confirm (7) and PKI/Registrar Confirm(8):<br />(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"/>. <vspace blankLines='1'/> Notetarget="RFC9483"/>.</t> <t>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"/>.</t> </li> <li> <t>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 inSectionSections <xref target="RFC9483" section="4.4" sectionFormat="bare"/> andSection<xref target="RFC9483" section="5.1.2" sectionFormat="bare"/> of <xref target="RFC9483"/>.</t></list></t></li> </ul> <t>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 <xreftarget="sec-consider"/>target="sec-consider" format="counter"/> and <xreftarget="priv-consider"/>.target="priv-consider" format="counter"/>. Further guidance can be found in <xref section="6" sectionFormat="comma" target="RFC9483"/>.</t> <!-- CMP Updates {{RFC9480}} and the LCMPP {{RFC9483}} provide requirements for interoperability. --> <t>BRSKI-AE with CMP can also be combined with Constrained BRSKI <xref target="I-D.ietf-anima-constrained-voucher"/>, using CoAP for enrollment message transport as described by CoAPTransportTransfer for CMP <xref target="RFC9482"/>. In such scenarios, the EST-specific parts of <xref target="I-D.ietf-anima-constrained-voucher"/> do not apply.</t> <t>For BRSKI-AE scenarios where a general solution for discovering registrars with CMP support is not available (cf. <xref target="discovery"/>), the following minimalist approach <bcp14>MAY</bcp14> be used:performPerform discovery as defined in BRSKI <xrefsection="B"target="RFC8995" sectionFormat="comma"target="RFC8995"/>,section="B"/>, but use the service name<spanx style="verb">"brski-reg-cmp"</spanx><tt>"brski-reg-cmp"</tt> (as defined in <xref target="iana-consider"/>) instead of<spanx style="verb">"brski-registrar"</spanx><tt>"brski-registrar"</tt> (as defined in <xref section="8.6" sectionFormat="comma" target="RFC8995"/>). Note that this approach does not support join proxies.</t> </section> <sectionanchor="support-of-other-enrollment-protocols"><name>Supportanchor="support-of-other-enrollment-protocols"> <name>Support of Other Enrollment Protocols</name> <t>Further instantiations of BRSKI-AE can be done. They are left for future work.</t> <t>In particular, CMC <xref target="RFC5272"/> (using its in-band source authentication options) and SCEP <xref target="RFC8894"/> (using its 'renewal' option) could be used.</t> <t>The fullCMC variant of EST sketched in <xref section="2.5" sectionFormat="comma" target="RFC7030"/> might also be used here. ForEST-fullCMCEST-fullCMC, further specification is necessary. <!-- Yet most likely it will not be followed up because, by now, no implementations of this EST variant are known, and no reasons are known why it could be preferable over using BRSKI-CMP.--></t>--> </t> <!-- ## BRSKI-EST-fullCMC: Application to EST When using EST {{RFC7030}}, the following aspects and constraints need to be considered and the given extra requirements need to be fulfilled, which adapt BRSKI {{RFC8995, Section 5.9.3}}: * Proof of possession is provided typically by using the specified PKCS #10 structure in the request. Together with Full PKI requests, also CRMF can be used. * Proof of identity needs to be achieved by signing the certification request object using the Full PKI Request option (including the /fullcmc endpoint). This provides sufficient information for the RA to authenticate the pledge as the origin of the request and to make an authorization decision on the received certification request. Note: EST references CMC {{RFC5272}} for the definition of the Full PKI Request. For proof of identity, the signature of the SignedData of the Full PKI Request is performed using the IDevID secret of the pledge. The data signed must include include a sufficiently strong identifier of the pledge, e.g, the subject of its IDevID certificate. Note: In this case the binding to the underlying TLS channel is not necessary. * When the RA is temporarily not available, as per {{RFC7030, Section 4.2.3}}, an HTTP status code 202 should be returned by the registrar, and the pledge will repeat the initial Full PKI Request later. --> <!-- Note that the work in the ACE WG described in {{draft-selander-ace-coap-est-oscore}} may be considered here as well, as it also addresses the encapsulation of EST in a way that makes it independent of the underlying TLS channel using OSCORE, which also entails that authenticated self-contained objects are used. --> </section> </section> <sectionanchor="iana-consider"><name>IANAanchor="iana-consider"> <name>IANA Considerations</name><t>This document requires one IANA action: register<t>IANA has registered the following service name in the <ereftarget="https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml">Servicetarget="https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml" brackets="angle">"Service Name and Transport Protocol Port NumberRegistry</eref> the following service name.</t> <t><strong>Service Name:</strong> brski-reg-cmp<br /> <strong>Transport Protocol(s):</strong> tcp<br /> <strong>Assignee:</strong> IESG <eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref><br /> <strong>Contact:</strong> IETF <eref target="mailto:chair@ietf.org">chair@ietf.org</eref><br /> <strong>Description:</strong> BootstrappingRegistry"</eref>.</t> <dl spacing="compact" newline="false"> <dt>Service Name:</dt><dd>brski-reg-cmp</dd> <dt>Transport Protocol(s):</dt><dd>tcp</dd> <dt>Description:</dt><dd>Bootstrapping Remote Secure Key Infrastructure registrar with CMP capabilities according to the Lightweight CMP Profile(LCMPP,(LCMPP) <xreftarget="RFC9483"/>)<br /> <strong>Reference:</strong> [THISRFC]</t>target="RFC9483"/></dd> <dt>Assignee:</dt><dd>IESG <eref target="mailto:iesg@ietf.org">iesg@ietf.org</eref></dd> <dt>Contact:</dt><dd>IETF <eref target="mailto:chair@ietf.org">chair@ietf.org</eref></dd> <dt>Reference:</dt><dd>RFC 9733</dd> </dl> <t>Note: We choseherethe 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 LCMPP is necessary and sufficient.</t> </section> <sectionanchor="sec-consider"><name>Securityanchor="sec-consider"> <name>Security Considerations</name> <t>The security considerations laid out in BRSKI <xref section="11" sectionFormat="comma" target="RFC8995"/> apply to the discovery and voucher exchange as well as for the status exchange information.</t> <t>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"/>. As thispertainsalso pertains to obtaining a valid domain-specific certificate, it must be made sure that a pledgecan notcannot circumvent the registrar in the decision of whether it is granted an LDevID certificate by the CA. There are various wayshowto fulfill this, including:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>implicitconsent</t>consent;</t> </li> <li> <t>the registrarsignalssignaling its consent to the RA out-of-band before or during the enrollment phase, forinstanceinstance, by entering the pledge identity in adatabase.</t>database;</t> </li> <li> <t>the registrarprovidesproviding its consent using an extra message that is transferred on the same channel as the enrollment messages, possibly in a TLStunnel.</t>tunnel; and</t> </li> <li> <t>the registrar explicitlystatesstating its consent bysigning, in addition to the pledge,signing the authenticated self-contained certificate enrollment requestmessage.</t> </list></t>message in addition to the pledge.</t> </li> </ul> <t>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> <t>When CMP is used, the security considerations laid out intheLCMPP <xref target="RFC9483"/> apply.</t> </section> <sectionanchor="priv-consider"><name>Privacyanchor="priv-consider"> <name>Privacy Considerations</name> <t>The privacy considerations laid out in BRSKI <xref section="10" sectionFormat="comma" target="RFC8995"/> apply as well.</t> <t>Note that CMP messages themselves are not encrypted. This may give eavesdroppers insight into which devices are bootstrapped into the domain.This in turnIn turn, this might also be used to selectively block the enrollment of certain devices.</t> <t>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><section anchor="acknowledgments"><name>Acknowledgments</name> <t>We thank Eliot Lear for his contributions as a co-author at an earlier draft stage.</t> <t>We thank Brian E. Carpenter, Michael Richardson, and Giorgio Romanenghi for their input and discussion on use cases and call flows.</t> <t>Moreover, we thank Toerless Eckert (document shepherd), Barry Leiba (SECdir review), Mahesh Jethanandani (IETF area director), Meral Shirazipour (Gen-ART reviewer), Reshad Rahman (YANGDOCTORS reviewer), Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Danyliw, and Éric Vyncke (IESG reviewers), Michael Richardson (ANIMA design team member), as well as Rajeev Ranjan, Rufus Buschart, Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) for their reviews with suggestions for improvements.</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> <name>References</name> <referencestitle='Normative References'anchor="sec-normative-references"><reference anchor="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>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="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>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"> <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>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><name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9483.xml"/> <!-- [IEEE_802.1AR-2018] --> <reference anchor="IEEE_802.1AR-2018" target="https://ieeexplore.ieee.org/document/8423794"> <front> <title>IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity</title><author ><author> <organization>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"> <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>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="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>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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <referencestitle='Informative References'anchor="sec-informative-references"><reference anchor="I-D.ietf-anima-constrained-voucher"> <front> <title>Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)</title> <author fullname="Michael Richardson" initials="M." surname="Richardson"> <organization>Sandelman Software Works</organization> </author> <author fullname="Peter Van der Stok" initials="P." surname="Van der Stok"> <organization>vanderstok consultancy</organization> </author> <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis"> <organization>Cisco Systems</organization> </author> <author fullname="Esko Dijk" initials="E." surname="Dijk"> <organization>IoTconsultancy.nl</organization> </author> <date day="8" month="July" year="2024"/> <abstract> <t> 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<name>Informative References</name> <!-- [I-D.ietf-anima-constrained-voucher] IESG State: I-D Exists as ofa domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant10/28/2024; WG State: In WG Last Call as ofthe 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-25"/> </reference>10/28/2024 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml"/> <referenceanchor="BRSKI-AE-overview" >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"> <front><title>BRSKI-AE Protocol Overview</title> <author initials="" surname="S. Fries" fullname="S. Fries"> <organization></organization> </author><title>Update on BRSKI-AE: Alternative Enrollment Protocols in BRSKI</title> <author initials="D."surname="von Oheimb"> <organization></organization>surname="von Oheimb" fullname="David von Oheimb" role="editor"> <organization/> </author><date year="2023" month="March"/> </front> <format type="PDF" target="https://datatracker.ietf.org/meeting/116/materials/slides-116-anima-update-on-brski-ae-alternative-enrollment-protocols-in-brski-00"/> <annotation>Graphics on slide 4 of the status update on the BRSKI-AE draft 04 at IETF 116.</annotation></reference> <reference anchor="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>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"> <front> <title>Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)</title> <author fullname="C. Adams" initials="C." surname="Adams"/><authorfullname="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>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"> <front> <title>Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>surname="Fries" fullname="Steffen Fries"> <organization/> </author> <authorfullname="J. Schaad" initials="J." surname="Schaad"/>initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus"> <organization/> </author> <datemonth="September" year="2005"/> <abstract> <t>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>year="2023" month="March"/> </front><seriesInfo name="RFC" value="4211"/> <seriesInfo name="DOI" value="10.17487/RFC4211"/><refcontent>IETF 116 - ANIMA Working Group Presentation</refcontent> </reference><reference anchor="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>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>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>2.<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5929.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6955.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8366.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8894.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9148.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9480.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9482.xml"/> <!-- TH TODO: Theneed for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</t> <t>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"> <front> <title>Cryptographic Message Syntax (CMS)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="September" year="2009"/> <abstract> <t>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"> <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>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>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"> <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>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 needednormative references forsuch 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 oftheprivate key and2017 version do notto be a general purpose signing algorithm.</t> <t>This document obsoletesinclude RFC2875.</t> </abstract> </front> <seriesInfo name="RFC" value="6955"/> <seriesInfo name="DOI" value="10.17487/RFC6955"/> </reference> <reference anchor="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>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"> <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>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>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>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"> <front> <title>Simple Certificate Enrolment Protocol</title> <author fullname="P. Gutmann" initials="P." surname="Gutmann"/> <date month="September" year="2020"/> <abstract> <t>This document specifies8894 (SCEP). Rather, they reference theSimple 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 Internet-Draft. RFC 8894 isthe evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide supportreferenced inboth 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"> <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>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"> <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>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often usethelightweight 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>2023 version.--> <referenceanchor="RFC9480">anchor="IEC-62351-9" target="https://webstore.iec.ch/en/publication/30287"> <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>This document contains a set of updates to the syntax of Certificate Management Protocol (CMP) version 2<title>Power systems management andits HTTP transfer mechanism. This document updates RFCs 4210, 5912,associated information exchange - Data and6712.</t> <t>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, extendedcommunications security - Part 9: Cyber security keyusages to identify certificatesmanagement foruse with CMP, and well-known URI path segments.</t> <t>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>power system equipment</title> <author> <organization>International Electrotechnical Commission</organization> </author> <date year="2017" month="May"/> </front> <seriesInfoname="RFC" value="9480"/> <seriesInfo name="DOI" value="10.17487/RFC9480"/>name="IEC" value="62351-9:2017"/> </reference><reference anchor="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>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<!-- XML forthe purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet2023 version ofThings space.</t> </abstract> </front> <seriesInfo name="RFC" value="9482"/> <seriesInfo name="DOI" value="10.17487/RFC9482"/> </reference>[IEC-62351-9]: <reference anchor="IEC-62351-9">target="https://webstore.iec.ch/en/publication/66864"> <front><title>IEC 62351 - Power<title>Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment</title><author ><author> <organization>International Electrotechnical Commission</organization> </author> <dateyear="2017" month="May"/>year="2023" month="June"/> </front> <seriesInfo name="IEC"value="62351-9 "/>value="62351-9:2023"/> </reference> --> <reference anchor="NERC-CIP-005-5">target=""> <front> <title>Cyber Security - Electronic Security Perimeter</title><author ><author> <organization>North American Electric Reliability Council</organization> </author> <date year="2013" month="December"/> </front> <seriesInfo name="CIP" value="005-5"/> </reference> <!-- [ISO-IEC-15118-2] Note to PE: The correct series number for this reference is "ISO 15118-2:2014", rather than "ISO/IEC 15118-2". Although some sources say this reference is also an IEC doc (for example: https://en.wikipedia.org/wiki/ISO_15118) the correct SDO is simply ISO. It may be a good idea to update the cite tag to [ISO-15118-2], since I was unable to find any versions of this reference which mention IEC. --> <reference anchor="ISO-IEC-15118-2">target="https://www.iso.org/standard/55366.html"> <front><title>ISO/IEC 15118-2 Road<title>Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network and application protocol requirements</title><author ><author> <organization>InternationalStandardizationOrganization/ International Electrotechnical Commission</organization>for Standardization</organization> </author> <date year="2014" month="April"/> </front> <seriesInfoname="ISO/IEC" value="15118-2 "/>name="ISO" value="15118-2:2014"/> </reference> <!-- [UNISIG-Subset-137] For RE/PE during AUTH 48 - Updated XML for [UNISIG-Subset-137]: <reference anchor="UNISIG-Subset-137" target=""> <front> <title>ERTMS/ETCS On-line Key Management FFFIS</title> <author> <organization>UNISIG</organization> </author> <date year="2023" month="May"/> </front> <refcontent>Subset-137, Version 4.0.0</refcontent> </reference> --> <reference anchor="UNISIG-Subset-137">target="https://www.era.europa.eu/sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf"> <front><title>Subset-137; ERTMS/ETCS<title>ERTMS/ETCS On-line Key ManagementFFFIS; V1.0.0</title> <author >FFFIS</title> <author> <organization>UNISIG</organization> </author> <date year="2015" month="December"/> </front><format type="PDF" target="https://www.era.europa.eu/sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf"/> <annotation>http://www.kmc-subset137.eu/index.php/download/</annotation></reference><refcontent>Subset-137, Version 1.0.0</refcontent> </reference> <referenceanchor="OCPP" >anchor="OCPP"> <front> <title>Open Charge Point Protocol 2.0.1 (Draft)</title><author ><author> <organization>Open Charge Alliance</organization> </author> <date year="2019" month="December"/> </front> </reference><reference anchor="I-D.ietf-anima-brski-discovery"> <front> <title>Discovery for BRSKI variations</title> <author fullname="Toerless Eckert" initials="T. T." surname="Eckert"> <organization>Futurewei USA</organization> </author> <author fullname="Esko Dijk" initials="E." surname="Dijk"> <organization>IoTconsultancy.nl</organization> </author> <date day="25" month="July" year="2024"/> <abstract> <t> This document specifies how BRSKI entities, such as registrars, proxies, pledges or others that are acting as responders, can be discovered and selected by BRSKI entities acting<!-- [I-D.ietf-anima-brski-discovery] IESG State: I-D Exists asinitiators. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-discovery-04"/> </reference>of 10/28/2024 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-anima-brski-discovery.xml"/> </references> </references> <?line 1287?> <sectionanchor="app-examples"><name>Applicationanchor="app-examples"> <name>Application Examples</name> <t>This informative annex provides somedetaildetails about application examples.</t> <sectionanchor="rolling-stock"><name>Rollinganchor="rolling-stock"> <name>Rolling Stock</name> <t>Rolling stock or railroad cars contain a variety of sensors, actuators, andcontrollers, whichcontrollers. These communicate within the railroad car but also exchange information between railroadcarscars, forming atrain,train with track-sideequipment,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 railroadcar,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>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 theSubset-137 specifyingSubset-137, which specifies the ETRAM/ETCS online key management for train control systems <xref target="UNISIG-Subset-137"/>.</t> </section> <sectionanchor="building-automation"><name>Buildinganchor="building-automation"> <name>Building Automation</name> <t>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 asituationsituation, 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>The collected data may be provided by a domain registrar already existing in the local network. In thiscasecase, 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> <sectionanchor="substation-automation"><name>Substationanchor="substation-automation"> <name>Substation Automation</name> <t>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"/> requires inspection of protocols at the boundary of a security perimeter(the substation in(in thiscase).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"/> specifiesfor the infrastructure sidemandatory support of two enrollmentprotocols:protocols for the infrastructure side, SCEP <xref target="RFC8894"/> and EST <xref target="RFC7030"/>, while anIntelligent Electronic DeviceIED may support only one of them.</t> </section> <sectionanchor="electric-vehicle-charging-infrastructure"><name>Electricanchor="electric-vehicle-charging-infrastructure"> <name>Electric Vehicle Charging Infrastructure</name> <t>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"/>) as well as between the charging point and the charging point operator(e.g.(e.g., OCPP <xref target="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, amongothers,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> <sectionanchor="infrastructure-isolation"><name>Infrastructureanchor="infrastructure-isolation"> <name>Infrastructure Isolation Policy</name> <t>This refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. In such a case, limited access to external PKI services will be allowed in carefully controlled short periods oftime, for exampletime (for example, when a batch of new devices isdeployed,deployed) and forbidden or prevented at other times.</t> </section> <sectionanchor="sites-with-insufficient-level-of-operational-security"><name>Sitesanchor="sites-with-insufficient-level-of-operational-security"> <name>Sites with InsufficientLevelLevels of Operational Security</name> <t>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.EspeciallyIn 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 domaincan notcannot 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="app_history"><name>History of Changes TBD RFC Editor: please delete</name> <t>List of reviewers:</t> <t><list style="symbols"> <t>Toerless Eckert (document shepherd)</t> <t>Barry Leiba (SECdir)</t> <t>Mahesh Jethanandani (IETF area director)</t> <t>Meral Shirazipour (Gen-ART reviewer)</t> <t>Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Danyliw, and Éric Vyncke (IESG reviewers)</t> <t>Michael Richardson (ANIMA design team)</t> <t>Rajeev Ranjan, Rufus Buschart, Szofia Fazekas-Zisch, etc. (Siemens)</t> <t>Reshad Rahman (YANGDOCTORS reviewer). Note that <eref target="https://datatracker.ietf.org/doc/review-ietf-anima-brski-async-enroll-03-yangdoctors-early-rahman-2021-08-15/">YANGDOCTORS Early review of 2021-08-15</eref> referred to the PRM aspect of <eref target="https://datatracker.ietf.org/doc/draft-ietf-anima-brski-async-enroll/03/">draft-ietf-anima-brski-async-enroll-03</eref>. This has been carved out of the draft to a different one and thus is no more applicable here.</t> </list></t> <t>IETF draft ae-12 -> ae-13:</t> <t><list style="symbols"> <t>Due to IANA requirement, shorten service name <spanx style="verb">"brski-registrar-cmp"</spanx> to <spanx style="verb">"brski-reg-cmp"</spanx><br /> and change contact for service name registration from IESG to IETF</t> <t>Address Deb Cooley's DISCUSS by adding an item to the requirements list <xref target="brski-cmp-instance"/> making the source of the initial trust anchor explicit. <br /> Including the vouchers in <xref target="enrollfigure"/> would not fit because the figure has a different scope (namely, certificate enrollment) and would get overloaded.</t> <t>Address Gunter Van de Velde's comments by taking over essentially all his rewrites of text to help the structure and simplify reading the content, while keeping the original message, as it helps improve document quality</t> <t>Address John Scudder's comments by tweaking <xref target="terminology"/>, fully alphabetizing terms</t> <t>Address Murray Kucherawy's comment by adapting terminology entries, leaving out 'communication' from 'asynchronous communication' and 'synchronous communication'</t> <t>Address Roman Danyliw's comments by updating reference<br /> I-D.eckert-anima-brski-discovery to I-D.ietf-anima-brski-discovery<br /> and adding <xref target="priv-consider"/>, which refers to the BRSKI privacy considerations.</t> <t>Address Éric Vyncke's comment by replacing 'production' by 'manufacturing'</t> </list></t> <t>IETF draft ae-11 -> ae-12:</t> <t><list style="symbols"> <t>Fix minor issues introduced during authors' response to the AD review,<br /> including nits spotted in the Gen-ART review by Meral Shirazipour</t> </list></t> <t>IETF draft ae-10 -> ae-11:</t> <t><list style="symbols"> <t>In response to AD review by Mahesh Jethanandani, <list style="symbols"> <t>replace most occurrences of 'Note:' by 'Note that' or the like</t> <t>move 2nd paragraph of abstract to the introduction</t> <t>remove section 1.2 and merge its first paragraph with the preceding section</t> <t>reconsider normative language, replacing one 'may' by '<bcp14>MAY</bcp14>' in section 4.1</t> <t>fix several ambiguities and hard-to-read sentences by re-phrasing them</t> <t>make wording more consistent, in particular: 'certification request'</t> <t>fix a number of (mostly grammar) nits</t> </list></t> <t>Improve item on limitations of PKCS#10 regarding keys that cannot sign</t> </list></t> <t>IETF draft ae-09 -> ae-10:</t> <t><list style="symbols"> <t>Add reference to RFC 8633 at first occurrence of 'voucher' (fixes #37)</t> <t>Update reference of CoAP Transfer for CMP from I-D to RFC 9482</t> <t>Move RFC 4210 and RFC 9480 references from normative to informative</t> <t>Fix <spanx style="verb">p10</spanx> vs. <spanx style="verb">pkcs10</spanx> entry in list of example endpoints in <xref target="addressing"/></t> <t>Minor fix in <xref target="uc1figure"/> and few text tweaks due to Siemens-internal review</t> <t>Extend the list of reviewers and acknowledgments by two Siemens colleagues</t> </list></t> <t>IETF draft ae-08 -> ae-09:</t> <t><list style="symbols"> <t>In response to review by Toerless, <list style="symbols"> <t>tweak abstract to make meaning of 'alternative enrollment' more clear</t> <t>expand on first use not "well-known" abbreviations, such as 'EST',<br /> adding also a references on their first use</t> <t>add summary and reason for choosing CMP at end of <xref target="solutions-PoI"/></t> <t>remove paragraph on optimistic discovery in controlled environments</t> <t>mention role of reviewers also in acknowledgments section</t> </list></t> <t>A couple of grammar and spelling fixes</t> </list></t> <t>IETF draft ae-07 -> ae-08:</t> <t><list style="symbols"> <t>Update references to service names in <xref target="brski-cmp-instance"/></t> </list></t> <t>IETF draft ae-06 -> ae-07:</t> <t><list style="symbols"> <t>Update subsections on discovery according to discussion in the design team</t> <t>In <xref target="brski-cmp-instance"/>, replace 'mandatory' by '<bcp14>REQUIRED</bcp14>' regarding adherence to LCMPP,<br /> in response to SECDIR Last Call Review of ae-06 by Barry Leiba</t> </list></t> <t>IETF draft ae-05 -> ae-06:</t> <t><list style="symbols"> <t>Extend section on discovery according to discussion in the design team</t> <t>Make explicit that MASA voucher status telemetry is as in BRSKI</t> <t>Add note that on delegation, RA may need info on pledge authorization</t> </list></t> <t>IETF draft ae-04 -> ae-05:</t> <t><list style="symbols"> <t>Remove entries from the terminology section that should be clear from BRSKI</t> <t>Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by RA/CA</t> <t>Add the abbreviation 'LCMPP' for Lightweight CMP Profile to the terminology section</t> <t>State clearly in <xref target="brski-cmp-instance"/> that LCMPP is mandatory when using CMP</t> <t>Change URL of BRSKI-AE-overview graphics to slide on IETF 116 meeting material</t> </list></t> <t>IETF draft ae-03 -> ae-04:</t> <t><list style="symbols"> <t>In response to SECDIR Early Review of ae-03 by Barry Leiba, <list style="symbols"> <t>replace 'end-to-end security' by the more clear 'end-to-end authentication'</t> <t>restrict the meaning of the abbreviation 'AE' to 'Alternative Enrollment'</t> <t>replace '<bcp14>MAY</bcp14>' by 'may' in requirement on delegated registrar actions</t> <t>re-phrase requirement on certification request exchange, avoiding MANDATORY</t> <t>mention that further protocol names need be put in Well-Known URIs registry</t> <t>explain consequence of using non-standard endpoints, not following <bcp14>SHOULD</bcp14></t> <t>remove requirement that 'caPubs' field in CMP responses <bcp14>SHOULD NOT</bcp14> be used</t> <t>add paragraph in security considerations on additional use of TLS for CMP</t> </list></t> <t>In response to further internal reviews and suggestions for generalization, <list style="symbols"> <t>significantly cut down the introduction because the original motivations and most explanations are no more needed and would just make it lengthy to read</t> <t>sort out asynchronous vs. offline transfer, off-site vs. backend components</t> <t>improve description of CSRs and proof of possession vs. proof of origin</t> <t>clarify that the channel between pledge and registrar is not restricted to TLS, but in connection with constrained BRSKI may also be DTLS. Also move the references to Constrained BRSKI and CoAPS to better contexts.</t> <t>clarify that the registrar must not be circumvented in the decision to grant and LDevID, and give hints and recommendations how to make sure this</t> <t>clarify that the cert enrollment phase may involve additional messages and that BRSKI-AE replaces <xref section="5.9" sectionFormat="comma" target="RFC8995"/> (except Section 5.9.4)<!-- clarify that messages of the cert enrollment phase are RECOMMENDED to be transmitted on the existing channel between the pledge and the registrar--></t> <t>the certificate enrollment protocol needs to support transport over (D)TLS only as far as its messages are transported between pledge and registrar.</t> <t>the certificate enrollment protocol chosen between pledge and registrar needs to be used also for the upstream enrollment exchange with the PKI only if end-to-end authentication shall be achieved across the registrar to the PKI.</t> <t>add that with CMP, further trust anchors <bcp14>SHOULD</bcp14> be transported via <spanx style="verb">caPubs</spanx></t> <t>remove the former Appendix A: "Using EST for Certificate Enrollment", moving relevant points to the list of scenarios in <xref target="sup-env"/>: "Supported Scenarios",</t> <t>streamline the item on EST in <xref target="solutions-PoI"/>: "Solution Options for Proof of Identity",</t> <t>various minor editorial improvements like making the wording more consistent</t> </list></t> </list></t> <t>IETF draft ae-02 -> ae-03:</t> <t><list style="symbols"> <t>In response to review by Toerless Eckert, <list style="symbols"> <t>many editorial improvements and clarifications as suggested, such as the comparison to plain BRSKI, the description of offline vs. synchronous message transfer and enrollment, and better differentiation of RA flavors.</t> <t>clarify that for transporting certificate enrollment messages between pledge and registrar, the TLS channel established between these two (via the join proxy) is used and the enrollment protocol <bcp14>MUST</bcp14> support this.</t> <t>clarify that the enrollment protocol chosen between pledge and registrar <bcp14>MUST</bcp14> also be used for the upstream enrollment exchange with the PKI.</t> <t>extend the description and requirements on how during the certificate enrollment phase the registrar <bcp14>MAY</bcp14> handle requests by the pledge itself and otherwise <bcp14>MUST</bcp14> forward them to the PKI and forward responses to the pledge.</t> </list></t> <t>Change "The registrar <bcp14>MAY</bcp14> offer different enrollment protocols" to "The registrar <bcp14>MUST</bcp14> support at least one certificate enrollment protocol ..."</t> <t>In response to review by Michael Richardson, <list style="symbols"> <t>slightly improve the structuring of the Message Exchange <xref target="message_ex"/> and add some detail on the request/response exchanges for the enrollment phase</t> <t>merge the 'Enhancements to the Addressing Scheme' <xref target="addressing"/> with the subsequent one: 'Domain Registrar Support of Alternative Enrollment Protocols'</t> <t>add reference to SZTP (RFC 8572)</t> <t>extend venue information</t> <t>convert output of ASCII-art figures to SVG format</t> <t>various small other text improvements as suggested/provided</t> </list></t> <t>Remove the tentative informative application to EST-fullCMC</t> <t>Move Eliot Lear from co-author to contributor, add Eliot to the acknowledgments</t> <t>Add explanations for terms such as 'target domain' and 'caPubs'</t> <t>Fix minor editorial issues and update some external references</t> </list></t> <t>IETF draft ae-01 -> ae-02:</t> <t><list style="symbols"> <t>Architecture: clarify registrar role including RA/LRA/enrollment proxy</t> <t>CMP: add reference to CoAP Transport for CMPV2 and Constrained BRSKI</t> <t>Include venue information</t> </list></t> <t>From IETF draft 05 -> IETF draft ae-01:</t> <t><list style="symbols"> <t>Renamed the repo and files from 'anima-brski-async-enroll' to 'anima-brski-ae'</t> <t>Added graphics for abstract protocol overview as suggested by Toerless Eckert</t> <t>Balanced (sub-)sections and their headers</t> <t>Added details on CMP instance, now called BRSKI-CMP</t> </list></t> <t>From IETF draft 04 -> IETF draft 05:</t> <t><list style="symbols"> <t>David von Oheimb became the editor.</t> <t>Streamline wording, consolidate terminology, improve grammar, etc.</t> <t>Shift the emphasis towards supporting alternative enrollment protocols.</t> <t>Update the title accordingly - preliminary change to be approved.</t> <t>Move comments on EST and detailed application examples to informative annex.</t> <t>Move the remaining text of section 3 as two new sub-sections of section 1.</t> </list></t> <t>From IETF draft 03 -> IETF draft 04:</t> <t><list style="symbols"> <t>Moved UC2-related parts defining the pledge in responder mode to a separate document. This required changes and adaptations in several sections. Main changes concerned the removal of the subsection for UC2 as well as the removal of the YANG model related text as it is not applicable in UC1.</t> <t>Updated references to the Lightweight CMP Profile (LCMPP).</t> <t>Added David von Oheimb as co-author.</t> </list></t> <t>From IETF draft 02 -> IETF draft 03:</t> <t><list style="symbols"> <t>Housekeeping, deleted open issue regarding YANG voucher-request in UC2 as voucher-request was enhanced with additional leaf.</t> <t>Included open issues in YANG model in UC2 regarding assertion value agent-proximity and CSR encapsulation using SZTP sub module).</t> </list></t> <t>From IETF draft 01 -> IETF draft 02:</t> <t><list style="symbols"> <t>Defined call flow and objects for interactions in UC2. Object format based on draft for JOSE signed voucher artifacts and aligned the remaining objects with this approach in UC2 .</t> <t>Terminology change: issue #2 pledge-agent -> registrar-agent to better underline agent relation.</t> <t>Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode and pledge-responder-mode to better address the pledge operation.</t> <t>Communication approach between pledge and registrar-agent changed by removing TLS-PSK (former section TLS establishment) and associated references to other drafts in favor of relying on higher layer exchange of signed data objects. These data objects are included also in the pledge-voucher-request and lead to an extension of the YANG module for the voucher-request (issue #12).</t> <t>Details on trust relationship between registrar-agent and registrar (issue #4, #5, #9) included in UC2.</t> <t>Recommendation regarding short-lived certificates for registrar-agent authentication towards registrar (issue #7) in the security considerations.</t> <t>Introduction of reference to agent signing certificate using SKID in agent signed data (issue #11).</t> <t>Enhanced objects in exchanges between pledge and registrar-agent to allow the registrar to verify agent-proximity to the pledge (issue #1) in UC2.</t> <t>Details on trust relationship between registrar-agent and pledge (issue #5) included in UC2.</t> <t>Split of use case 2 call flow into sub sections in UC2.</t> </list></t> <t>From IETF draft 00 -> IETF draft 01:</t> <t><list style="symbols"> <t>Update of scope in <xref target="sup-env"/> to include in which the pledge acts as a server. This is one main motivation for use case 2.</t> <t>Rework of use case 2 to consider the transport between the pledge and the pledge-agent. Addressed is the TLS channel establishment between the pledge-agent and the pledge as well as the endpoint definition on the pledge.</t> <t>First description of exchanged object types (needs more work)</t> <t>Clarification in discovery options for enrollment endpoints at the domain registrar based on well-known endpoints in <xref target="addressing"/> do not result in additional /.well-known URIs. Update of the illustrative example. Note that the change to /brski for the voucher-related endpoints has been taken over in the BRSKI main document.</t> <t>Updated references.</t> <t>Included Thomas Werner as additional author for the document.</t> </list></t> <t>From individual version 03 -> IETF draft 00:</t> <t><list style="symbols"> <t>Inclusion of discovery options of enrollment endpoints at the domain registrar based on well-known endpoints in <xref target="addressing"/> as replacement of section 5.1.3 in the individual draft. This is intended to support both use cases in the document. An illustrative example is provided.</t> <t>Missing details provided for the description and call flow in pledge-agent use case UC2, e.g. to accommodate distribution of CA certificates.</t> <t>Updated CMP example in <xref target="exist_prot"/> to use Lightweight CMP instead of CMP, as the draft already provides the necessary /.well-known endpoints.</t> <t>Requirements discussion moved to separate section in <xref target="req-sol"/>. Shortened description of proof-of-identity binding and mapping to existing protocols.</t> <t>Removal of copied call flows for voucher exchange and registrar discovery flow from <xref target="RFC8995"/> in <xref target="uc1"/> to avoid doubling or text or inconsistencies.</t> <t>Reworked abstract and introduction to be more crisp regarding the targeted solution. Several structural changes in the document to have a better distinction between requirements, use case description, and solution description as separate sections. History moved to appendix.</t> </list></t> <t>From individual version 02 -> 03:</t> <t><list style="symbols"> <t>Update of terminology from self-contained to authenticated self-contained object to be consistent in the wording and to underline the protection of the object with an existing credential. Note that the naming of this object may be discussed. An alternative name may be attestation object.</t> <t>Simplification of the architecture approach for the initial use case having an off-site PKI.</t> <t>Introduction of a new use case utilizing authenticated self-contain objects to onboard a pledge using a commissioning tool containing a pledge-agent. This requires additional changes in the BRSKI call flow sequence and led to changes in the introduction, the application example,and also in the related BRSKI-AE call flow.</t> <t>Update of provided examples of the addressing approach used in BRSKI to allow for support of multiple enrollment protocols in <xref target="addressing"/>.</t> </list></t> <t>From individual version 01 -> 02:</t> <t><list style="symbols"> <t>Update of introduction text to clearly relate to the usage of IDevID and LDevID.</t> <t>Definition of the addressing approach used in BRSKI to allow for support of multiple enrollment protocols in <xref target="addressing"/>. This section also contains a first discussion of an optional discovery mechanism to address situations in which the registrar supports more than one enrollment approach. Discovery should avoid that the pledge performs a trial and error of enrollment protocols.</t> <t>Update of description of architecture elements and changes to BRSKI in <xref target="architecture"/>.</t> <t>Enhanced consideration of existing enrollment protocols in the context of mapping the requirements to existing solutions in <xref target="req-sol"/> and in <xref target="exist_prot"/>.</t> </list></t> <t>From individual version 00 -> 01:</t> <t><list style="symbols"> <t>Update of examples, specifically for building automation as well as two new application use cases in <xref target="app-examples"/>.</t> <t>Deletion of asynchronous interaction with MASA to not complicate the use case. Note that the voucher exchange can already be handled in an asynchronous manner and is therefore not considered further. This resulted in removal of the alternative path the MASA in Figure 1 and the associated description in <xref target="architecture"/>.</t> <t>Enhancement of description of architecture elements and changes to BRSKI in <xref target="architecture"/>.</t> <t>Consideration of existing enrollment protocols in the context of mapping the requirements to existing solutions in <xref target="req-sol"/>.</t> <t>New section starting <xref target="exist_prot"/> with the mapping to existing enrollment protocols by collecting boundary conditions.</t> </list></t>--> <!-- Local IspellDict: american LocalWords: bcp uc prot vexchange enrollfigure req eo selander coap br iana tcp LocalWords: oscore fullcmc simpleenroll tls env brski UC seriesinfo IDevID Resp LocalWords: Attrib lt docname ipr toc anima async wg symrefs ann ae pkcs cert LocalWords: sortrefs iprnotified Instantiation caPubs raVerified repo reqs Conf LocalWords: IDentity IDentifier coaps aasvg acp cms json pkixcmp kp DOI abbrev LocalWords: PoP PoI anufacturer uthorized igning uthority SECDIR nbsp passphrase LocalWords: ietf cmp lcmpp submissionType kw std org uri cmpv app sol est Certs LocalWords: github eckert lternative nrollment sec certs reg priv pledge's CMP's LocalWords: Mahesh Jethanandani Gen ART Meral Shirazipour Deb Cooley's LocalWords: Gunter Van de Velde's Scudder's Kucherawy's Danyliw's Eacute Vyncke's --> <section anchor="acknowledgments" numbered="false"> <name>Acknowledgments</name> <t>We thank <contact fullname="Eliot Lear"/> for his contributions as a co-author at an earlier draft stage.</t> <t>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>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"> <name>Contributors</name> <contact initials="E." surname="Lear" fullname="Eliot Lear"> <organization>Cisco Systems</organization> <address> <postal> <street>Richtistrasse 7</street> <city>Wallisellen</city><code>CH-8304</code><code>8304</code> <country>Switzerland</country> </postal> <phone>+41 44 878 9200</phone> <email>lear@cisco.com</email> </address> </contact> </section> </back> <!--##markdown-source: H4sIANNj6WYAA82963bcVpIm+h9PgZHWGpKqzORFF0ssj6dpkrJZpdshZXuq a9XYYCZIopQJZANIUixZ51nOs5wnO3HfsQEkRbvq9LRWd1nKTGzsS+y4fhEx Ho+TpC3aeb6fbnx7evbnk/HB8X56MG/zusza4jpPj8u6ms8Xedmm7+qqrabV vEmLMqVfbyTZ+XmdX++n+nAyq6ZltoDxZnV20Y6LvL0YZ2WxyMbndfOhGGf5 ePdx0rRZOfs5m1cl/LKtV3lSLGv6W9Pu7ey82NlLmtX5omiaoirf3y7hVyfH 718mWZ1n++nbZV7D7KqySWGY9HVWZpc5TjG5uYTZvzl5fZD+9F3y4QaeKnEp eTs+wukk06zdT5t2lkzh4bxsVo28fpa18I69nb0nybLYT9IUVgp7cps3G/CP abVYZtM2fNDcLur8onEfVHUbfwILKqu2uCjyGXxYVvSrti7CMNmqvarq/WQM +wkPHk3S66r87+V5s/zj26u8WJzDE7yXR9l1MRv4Fo4Gvs1nRVvV8M+qhuWf FbgVTXrwHXyixyMf8hTyHKbwtm2r8ffZVTk+LcrL9Bmusmhv99PXq7KYXtGi Z0gWz3e/evyCN2FVtjX84ru8XmTlLXyUL7JiDkeN05vA9CYVzezfGn7dBPYN frWqi/30qm2Xzf729s3NzcR9va2rP5ukL+sib2zNZ21+cZGX9un/qcU1PI/J Bc7j96zs+0n6bV1NP1xlq7C67/NyVhcfom/+T63wiucyOde5/KZVwk0Cqj5f tUjKurzjeVG16as8M7I8LJpplZ7dwnYu/EJOYbZtAf/KmiZPv7J1/JTN50WT z+d5aYs5/H78/PHOE7+Ys5ui/Udez4EPwMfLK2IoD/7wZDd98iR9/tXz9AWw kwdhrXOY0r9NcS60uOu8XOU47cu6Wi33U+JU8E/+Mf3r35CFTWAN+KuivVqd yxfjm8vtmLMlZQVbi2wThzx9efh07/mO/PX5ixdP5a8vnjx/jH89OT4+/vn5 zt5k9+B0vLez+xw/BM4j/Bi/hlsAK8vqWXpR1emraprNmeXlbV0tq3kBX6cH wBTTN3l7U9UfmnRMg5zl01Wdp0f5dTHN05MZMEfY1g36TvkO/n3Mp4Pvon8r H9x9Pt55Tp80ORJ+UV5U/ATPez/1E5cvjt6e7Ke7O5Pd3Z0X2/irs/dHE/x+ 8vzJ3uOvXjzh9WX1JZ68UlSR5/nH5byq8wn+Fbd6G6TIChn6tj6I73d7ezI+ mjjRgtwcKKgo89n4ulpNr3JangqlcXWd19dFfhNvsH5tgi19K78b2ifhShNm wcqV8Jv13Fv383VWT69QujymD3kpup3vjl6GzYDfZ7CS6Ye8nijhbS/gpsAt 397dfbYND8KBZPNmu5kXs7wZw4eyC6slvm1clUHUZkGSj3OT5OOlSvJxoT/e 2eE1lyVwiDpbXhXTJq3KlN6SPkmri7S9yuHaZu2qSflV+D1+aBtJMj/deZJm LcnrFCY3YaLfe/H8mdD/k73dnfDXXbsrX+3pX589tb++2Hshf3324qneoK92 Htu9evxMx33+/MWTcNv0ry92nzwPF28n/HWP7+Dh+Nne46e74xfd23eY0hdy oeCcqpu8BslPHAw4hCoddCGBe1XTAvZklhqpwu7kH6dXWXmZ2yBHcL70AHCf BbJq0WMavK9wQ8PbsrpNXwDPuz3Ht+rXH/Jb/2rkCks3rzT/j1WxxK/WX/VS SKIqgZkcz/MpsJI2n17hZObpIcyL1a6YH3w13nm6lh8cwobJLqb44jfHp4fj w5N3QFVPx0+jjeX1nNlydQbw9vDpO3jHIod5rlvEG1C3rtKDBfxuChzwNJ8X 2Xkxx2cPQTRMi3k8+8fj3b01s4dp7qc0TySHs7djJIndp7vAAfc6JHH2dhvJ Qr5MT6sMlLIcbspceAHO70f+YAzy+bsatLZDf9C8+xfZNLff00Hv7SsDZ2pa Luf6hN7VtMazrencm7WnuxEfr4qP4h882Nv6EniF/GNb5pDenyY24m19Mt55 so4oeLNgRrpd+OwPb07OTr4bn63OG9DJdx9/tb9uIfzLaP/DU39Mj0/fvz7b Pn5/eJa+Lcdz4Pzpn+FqBFMgffny5cnZH9Mfdyc7kx0/76N8mi+QCGEBT7/E j1HdAWNjkq9A3uJ/tpuizZvtWX6Rrebt9kUBZ8//SxdwO6/bRbM9nTY/t03x M7DT/OPP2c/jnxd4EKAj3f7cLPMpmAVy87dhST9XF51Pf378c97CGOePf673 fr5sFuP65/Pd7aKc5R93nj+G8RrbjJ+vd3d2JsvZRWDgOHuZ/IfFdMy/hZ/i /GmMyfJqCUL2ppwDDSMdvD189y6idrCxyvTwCmU1cL7CmX/pHuzobrpJFtXW uvPzzx+AKpeVQvNGPC/4TnZEOUujGWpoIIxv95NkPB6DIozyfdomyfuroklV PUjhGODomzQvr/AFdDfAdGOpVFUtPrVcooZ8mi+AolUvAlpJTsoLUDrB+pu2 +NEmSbEtu2+j9EMJGwScPci3zWHLeGvy9Xn9TWI/yz+2oFLLczidZrVcAsdK p0AdfMh5GsRxushRShQNKMagS7Q5sBURt1VdXBZwJ+e3qRAICJgVKMrwPWhX k+Sk1cGbdaObsB/BT0ENgQUdvn43StorkNI4Fp4e6odTEl+gc1+gQtWSOpU2 xSX+pzr/OzCFhgROeA9ykUXeNHDnmlEC06xucK/xRxfz/GMhLLko01K424wV 0qo8r5AtwY+baV5mdVE1vInvr/L4NLPZrIZX0EynWQOHfQPqXU7bA69oUDMa 3Mxkkd2mYIKn53l6kWdNcT7HDU2rZQuEBucLGwN2Kz6epUAKixxnmODkgdzz S3Qx4PxWoGTjo06XGtxenb+nT9DTKlGWmqAqASu/gCXAElNUDIGhEAkmQCnZ FBWDirQr+H0TvxZk4lU1g61G10VNs2N6RqHRAKumic5y0KZv+f3TuoK9y9Ka tBCgGj2IvLwuQOrSHk/4ki2K2WyeJ0nyEAVCXc3gZqAewISdfvokZsznzyms sb1donAAyoSTmaVgh115ZxHeXr1t7+HtDdJosglEO+KRUIf7/HkLyZGOsr+j dBQV+XqqeqwMUknIUTtQdr7ANeOOfP/+/Tt++/tXZ0SKskdCqGmLs4H9n4QL W+AWXQMVZiVeCSKJL5w2LTi58+r4O4NL7E/cjTxJvv5v4zGTj6N/PDLefvgc TZCZcaORXASYP7nT6EXJo0cHjx65uT96dPzokXvL5s1VMY8YS9GmN1nDp4gU SD4HVGVTGqu5LadXQCkVqP3xYFtANd8IRwYuW1cZcJfqArYW9Vk4AVAdZnRB p0CJs2vYXGQUxLSIV4StcfuIPCXifvgv1H3ypmV/H7CDJbrvkFsCrQOrhUdh IfC77hk71jrhiU6zpWqKoIbhX+huwiCoseWofEVzSTaLST4Z+R/ASuFV+H80 vy29ZQtQCIrlXN5ODP+qWjYJXU5l0rRav6eVOjNxxDW0ARoYrBe2ANeJnBsW wtwLpu5YCGx4h+/OUIteFCWSNL56XskW46SAD8LniR4CTh/Ny+5pZLIpsNx/ DMwUP9DzGSVMXsafSMjg4MxScVaZ32P8QE474uEsU5ICDa1CLxTxmIvVfJ5O 69tlW12ynUq+pPKyvZoIMUa6FJx4jcop8wR8EY6YAlmgQgF6KxAomrpyz0Z0 y+aoeDxKURjBgc6AopDGm2a14EtylcHVqkGRhCsGFh+c60lZtGCWm8flCJcH 4rpONuHv1ydHyPZ6Hh9kgNM6J/cMyIp0xruGA4LCuAIKbekTujOrhoXIgq6p 4zz4e2A9ovgkr+1JWPCBHBxM8wxEOY4uH8HOb74+ODsYec6+NSJyFRWqzi/J NVcjryngdhdCwNMpiuQl6YVyfOzWAdGH22ujLOFigOCFy7YCiw3mg670qiTJ Lg/yE8LMkBkVcMAgs/li5LNJ5yQuirqBt54jUTQpcCoaRdw+spbHz56BlDLr O+PIApDeFFZOBO9pnBQI0HuRSorST0oVJveR7Ul3XjieTQtOJCF3HWpuuO9I jrBZPfJIv0AewLbwLEgqzEY0EXnfZV7SBqHsWtbFNRLCh/x2lOJb4bhf0bgo /eq85QMxNqq71l0T6EHVgr55ByIHDggpscxv5IdJJn+5Sxp3J+C+miRvaU+R ekZ41nKFeIP7v08xQnTJ977oaLhwtEUJZ0AaI4taGkkvMsr1DPXESuWpCNLz W/gAFCU89v4rE8eGWuDRq8srZo6sdGdlpBmYcQ5vAdWG2B1xjjPl92sFC/Oj NTKDaOulk08dHcYomwbJyltUx2iCfck3wmBUOZ2vWNX1smeWzwu0suB1qH2M SV2uc6RadHLPYBJkYbGO7Hf/Jivo3oAE9mIC3jjDjR2ZZEeV3aQAeu5pENLU jBUgW9kE4xmWDzrY/HaL5pFdZwUptBPWM4ADokaPnAHM2RoZr0kXPlnlAbY7 56Ds5nnpbs0ocTyNPOnAAWEV19VcyVBP+h6qHYk7ZIslMi9SQpDhIW9k5R3o Y4kLRq2HTRu1WG7y+XzMFuYPpydpsENJD8Pd4zXhHJGyvEhk+xJ+do4ynjV1 OqISraVC3DjLDG5NPufAKO2UmpBrNW7YMGKGpEwT5x2Qp6K6RfIB6Z80v0DQ gxZoYjePj4MVOhiqqJGT5HPcLrLgYcNhh1leV8i6UcEENsdu5zw5z3CfxAHN boAZ3QaYXtBGSfVSVgV7RhILzyIQU4Fk1yJvhreWVSvUyru/CcIkRcm41dk8 JpIkMjZG6fmqZTNCnLpqbofwBI+bAK//YgQDBBhTF8n9w+pA3nSEr8JIuApX VCiJniaghbCsQEoFKhklGzjDDdqHDXhug1gikRg8Y2ao+Uxoq8kCLXFjmHho Nah1EjMUM6kRO4nmBcNvVzwzegE+ip4KlunizYSJwrRFlopZwDF8+A1eeLop xA/wsUHiAwFYgZaBl9yEgq1iZnY3Chfc/gt4riBOXiXqg+GDpadxJoeOqTnv oTm7NtFXwloFhg9AIuMagLzQ5zdTdeFVcXkFrAb/F50r+Dh+n26+gn+55x+T RD9x7gU3Hbi+Q3cSXfwyXEUrB/osUxo4IV2pzFGekqDw9//k4M2B3VDa6REe OlgEWZi6c1ZMkpesoy2qGoS4Gyn2TerFEX/0zNm3OHKTiF43sABVIy/wklar tsHYEoWVppWIr3hGSfLwocpS1GDVV5R+egjnCVL1+nMSmfFgELHDCieFlxSV OHvKq3MXlbirSF6/C+xoW5YTKbTpnAxa1CVLY+Imztb63PyJkevDeeBMf/Te frm4MECOEjsWSTBCknZccNFrZyvSd1D5r2pbLiwQ3bL4qlNHDt4OOD3YIgdD hbd/TEai2lsRn0dMguiRcPR3ajdmtANDRxWETx5F2azK+VV6Je/WhGzuB0hJ h5Hd6ZZwCEtQZ1HK3naKymSg97ADr2O300b666/20alqyZuHZ6fNlhAtHnZW ij9RjG+SwMT0UOMHaUReCHKA0CqI9zTVqp52jWpelns7s0HdMqZfDPahXuc8 txjkOC6n2bJZzdk/kaavVdNLN/98/HoLH2tGLMVmVbTRjawQ/WpImIjDgH/P 83FzVbW8QWP4P1Fi2L3LLke+NlWD17yZ1sU5cxBibBiZ/fwZl0Q0ziddg26Z UwgZdxF/++7Ph2fpw90dfggDwiDiOPYyCkThPKAwIKtRthGw99OMrnXr2V5z 19RpFNgLsSeJqmE2mSxdNStxp2VNoJMwllw72F7a3XABQCOBz8mMWZIpjK7k vLlC8wSxK8AwrrP5Kg9krP6ESLqKyuXiwPPiHJVhYgD9g2ROwCwO7T+kQX4C nsymH9hxzb9V9vygnTfjVVkAhT3gSfFBYIj98+f4itr69OEGQ7SX6Tnq+0hA F+vImgwXdNHAdb1YsYjP2BvVxGo9kMYYg2l6IANOhFRC5WVJ1h2Ogq4P5C4X /Cy8RfW4kjxdbUte05oseqBBupAYH8QTQCNHRTZcnxb9EWifZGZYNcA9ctDJ ZmNY+Q0Cb8yOogXkOdz6SUoGySNjP2wMZqLPAE/IyNFGmyAWSlCVSUEqg3Ii tIV+rVvhrhjNxn+I7yboy2vdbikQa8teJHhQ5EBGtEBUyQ4b1HDp1iCdINQk JdxgUWYzGAkvh9HfAm4CmCOO9aj7cE6blHE4wTkeGtvhl+hZ7rgMyTtCsr3M eYdOUTtpOAAjZ3KOwJdS9zcO4MkxM/iBeA9qomjF3mS3KPjREUy0yWN5qcr0 NAG1Gz4d5x8zvHwNcB9zooIetWLBiP5++UFC3pBZcUEKZovGLv4I3XyEegP5 rrALF02hMzSvrvwWZHrDRtiiannL6FqpBLz4cngJ4zLvyZlbzatL8aOqs54I 79PDNnz/mQ1OZJ03VT1r0gevfzh7/2DE/03fvKW/nx7/Xz+cnB4f4d/Pvj94 9cr+ksgvzr5/+8Oro/C38OTh29evj98c8cPwaRp9lDx4ffCXB2xkP3j77v3J 2zcHrx70tE710egNBsWnJeskieTMt4fv/t//Z/cJcKz/hrJjdxdYlvzj+e5X T8hWykt+G4lh/ifs8W0CZ55nGNRD0xUDAHBh5yzRQOyBAS7mxqO/4s78bT/9 +ny63H3yjXyAC44+1D2LPqQ963/Se5g3ceCjgdfYbkafd3Y6nu/BX6J/6767 D7/+n4SWGO8+/5/fJN14ehDaxI0dtamJrTKf3cVi2SDOEUUI7v6gG3OULrMa 3SM1XFPSLXnPDzA+qrEidRHja1kdCiSgFqEQioV9zPvspkpS2Fn9vbs0IhJM bNWrtpgX/4B1k0sVnvGjAeOWSDW6RB32yq44Xk3vVttP9jG0ko9vikaoul4t cdHqb3OhqmZEYeOUVmgOq0z5PTkwqoWxRmU4m/nkcoLkDmx0C17fMgbXNEic g8o0+YhdbmXL9jDvI9kYZsUOCpd4cI68+dFDFJ24btkgGk3cCb1pJfeJmOLo GYun4BYj3omeDR/5IWF3Xq1CxKIQpCs6Z1JyD0ikE60CFDslTiqbXuFpwBct ijPQijN6iYoOeCV8zrNB2SohYS/tOggNHN4LyhPvfAf6kOPDpS1BKFtsVx3q zhna5HBX4C0YNFFvfNdP/0fCKLMzVLQo1OlFKxKTGF/2BRBM2gHBuKsd7Goa J7gp7o4wjzSSrlZgDzxACofomvwKshrWuyT5SrgLEYemcDzUyGlfZ+zeH4jX swdU5O36cG+qB6tRHaar04OgCHWdPZtNnrM/ZgtO+vCA7lHzhZsoP1PrL3ru /pcsS7uvS5IoSFKVF0W98EMhgpcGqrzKRczN3OlmuTOJ+vCIBT3xdxgZisI1 uJ+gahKzK6K5OI6yZkc6AQYkNbPE9Fr3R/wte7WGv8HJ4fNf8gQSCSN2mTQP 8wfC82en3ec7roQkARLH33wJIOOhMUnCTASfWxtd5gOS2EbkluBId4gEmzG1 AC42wM/CxZoTa/5fk6c7L/pHQmE4DL0lCZE8zm6d99N5PeHXtpj7xUXXLgxn ENmJ//qVmfG2+QrEK8ujZnVeoR6QsdVp8miOPhEKMkoEWWIodNKoyaLQFpZO DB2nmxIkkwAdMNgEEbghalm0wdRMC9wGvaTw3oKROmobqzqNZizz0Ff8ozvd eMCmMO6FC7s3WGAUjCUJUADTUomDI9GmCZ4jSDPCX9UM+qtjj0DgqOLaO8BV kY+A2RDLtYvu3NOUlFaRf3itwRYjOc5iMMNDWc30vTgonA8LHPUloHuo7zeA fRFx2l1Qdr8l4ancMfckATa7HVwBjj3DCZfVDZL7wqm1FIXvKmfG1pOE7wc+ L3F4JUtW8M5N+pOSR0wwujq4mSeth1dpSJxVHlFjPEQFEaoc35e76JkMbOAp kdWwo3lkiwq7qUdD1wKkWcAVgrYMujd69/zaffaDbD3lkwkpdXAdPswI+jp6 G4lBRL4JIObpB8rAK9c4WJIQNsbVgdkojrWuYpYkSj3mLkEKkkBYyVzCUX5g cS4uDeNGe8QaDsM60ftEfsQ4PIHETKAkc6MTTh3OY61hsiq/aJrcaZZkzqeF yvWggYK7gKwGbJRowrpDMn0i28xhrS4r0VGGqBg9Id9mDRhqpy4nQnKBWdOF J8+q+Ur9InCO46aao1Lr48a4ARRIl7mFSFHHya3Bps+Eiui6l9Rf1H0qdjaN 4rBTUkdzJ2u3Zs0qAMbvA0LAeKR+WDcEd2N4xSAlCw7BpuEgChaBsKjeGpWJ I2Z9LzlyoQUHsimgYU5HDgeSRAaSQpk8rWrW3WZOF12uzmFP5XtdJbnqB6dh kiBCI4NtV+TXzJ4y3rJg4DFXI3bqJ4DuU6cwYBh/SkifhgjQhkTvNyjACMJM Uek3lXCEmhzN7cnkMYZC/Aap8jriAQUd1YlG7dMcRMCKa5aiVMPQ2PUbohvB Tg7CLcY7MrAZcu8ioxXZIaqo5H3ACWlgBxUTOlVxH5A2o85sVOs4VMCrJgRk x6aKXcoiuBrKakzLFabmoMS2A+16KUB1QrrXMU8GUGZE4jWm/MLtri2u3MgZ XRJQLANVo4T7iRnPZMjOi6blyAYzDrvXo4A2MfwOZUepa8zdekp7NBzChAPY OuDbJTMkvFtGHu9CxOrTQ313M35XvfuMgVtvVmj8Ts6bApRbygf2OdAGlzhJ O94TimkhRJj94/PbDiRXicouHT4uGmYwpwbiYsIlNuei0ismcbblLxRpGQFm Q4E8GAam25snzJ7C1Y8Go4UTvu8kpwSlghJdBysaSUaTO8+8VJZOukqMQuYv r3O/oIrTqBzH4ugjCqjAM5oBltWlU7uUtBx/jGIVpq/FYn1JMVA4zdPXL0fG VHYJK4KToUXPkZfKopFBIUpD9ntOq+dIKu+Aog/VtUohEmRFtn4lCAHuDZyt vDsw1i4zVVMkYIPt+Jl1bKLTFwbdEuxf6vx5ZpT4XR6UCravYa95arhdzFJt vepCviMczCFNpUGMW8mBhygrKVJ610LCwAQPSlEuEf/fdfyfuD9p1aAlruYz FCAIK3NoxcFTYBpudLlNh7xgSBf7Rvw/7y3zULpFTPFi+sdb2bmMf8lb4Yh2 mBZ/FyF0hwwapZQSwQIrFnHB4lEHkk66lVjUMitqxVvO2M69EU6DJ5dfVH4y t7mcRqY2Dz6kL3NJ12LBWwgym9d5NkOKAkIMu1IStgZscXIg76sCAZ/WmWpC tyT7z5FgI8kZgSs1EC40KkIoEnOmnnR+Oxg4jxJEkrRjoMzyadHcR/pT3PSL EkfLQXTkzQnJm29ltrE7bljycDDeZGKkrSJexszGdDOgdBWbuEZ6bzE6m7A7 HR3JOA0w2FXt9iwr124Y82KYLd1K1AschuEOPUsOCx5k66tvls6CZiseQoPu DturPYJQD4ZSmeLNLQhfyenh9NDNtUJ1Zk7afUBJ2etVq0IwSMGE0kvbaR0I u0M/hML2mtwWB+uFadHViaoWID4L13TUDb0rXIePWFfrNWoamEE4pC3m5Ma3 NY19hO8GdwlMaA1iyLEIZjKwMDngwtA5C4GWSwapxAYGUkYtSMChCY8rGEUg ukcEjnE+WlHpUbXQ9EH4Bdho2bIR9+fuk+eMrklDnNF0G/IbYnGb+wDRWOr9 RAlWPCvah6uskTTXvDT8I8u0oKP3blLL6TaoBs+LRdGiHFfzhrZcFCE9vaK9 m38JZ3IUimQYqxID9khITCjspnJA18BKfawSjQZHiq4OTDfWKBm+ETMQmqvs Qz5J04PGbCC+Sex2Vjgpr48FA57rLw+2G4JlMWk8+MUQ43yzteqZ5NnP+u80 5Lz9NohzxxPGbE5M5wL/Sddspphl5p3ue+NGyoDocGko9aEoj2d3dFZ2fAk4 b56AiLs4jqoM0+kKRgkNmxBwLEUIHQtuVWbuzp4GASpG3H9zNeiOJuQU5abY WVCCR827HDRQuGu8XQ1HvuGMz+AGXeeaqdVJDHSsXrmhl0/9zQqrV7jadcEQ +xLYOswITpCwa5KBZ7yVR6PsggjY7Lx6weW3CQweFLMt8ufHyCe54j3QmBnd oKKyezdKAGQVPh/rnPJgxLiwaaXpOjmfqKzWTUevhIp79lgREA4JdlBsGHl2 Yi58UhZ18TKRNOErOe5iNv6wHE8XU9gNy2zBMVZkHBmGQOjRuG/QufcmmJPe fMjb6RXWB1BJoWx2zKYRzgIZKQ0j0oOgiuhsVZvMwqTim8YZAmNAdB5M0fEE x9NuSM+nvBhOOB/kkHKm+gIElM+FKnA/7MR8eADHVSAic2Dcobqk6BTrBYjU w7OCGSLfdtOyLBhU9BEVXguG1DlrzHdhTG1efEDoQSRVDKxKOUGUqP5GM2VG 8JOmUIPlTvEapE4CMp88vFSLQO7AweFx+tN3ROQENmJ/ucM6Cwbe5UKBgnt2 +Pb0WDVDyodgycCbA4yop0wQbNHcIVRGI96vT5+okNUE7N0M5dk4m+Yk08dA IeOqAdsqBykk6hum7sD6a86pycwGFYVAstdQeTg7PH4nSIjnLxCzZgqsAkxA itTk6EUPHNrPTbO8qkFabDFSM4307ehKBUcHmZHqsaKH6MUSa1anw1upTiBp PK/P7N7QI5ssb5893UM3RGrHTSdlN4we7s1L5BQcAL24kBydWgoMNOlGnYPZ l803/CXKbsNczQBkBK84/kwt7uka/doO7HR5/W5d2P637D3NCx1dUepHlPyh BKgqfdkX1qMu1+6M4b30lqALrOld8BEE9wkRN3wpp6n7uMY0jA0Y1jhnoo7S 6aPjidkiaZemn1IWlWbfsNR1OFV96wpuNm71v+zUDhVW+NUehlwiF0+Y9b/o uqyHVCsiXhSkvKB7DVtPnieK0sk+2cGEg+j7RmQYwzJkwYnDgggWLmKI325e Z7yd7j4ypoDdPZY51rl8ijzzJ3T4rzih93gWi3S1HMXJPFik0Hw/FtfqpNr3 gliJZtKSTxPvPpESA3l5xuL0NbQmqBkLShOGwaeU/0A79A4xwwWrFeQbFbQ2 6CIz1v5TSsPCQXFw4jP446JpVrIGy40TuOnD9GCWLVuBVwPNCJjt4Wq6+5m2 gn0VAzVjvlSMSQmaZaWi0ZKupy1K1849yg6WELmAJe7qCwoBERuoxGJLFM+R h0R5pR3s4fREKgJfHt0rDumiOt00oeTTJ43AAvGeo8tdLsOgy8StkyDFvVQS eVgj4phyk1OkiE3HGOGABfas2MTgUGRAnHNWKuua4sBW93kJ/NIyuKPiVDWq u8uW8WVYZ2WxWrBV31BFJ7oPmlEuPkmFUvuj0kTtRlA9QEiSToLponpeI7G1 vBOGI7m+utQCZstlYs3h4FUzKec0+HZ6GTKlYgo6Vx3VmygIg0ZwjGgCZs/1 ikmgEaBLacLvKOWeKg4hyhYPXxP3VVz5Kj9IuZTohVVQyLmZHvipf3roV+Ky HmRNUUGIoglKTM83tg4gSEkAyLgZP4KOC2XMPbN68GpMkjslMxve7A2LH0ed iCirm7oYZb/33QKTJCoYtN5nDGfxF1ya8neUpsLLyltXSo1TeIlzTQjO86Xy QGvfmOjdlTygdYSzzXhtRZV0UdKwRLB/8Hxh7B5Kg1bc5L7YjKKlORnMo6Un Ei12L5e0XYVW916eGNymrGgoCqlKAYvbdNNjyrZ6+Wsw9kKz2+fAEUiydDky 87IkgMVxWhHvkV2eV5dUpDMwEE1roT0BSXVRXOLNwLjU/w1/0ixrrlmBvdef P4zX/PlD0v/2qK6W47OrYhl//Gv6I5xihYBXBs7pn19xjF//BfO43xi/pq9T B1cLD/2GefyaHqQBJ5n++vYGcTew5N80xlkqLhb653su+fw75wFk5R/6/Xv6 h9+zp70///ufeJbm/uPvfFb4fGLL+AN9PrnvH6IPEE7Jr2FIGuCeE8ABBp79 QzQb+tPdd3uW6xCEZ39N/1TBPfbb+Wt6xPxI/vk1n1d479c86De/YsTv4619 QB+dGp/jKU4GJvxr9IH89WaboMVwh+F/5UGRPL9xpfEbTTZbzcbOn/9t2xsf LMmpUco4Q8Kidx78NTzY+eYLB3rHg3f/+dX+Fj2ocoRhMlt9ecJk/xv+/Obf +2367e+69w2KN0G3YpK+IxzDeCDjqPfnOv4nPf4HTz/pHaKgKxn4cccav9ZB 1lTCANr2uxYePzzQ936D/95clQTIUQNerqTdrq3w+D83+X/mTzhoVaM2FSvv 9J8BeiQ9Ifm0nz409YHrQv+PjUj31n4J6Q+kM37rcokObbCNBPYI/bxjUG8u y//xYJ5ftA9EUY+sEG3T0NNcEo0VNNliWOOR2o3oRBDPPhnHXA0Ta3+oHpX0 Y0HDSiyDwtdDwidJL+7tMcEKJR51fPqocIMZNp9jJIfK4FywsprICzezRsss Um0CjSRuES7coX4WPSgvARjV7uYhlPU4XjNkJSdxxHGt/viIxRHJlX0+jRjG HHpDOYQs+hMihBQO1L0xLhQc5Exkq+/b2Fj9NkmHbQf2/zStgBxpjrHJH02S q31yikiGdWp53xDg8SGHA647ZSqpJnGoXk21EQnB2kjMi+vvSOG+AXsdow+S lKAWcVGLTSwxZXkVXKMA1qL8gTofdt9EZc78gRBqYXeSxhYOGbQGMW/RCEHk a/lFrxUzFL5g9618vO720FC92pZUCw9uwiJn1yFDN8RJJvHVbnCUhzL44Zz0 8k2mvjAAoSnhp3uT9DRrrSoTWHGEIRgqWTJ0d5lG+JVa5cMX2VIugiWJMHmM zkYhQ3Z9GYtKILiFYgCQKNfsP/kAQhKYbN6JRL0ta6E7Xwd6EOayJruFX+/K cRKkwufOSBAy1J91QWtKjmVPubhIZMTWUNiEQfR+OLc4dUUQnmANN5YVuyhU IJzOVMjSx3B51IjFsvjDzHo+C12v4Umi/Bb6lP0CHN9VGn7L/JRgSjCL7iHY zlnZanV7vBMoieHImPmqVx4ZF/pfynwuoe/0ffXlDOYOeERqU7cCwI1LNnYP cb2fyMClYf/kBYZMQG/u8iqfzzzBBOhllMCXUoyE0Z7dDZMqW+g0pVr87VqH o23gmsp5mgwXKrhI/qWsYOgZckj364b2887pTB4za1UH7xfLwVHReJ7yffjn pVxG2GIgPhDKdGjiq+NxBqpmr5s+Q2b4MfYBz/IFFY43nyjWK6L87bWBSepD RmafXHKutqJHwn0VDQfUPXQz9i5XGSyjzXOBaDGMrozLxUq+K6GSmXF6vmLA GnLfC+CxVyCXZhbnppF+tSol/ifQB/G7Sx1YK0XSq0WXYm81lCxNPh1r6J/r mBk0nKCRN6kk5pYe4ynwCYLB9SHKhkwmVF4LCrfN5DwHJW8/sEH560FDuI4M 9UYV5B51v1ai1BmiQCg2X61sEzTs7HbXjqzOxxRtm2ll9/XqAuhgeTgqYWIB 9UOYEg8JK1wfMWy4uMTfEBLckTIPuPY6pmnH573Cl+JMeVFFYxMhlmWs9zx3 MW5Fz999j5WaKZaDfYBG8QuKgL+I+1FwXJfMlIIr0CoiVn/PlZMpybacAm+M 676aotDGmLtehdn0fhVmGZxCgB5VKcinzLXRzIYJZ4noVtM0nUQP1YWt5BZn coNJdCsQmCMQgIXoxBwE7OqxIpK6pCSZk1hVLEHq6BXr7z4lXepashDb+pbK wVKcjgs1Fv00yAHbydlMrv4AxfSu2ZvNlSZD/rxH/nWikGDxUMp93xaJ61z1 o7AMJ+jVto7DaesKujN4PUSuBt9HooyYSvrSKs5Q3W+vULigZOflVIJhwNJ7 SnxRw5OZ0TzeOBfW3uSIk6wwSWNkYVlhgeItwt8MPEVfkyumE0REvDRsunnn U2mruM97YNWsdAfuJAcVIHHSdSAQLQQuq9PKCwO1edYEqWGmp0Acqj9rTQMy Ze6R/c6Z5Oxk41y0yMlmFXp53lomFWkrCBC6rhqiviM6R4X7baLhZqZ3avDr e4YA536LIg6T0tWqB8E/VMCiZ+xrOq7G2IyFHB7Qnh4exEm3MsAhbHVon9Bt aRDV5UmpIGmtCTxrtCIRbdc5ybakq9753RjQiDXeSTAezERCNS3OVJ8VqBgs BliEh8HuCjaojT1rcDjMNMRC1OY/QS+9QOgqacrM5qhWhKIfiAc3CTqFpGz/ gtlXIcah6teukLi9IpRib5QX0MkcaYc3Hn5ffTbOOUOaQLq5uzWUeGcd4sQv dSLpxnIyMigZUf0h95g3/NjlqXc9BRznMVvzm0/ix7vSZmAAo9PsggQrzUKG ObxDieIiCaH8M5WzpoefUsFmnre4nUIPrC8bItr8jQj8XiAGYiKuXBNObKjD BwyIp2Wa8xd0xUHIhxWgoCfTdPNoi/IVRL3yquNAebBwr2CHtFgjbhCsl8Rp 1+m0pkRgyFfvaZvsYHCFGtwx8dgGOpQ5r8c4UQrVKjeXhneJRwAcg9rpy20f fGZiqHDT9b9FC+0vqc65dQ03WJL6ptY06W47ggj5eL0Cth/khOtdchFdyqdb nC2vAOVj/d2nh0IPP+cfJWxwnqPfroqqRN2pSHW4ZCL64IhlC0q7Rfb3ilhB vmSP0wFdVdSCQH0QIj7BElO0Pr7AfD688HAxe4Ch5K76/g7Qeq+WIxlS13Ke hXKchq2TJnLr3Th9KJOife5TmNHVAkAyJMt/qFg2mjckdfsY2M3B3IgtthA+ faJr8zNuDUgyZPErHFSageC0tBnjYPYeF94Vl7g1nQCqOiitg2gIMola6xGS 7OQWk/2CYFkZ1mTrNRInofMQiFXi9WMXxwiS7dPDIKUSsH/si6xx7TzvIlZM EuiWy09YH9CxqNC+vFtCCgITmmHbS9L/mpwAU1ZEGhaIAwJtz9BmsSpi6MO8 ueL+GvqG3DHUJvH87ksyBtREIFRG98Z9Dw4aDdAZelXykEfOERDWGGpwKxRb 8oQSKeGARtdqOb4A26CN/L5aPEuT+AtO+w8rmiQvqYhXbYteERFr+Oru9rRE B2I0A4VRS0+sIMLJaLI4FPtGjWGlAZsbGnYyTk3y5YvaQTE1c2VGaTM2Aaxp zXOaLpZjdRsg1UhnXEGlZmTQmDJG4l+wfwbB5bNZQ9VjNvVU51HmzOy4Z5x2 bc6I2iPr9p7vO2OB8l4FSvzerriJ3p+sfb+zVCdf3T2Z04Ptw4NIVQvSTqB8 UoE05DBaF1mpk4Jh8fOoHmsHIz0wLcx2lZadw99PkEVwkKWx1ias3LPrBMmY nIdbYuTe5bQj8hMvKJupqMZJ82+ibLEJVEPDKDir5XgzOc/qznA4cS9Lkx3U vAIAUxqZsFhLqVAyXDYCcJpN2PUhdWtweXDw5xE2fiKt0Opne5c6R+JDfpl6 Ve5SPO+OEUiH1JyFZc87bdppwd1badu4+vCwAPdqsjXs6Y3b6N2OLqE0L0gS 9h+/H3CXI/+pP8DPtXC45aciBcF28oEZLmPK/efmaFAg6L/nSI1NF/G1vCcX I6zG3gIKmPnyBgodSgeqIpKD/BKqHYwKB/ydkkCMeNYU0XcQ2D/00GrdP13s Tv+LPyS/MsO4A/D4qwH2Oj/69a14Ygw2eNcoxo+6ozBzcuDDu0bZ/NPp4dbA j37dfIftz3GUf82+3BvGesd3MIjVsLc7gP7uuHry3740iEwqFR7eWLrv5u5W Kl9+86VB7rmcMGGJgQKn/9tvHGRwrjLLew/ydTyI2NY0Cg7ydX9P5Cebe7Yp /6I9uXuQwSO2vO/mfoP4ahfo4ovYp2zhvenkwArXG6E81j35r0Yn/bn+Djrx gzhC8XQy8BOwgNP/TDoxcTkoHP92r0GMFQwRCJnv/+WOeHCqv/WIu4M0ywnW i3JH3NsSPeVndMr/yaxgnRrwt99zxDlGSHGIdPOrrfS/4i0emOtvv8UMvOWF OiSxv8VYgDoYNrYrz+9xxAYK9kqg4oKHTaNQ4hDUR2w+OggEDs1YXaE878f0 unacqCUwII9d1sYc2gtwE5FNGAjK2+lka127MIzPcZuw1wqjCfX7CNKCZmSF oa24s6iaDuhimEqfM9e6WJRd0J/TXwZp5Re2UzqKNRb1kLASMTjE5Vmto1CG 2QSmKvKyeAQOlVyDK4k3jTCM0hPhygr1WYBiklgLWbIeC/EZdtvNOzSbWWKM WAtZiEnWBOdCpy63dKwXnA+1r8N6KBap7HoUJkmIEXZRmTg/LZLi12StOxIH SKPExlA7ykIOGOGNgXhydr72nvrGEOOrwwWdhbtM8N4WrYtNmmWcVKG6GPXh mHL87BZMH/i7mrsY8Ld6ol8wpbuerf4VsTxB6WkgXYNvXYQ16ddkuqshC1f+ wIphegU1dppIgyE3FS2CathNnLaCmcWbULkqhYyc6pfBQRCVVF4K0TTa7CQC p3VMA4JuroMhOyVzglyI3zTF9kCOwKtz8YJ32/G84/7cCRY4qp3XzjaBQ2a+ oGmotN9Qk0brr5hJlWXJFdYRplJaiEFC6PcHvtOy3/2a6DKf9QDRsNvqGbCG 1sOtWHxZEI0qwXuojXsw4l2PmBE59zvngwFEYymLcDwW9ahr24gmTxTmV1DB BWq1pW0uxXFqqFPjwHX+d4oAjJIYHmU1Ua146RJrV3RCKRVXPgoh+Ak6lM5r 9M5gC7LRWm0j+IKotBClrM9vOTygANd+Jx3epaJ7G7HDQwBb3lrja2n1UaGT t2QBCDcEi1nQ1lpnCCn7ZzjPwLSH0CtW8SFz0Q/2ji09rgdj/wnwp4IiLAPC SJAUfct53zc0dWBzB4sgLBn+vM6BwWcEde/cUKnvwRUTHBZVxpXUH3gOZfw8 pyaVZCFOVzWBers3/jy/rZgvwUPLokTEm2A88HfpptUrjqrMO7GTMBw0wvT8 fdW0wyAUX7y0u1fBot7nZZK0kveSLGJFJJ9RZ/tuV6i0tx2GbgeqE7xN3kOs YCMEkPP6Gheqb+sVeRGnVwj/wRamQ5buflxGnsJ1sGpyuUUO7GoKh4CvxKuO kSSWMtkMgw7WT5MuFNDSAD4dg99vUArAR4ji0hJheDWQSTShV1hnE6QYoDP5 Cfez1qpzIXLnWuDGE1Qy3fA/cp9jhBaiBi45E6fJ/Qjcf2h2zfyINqvb9U5J CGVmb9ODKT1EIdF41uSLCRYOKlEE60CRfO0vtHZLDKshde5HFmJ4EkIMzya7 u5OvJlh1SIMoeN4qpftrlargBI7A0qzzWKsSgFc2XY6xqsq4pPysAtMGotYT TvPgxjVlenD4zuPl1q5rzT72UFnDMW7iQ0jb55VVKO/XvScoOulf6+psm270 5SLZg8sJxvfQeqhiNPXXSNJosBguqJxAb4nGOV2IFCF3WPOvozVddBlTIzkE t/4meXbS9NBMzubeTw9KExGxhG04AYqRUeuXYsBx60CH81EWSJUzTy5osGC1 GJ/FoyuIF6EqgLlYxpd0GqLrWNs/2VfU8Uzt70TPbsgUpFPg7s1R068LSvJq Oe7Cm7PW+Kbt6bSAirKEOGAr6A3OsOCdiET5wOaLbqCdTYPuYGEyhmKrWRwq PbpCML4B4Fo0WajGfd/UQLyUa/TyXhzPYVyOtd0OConQTpw1Fwcg8UaHuASU /tZpe10isBPobhdWFe53ocVsGvQ53N4FRk8YXHuP8KEycxfP9dWMRm5WWJ2b yyMNBrCdR2Y4kn7HfH9HMJ2i0oyMYCiHlmF22xh3MFgTlEZIFYX3ktnKziOO +Gq0eYguIxqK2k4n3ESB0wK1cqe16eOtliJwiEk79oV3ZBrHWhz6ICSpnnHq amh7+tAloIaOqoJfYQXZ5bhK5isoUvNes+UIVj9KfJOoL3QO5wsgtcDi2zlK fnPmbjoeE6aAbNL4wm2R8doIPKdhHBa3cbZuLOecVwFj4p1luJJiJX1NhkRr MqBfY/P0oGHsbSwlo98c4m9YnxMUu24QWk1DfAu0TarfJ+i+gm14VWVZHbFa WNXM3qvZI/2TMyzXHfunHcS0MHLXfKFlnp3Gah/8FcynuQP9Uy4W2SMhU4Mc FJ0S9ZPke6n0TreEeSdBOYjXO4rZx0LHk5t8Ph+jICq3YbqdiujdSrmdpGu5 GcEQBeuWVr+fdIb+Orx2rMfxzfbXsknfPPglMb3/l8Hf/sI1ZZtuZ9c1+VpB EHjFsvHFe9nucAWgUX2eYg0/9kYzOtay7NZUi5PWeMNtaicdOx1GveYSZnxR VHFWSNsi+4jQLbsxBTcTxEsjHZ5BqVizP/usLtAuES5NdNGuEw8Vp2O9gVRq 33rQpBu/wIp+2fDkFMHaca0bv0wXS/hN1rg8IG76mnI/+EF8GgFK8N0/8iup rgLjNnQyvlamogdD7c4Rp70gTXFuASp2N/NQXjE8jlvrU7OaabUMUG0VCROx hgzGna8lPZzDL0asv1DVAp8MlLJ/h+uCO79aJDmzgGaFHZPqEdLEmkwenMFP eGX+jFcGX9KobgBmOfkjYOECrYluPFGFTW8fPVFLoEHSjWnNQE1XrgcnUYoK S5z+rFva5EuO4BBxcXdBiGtIJOGRMDiUN0cqfjMX1qtkJR/krDUraYBCNteL JMm4BSneKzlyJgICjvvACVE343f2BkJy/WQcjI+DileKQz8UqNCcnV5ZwzpP ekVAYz0I00AVFR/lU5LX0zyrDHyiYI1aY6N1ekCYl4DCeiAt7zg2kPDZ929/ eHWkXm03is5cXdcDpLHZbCWa8IcuTEq8OGm1PPu0uixRFfF2lUcNk2jrhhaC g6ElN2lD2F/WS5l5Ytnipq0q6bncXWUvNRL7HAiVD4SNkGdT1caw9jgVjHQ3 NAaSvh4gk8fSssDeMkuCoWRgUbCp7Yu5AlRAnETVG2gnwtart4phcC1aGzCd f6Aeh9U7iuaD85+6LLlQ9Vm3PovkVXu1YuQxu9lhi0eJz6oPQ/k2VaF9qh0e I/CFDQy7pWHFYUHeRw20sTKXYdBTkqx/kVzt5KEQErLEWDRgj3etUeFbuYAu zhUc5pquo3KenWjaKcYdQTXsjpRwNb0/8pGyezuJ2rppdJPiLNL5RGfbuVL2 ZtYdYB1jVRwH7zjr28ZbbmKGhVoVbsUPyxnpmr4gvl64e3RzFxglcOVIqSNB vy2L03qvd/3mZ74Kw7/h5Q3/AjXTaYZK1vBXTY3a8+B30smj+xWoJ9uXebtm UP0WvoN1YaXXORfw7/2KqyTPQ1uY3i+WH6bN7o6hKdZgIpKH6QlpS1hz2VKu TVEbFFGfHjrRJ6h07Xm6wI5UZj13ykT5TLahhJ6oQ6RvlmOJOYNF9tcm6Zgn 2RySGTFb8juy24lUvkFr1t9dMs75X0Cq+67Qs+2d5g9TL4iHA7poYpAH1QRH QWumrcFHmYvdeUE2qbriVuI14NqVmvKdKFgztss30ptPfnuGuL5+l7g0dS5w GfVuwYr7jYku9pz74gIozWdXqv2zwOJh/ioT/FuUIXmDAkvbgbzr2iqD9cW4 vkO6SfuF7+jGDrfIRMGRXHI45RFQf6dexqcvss1iG3fYOmXhSRaR00x9olFF bO+W7oD2sarIFevaiu5ndUtYkjS31JH64UMrlhAkbdxV1hwsVF7eqgi2BEXZ PsQeS72laV6TdsNjglFZJkFuNSuktIazK8KmXVXL8fntGP7DqHi2KlfS90NL Rq2N6NICoqglJV2k+huijY6/AkhIcU0T+TU64lV2kjf+7PuDV6+6/uWOK9Hb jlE/bUzYXB+r7Ez5ydCUvwT++E9Yw2PpC+vsjPlggTlyNN3eGdVRdAhbRX13 bPz2p5M9eP+exvHXB0ijfXxm+3joD9s2IcwsNImmRPTujLTk7OC+7FLJgs3Q 6OT09Uvp3bLm90+i32sDFo5lDrSkDxO2Ei7cNAsTeupggasxo60rJ344k3j9 waRXGqVZclu/JO109Y3d254AhenxpvWcvvHa6QRHrmd7p89Lgm3jehBJKz63 zltlkCYf9/K1BrcROVn0k6b6VgY2hZKio1L8IVnbaRSPoGTyMX+b62eDUTNU WX2nQ3EBxFGhQWLfY4bR7YLmwFPkd7tt4gVsNFa9LCAHtSMSJ8fr3lt1i+EW B6nvbh03bvCEE7Z9o+m0MQXmsy7KOnL4lgHxhPvkJAOvNLhmpaIBsZeiUSPf dWQlt9c0ewd6yC8Sl19Dw4LmSiMdR1vYZn0QzF3hYWIi66OjwomO5QTjmB1M D6uwRjLJDpDlrc90vQfHFL7UkfQD8b61cUTRU7CTUZLeGVwb6obZOrWEYLFE UfN5L6OvfxvWReIeIUnNwHBEWoD/Fpo7jjqIKV+FJgnCCze5YnjrS07aMjjt r4wrMkmW5BYu2cvLtZnA67j8E3by2iJ2RXqhGmmp4GzqCz7Y9aq6Cy3uIHqJ q+61ySrf6YEW4jnEuq33dBrDBm74YDDo2sZUu+2zXCJ7xmWxcA1cpJp8+4SN vKoq4/LEvZY1YTAsa5Q72ccq7xBCmHPb3beUf67dvlhuF9fZ9NbCIBzeGiVO n+/UOWTDBZ9zn4ZM1MsVKPm4B1ERheFr9owOlSpW3OGTSILZ4gyrREMkvW5j BFshHxRvqeTgmmVoxqDvRw3EcF6o+El+bzW9USLWE9bs64CYIlLgsK2/v+e3 CT313r6WjHxbNF2BNSV/+1X5MAvifpPuVOojkrHNsvegcUjhsW7BBi58KeUI GFFvxSJsq5WDCEo3YDY2pxeTuJjTFsPag905VL7A8fP9RH3AM19eo1vgzXPH gyUFNz6m36JGhVYSGld0x6U7DYHSfnnAzgJYEDoMHvxCpdndwJ8+FVmZuWuw laBTIc9IZLrHeT+GBuhx7OeTZxS08AamV2K6xUDSv1esVXwsqEMZ+kNcVIOS JgadRQEiXng3UxO1y3K9miYpZyUgW0QfFXOuFZUXQf8Voz1867BuG0cp2Mel r0FXRj/QcCtxduVuJdamz/dMdcNYG1F5ZCukCgjUklwY3FnRGrRLOrq0C55F wbNOT+FkQU4e5RKkPxAqhAKFeOt0cPVjxUEbkqcID8uwUgdxOqzmjqXOtM9u IVER7rUrdI/gq2UiZv8IdcWyuhlhsymzPcNpEYHginSB1JQO3Y3cPa/ErIOs 0RgzO4NvrujVtl9L4vh0J0m28yabZ02YKBcKNZeb24B9vFUmgEBwwHdJ8lPw KHVQCaMOUED9fzhhY1PAxmJV1vrsivrLaU5cMy8SBO4xmOBFgaA8rdGYYUvH 9SV3UGcCAUN+qyGDsnDVQEPyxPmtM82CjqP2KcKLfe9WZ9tzRbJLjoQRx7Se 1NaLlCmQuo66vomTaIpmpPqC3Fp2uNvTe53dIhjYsJRef2xppbkZujXgz9Sr boGILbO/QuPJkDTnK/So5Q3aV7ereTBY2PgLplcHQqvtzRfZh1zL2YXKkyGD S3HABiEd3IdJEkosH3sIRdPjaVZYs1cttbtxii7oudH5Jpj5p8+fkTl8lLXZ uhG7pV3XuAY6eHuuJouZRmJxwzCLFdnkCqTn/2axs5k9kzJroO06HpfMnMnl SJ3YREbS6OBkuEqgbrFPOOQYeFH6GKtrR+uLABZaC8/4K9wGc4Fw5XBtyYfN YiPFg/zt2NxjgPM/QX8ZKnNUGbEXsd3b2YvykuDQyoFQ+kjyMJxvRaLfy9zc xhQq6t8xyifzLLfTfbvfM71TSIjal4/vbl+e9tuXs4rHQUOqM1eI7JMAtzYS HerJTi4drFFFyWZ4EbnSct9oXnOeTL7Szl1ZNb4chV2hKMZ7YYsVSiVbiKG0 gzcHVCQ7GDnpp4ex+iYBM+szLAKloeqANAAXP96XQ84Vn5v8Vbsavskk9h/U eFW40nf4rzerxTk8J16O279tJldtu2z2t7dvbm4mOJ9JVV9uZw3eTRJl26KT UqJEM8YxxyWNctdXk49X7WK+1VGlvXqL1+WRn/f+o0dppPCS0+XRo/5SNpst /HE71Z8c0HRzGuLk+Oy79GtQRi//DS0PXM438rNDPKhpy796/zL9Go6+qHs/ OwopavjTb6OEo9N8gXdBetkP9BNz/kgy5cjQcymyPQjH3dG8kTc6t2SGpyoQ cH5/ff/9yRn85G9aV+knrBdVCX5Y+CEw0o/pA7QiIm8ZNfNh1Ft2fl7n1xLr pXyMByBQl8sHCbr2KOWQMx0j94OVecPXlCxTrzmwFKn1iKMw2LgAGFCVpB3x MUI2tL3eKmAaFQXUFftMfQi9KxV5C1j/NodD7GQALldY9cG12tgulTSmICOf V+LMPMz/6Fae60ACafuZe4fidEH76Fkta2Av2sBHwVq1tu5C+QayBuwrmBnn Dd3Vw8cQ5tyJgmA73A2MZPA5YklmSDC14/euZQuxVZqC8H/VbTCznDt3EGgP Zzyds8M6QH1gCmQuBjQUcXmLHq9zIlLs6kA6dYDUFCQsMmcYktOj+U0U5L2r oDateM1as259ymlRA5lf0+75fUg6i/ep+RyquKw5kRYG6tcotvDrAcW4JdtQ YXwgwxpttSK2Ay18FBqUkW1A10ec0ZTCBJ91sFKU/tZIB5tOZAEpf1xdsB0s zS7w2IiGkn5/Gi7m55OfCQmJzi5V+7RPtxoCJJJR00NH4aQ/P9PM/QQ16Ues KnNbSSsd1ygazYV+q6IBCFOo5mylB2hqKP25S8fA5Fy0Bu9vZ5bBnBnRWBIr GYpy5HfrDF8oSy1z16J56EVHbedGSlv0eheRXohmaY8+qF34mnQnWE6oCBIZ NsQ1UDeUM5XjSUJ1lM7ypPthN1ysNxR422z8YQnyfQo0aHkaE7HVSXD4pd2H eSNX7jlozZ/4ECQqO5l7wiL2IrO0GPZI31NY7JiwEDEQpYBFoQ6Y9AJI4VrS yJDdgAysb5eEWiZNEBVkOso8g5/N6mq5xIQDuH+kLBBGm0WpdQDEjjWmrzgc d6J5qzQw7hlYDemAd8kwVYQPSM/nFZYlie5TIp0UEBIpL0ZPF2YN5MQryUNc NM1KC6g7jbvvhtZ7q5V1O5vgGhX52CXe3fuksFGJkEQlcVVSzZQ7mzONdAqM WovqUsA9J7fHw/QgypVsEJlNKtWH9HhewFm+ykFMUDkRSfMnpAcnWlA0vBqz kwCjbcjtsnqORi1ZTshx6M7boN+iZy09nqSHWb0kpjtKX8PJZ7Bxp/jfetYQ BBvW8V0BymxRpadw5GVeXl4Vuv4Cmfdy1UrTBC01jJwBNTvOdycPGGoXF9Ir 4TWIBlR4wCjS6byv4Dyx58kxdjRp003TB5urfAkibbY1Sr7NalCSXuXFeZZu nh0fzghZj9Wr4cvX2VXeXKV/ynFAxBGXRbpJWjnQcCaVJaoaf0nu/rOros7+ USyrVZ1ufpeX44PT9zJajr86hdGyWXqaXcGi082/HLz57ujt4fu3p2f+V0f5 OXAB0JVuR+l3K9zG9EcqjpP+mM9nIN/+VF2V6dl0BeeMO7yqayCAP5OKl93A Q7Sn6VFW3s6LG3Zv/vfjbLpq8z8ipvHH2xI2BBcCRoi+t8FF9M4q3Tx4c/L6 QHLT0jbPFnA50HjaIqVIlcjT7O95fg3/Kf+ewQGfri5AR/h21eA47Sg5KGfo XAW7pCCiIJf1P8CCyNKX2T/yD1kz/nc46Cs4gQJ9k0iM83meXcLl3HJ0wZOV YkrN6vISkUuKZwZRAlePXZtAEFjGCy8N3QPndbW82E8PgfuMBULdqGFrau81 3tMy/+hcc2iHcH8NhLSv2iicqAMx2vIU5k+pjmALwhT0nw3+EzWYGgapqwyJ uLYKG6Qa1mDp3TL4r2wQyZBQqduWQA3i+G0pgRo/YM4aOv/lHvznXxLKzQ9p +Mal4nnh96yykqd5JBWQsEXQmEK+qBMvGQwqQWFTXoa4lmY+ekkQvMOrMrvJ 2LcXP2dVzq4pUsmBmo4R0ainhiAaYmSgNAHZzaHW2ymcjtY98+vk6BYHOpmH s6sfLAiEAfBQDq9/xnlWLqbvVCJyX6l3ULrnrAXXWUckKuSBZzpVrBhXSwrl cy7YKzqVDApEoSKmP+kuBstvNNGGBfCEC+yrmyk0OXp/NdDscz0qizMlS8k2 khh74ofcQCHS5O12Qel7mO/tKU5LJvOc4Nb88Obk7OQ7qmBgdToyUkeW4mwY yKWBOZJ7jPGhKEUFM/u/Jk93XvSqNVTlmJoSswgOdOwK48m8zghiPN59/JUE Km5V6Tx+f3rwevv4/eEZmJNUZRvhcL7lFDd2odZX3B9EOyp++sSLHIfRpaA6 MMtiTnrtAReRQWsVre5z/Tyzz31cOyOGhBG6xH4pu4SHonuUhXHkmtDNXaoq rLwmDbwm6fCa1NJqhLhY38gx3lpJiNR6/ZY5wfUpJ116h8AFnxeLwgpNxTQq +ancdt3N1TaVt1DULSCI8znwBVwLFdfRW0pW31x8rm0B/NrYXv8eK0wAffy4 ajITzP3X5tMrYKmo0cjNFP+RuXzQaEyEkMjcI1+u1/fizVC1745lJuLxSBlW JHYMMINlWy3JoZIuqnO8C8srDDeLMxbjFJxeg51XGuqgDNZmi1Mix1TeIhNq Eu/ECHeV8XNWOYEtGiKIbSd7yN2WBURQZD2RIm3+fasq2Y1VZZfoFGmZYDy4 iGdZm55+5fmhra+DKe3nPFnioGVaFAMnMYmiKUmXELusUt4c+pXbOmXGSaCV jUYOa5IMYJhpITGiRteoaKhE+yu78n0zF0utBlYtrTEEtZuERr5KeQR+YKea Dyb2Tr9b13JoZ3pb7vtzrt+jdHCPGIhx3rRWqcDzPjLxatQOKOOjtdbhg4xQ me2ULA+nV1xV2L0bT1IpjKpgI8XGAgL35QQeBuXiErfvmN5fwazTI9FYeMuA 20pqss4KbJ6o+7LnAn7ugafKPJMoOhmAoQhWud1Gb+pNdrt99PrfVdfjUoDs ZfWN6RoPh/n06c3x6eH48OTdeGfn6fgpdb+QQA1cwGXAXbuUI/YfniMWLWPY YxY8GzDHgjhKutlZU+FIZquTbGuPO06OzdkGTxO0BTDPmkT5YxMQOpq/OFy4 w8CX3HVUXJTdmp8nx0fStTxcEO5QKlmDJ8eHli6K/3i29/jp7vgFIsSOD8fy r8+fE5eXJRep00iy4aoEWuUmrCOB6zi4hv0+ggdJpQsHSRhmDQzkTjIljmVv RcmLShpz9gVfumO5WmBSAlXBmIdgqRFANI4UMdJNLyLsF/96qr+OVz5ypxL6 PHZToX2LVH9Pem8RgZnY2zi/WDC3J2dv092nu7vPx3t4RGdvx3hM8gnCzJx9 6l/TGc2kcvyxirCE3pa+PSTHHf4HkWew0Z3U/xidlSyqWT4HAV4WpMhj6m2d LlbUs6QD5CpCbIEEE1VUIy+H1K6NJyZp330FtydsuXowcioXQW6+uOUDL+Xs X3eHFVDlX88hbFQcF4iBIBHfWIqY5UCqZI1kSyhBcqKtqFgXwQ3XagyW+w62 Xp5xmOA8F5cZ5Ss4Dpy4AgxfPHuZ0wgNqJp7Q87nibdW2sr4djSOiVBWYcjg 1Ep6nZfxcUgdT1e5Orax/DYnHqSk1WYVFSibI+MZdydalBIobZUEFEJ+x4sc tr1kY5/dnmMPTAA5NKF6Q8NRgmD9hu5n2OH7Nsk0so4TCC5VrSDk4n1DjY4S A7pcuQRIUUa6xQIdCcATLisceV4nBn7SVGIovKvmxRQb0cXcbFzoLz5b8yor poP13qg8rxbgCbpW9BYC4AAVgSKS8HhO2SM2XsOT7G5dcENxQtLhjEYRBhIT 9E2eClaRGIYYMayyqY2VUcE9stA+kh5K4JnENCDNlMgESUnlhmF9VKHPzL4Z gnhqamRcVLOGRBioASPJKuDqA5QRi9lQLZqCnGeiHh6qZsbKqTm5z4sZHFtK Dg3yxedUnJmNSBzeILpFq5XTT0oHjHtFRdDxAjgFVqPtbDxgBW/WqpAQNq0e kVQR2TKeHbk71kWeCnKGYwmtKe+jqwojPKTm4KTdw6viEk0cr2Lb4RGqwRk/ obcl0TSZUklPM2UXqA0iXQuBBLDqpCnhsxwVD329/drQlKF2GLuTZlROmAjy 9MAcil0lX1Dqrtv0qbxUELladFxiwZPkmLQk0r85irz9bQ1KKvu0VgstS0xR zilSs/AuR+EBqapOma7FSY49vwykKervja/FfLA4dgnCiZNYuA+XlRGS3LEG 5D3riuc8127Hcg0+aRkL2hQjdQ8ZIEFmWD3tcO7OXBhWp1W6hPTPczM0eEPg /gMrJ9NAtSiWDUi0ZYq9G1quY8DGVoDeuVA0yoOsDD3WgyRWWpYG3U0Ea5Se A6SF89nQ9Uy/LxpSbzE9Stqivf/2iKo0HYP+X9X7GO/KyN1LBanJ4f7zFT8G LPWVFDqxEARnwX85aoM/G4jb0Of3DdnQb+8RtKEu3P/igAxjHu8RkqFJ3ico Q7+8OwgzGHDhdh8WduFh7hGkmoSMP1jNX/1vjrOaiptr99i9nb3d8c5zUMz/ tqkwPvSDkPc1rycKbNuGc97mx8a9VqLkbR+zejDeeTy+BXqD36NjaoxBydtx TdMdh7dtbxGE2UifLs2709cCosep/ZURoF962z3mfY+Btncebwe8t9XpBaGL EGtUhIQlcHCVHT1mqKIBZzWISKegzrBISiFpTUpxErXzKFk+3t1Lx9/QXx7T /ZIm2gTVdDx2xJI+L9em97AkkCQfGKGX+SP5p+Tj4AjTlLGMxLOiYSM5RMKH KB/nBZPHIgaMpXVXbwP+cXJ2+MPZGbn+ZjNFamCAyKpRuewGTIai3MnBynqL 7IMlInB+jWy/4o3j6hiCs8Hz08oHEbRfEHbNUGcArXBHvYRbB1HEmrX4E6wU Tkw3nDfnUW5ys8fRGvwNJwTz6ChFMP49rzKK/octHOBYlMS94G1CNx3vBaW0 IICZcsnR8wgqIlZlwnt0UxcSQ2lBocQNv8rnS0EOqrJLXlyC9FyQimrbI7UY RpYp/iHPl708cdHuCXYOG4UvaDSsG8Cc/7Giui1uhZ79dpd2k/PiPn1ix1k1 ry5vMbOGNd1svrzKwEIU9Qt+0riBu5w8DM7lSShJRh+UsRGDVBcIKgHhR92I 8G5vRMbpBjxOVL8RpwZHv+G6keu/d/OM5EtnB1aYMMoph4LHVQIeH01ykrHD XZvpNt7Z1xkHkoqMch97Oa+qUAbLCU+csUnDICZPun0RGRaHa+NmwvjiDSCS 2WrKGwffbMCGrLBTEEV9NnpMcVeZ4h4xxZfFR0yhRBQBIYLQR0UDhgAwGwvN RqjGI4s5OBJpN5KNDUk/JaLx4NdtG0IusYaBc+2pIb3Z7uhsd2m2J2U0CZsA DdbXf/DWjWWvcjYpKWgm2TpwpTcItscbZ4J9QwOJaH/SEAu8h3sYjgBz/bLO lmTuWdcUtcll66SyF76ZHtQaW7uTPfaV5PUld8m6KGo2zWRQVxcihxNgUL4f TynGgbnnIHBWxDwCUaDQBEK45YW9PvjLBjmfQ/0CGg5B5+pfzhbnwJEFA49m FGhcWA0IeRkVlOctI9IbL6/A0BcmtuANwsyqG0HOU+d2mmlDvI+iMIah3geW MGRrbticspTTFHCPN/HUgF3B/iwWWb1FlAWUkJ4IdyQpSJj4ReGyHjGz7iGQ D1fwxll94IoeGQEeKEUWdMguwe28UILbIYKD++hL5Fak5D9/9vgx2u18eoGi iKBEHm6km7AU2LGHj7/agoE4e92NhcaDZXRfsHXIlcRIKRgf6dswtxu1YVws /hsrhHExHv5yxyeg0cOBNqjnqcF65Lr/stzd+SW9Bvv5F6419wtxbjKVrQSj eDhC4UDulh2qlX8mDR0ZBx4Zfbua7prkpw4HcDFZZqIsalKp0S4q95i84Sj9 +A7DeMdU9lyuXsdE4tpZMayP5ZyN6LBTvXN9Lue682KIkQQuokYYsw6aeHTP idDRh0nXDM57uKrqhlyCOeIMcSTQozJufc5Ug3oQEuGDUP3vQZTkAWJUyxpv HJ+931AeaxKHM6/84bPDuajDK+jV8HsYCm/PrfQHRw8alyDXWhLUGpvqRKZU GUDT95vxu+oEztpxM8cCORd7gQHnqcuvD/iPOZWhvC5AjC+kIhXwirzke19x oXF3xLikotvpwooU4n1ECLUUKBeWkErFQAZG0aXrnf5XevrP6fS7l5EjaU5N F3If0p97Yz/Tsb/yY1OhPmlPiTmmISvFJxg5kKflLJhpy2Q6PIsRqaYs1zYs 4MbsXgv2bTjm10/iCTI7uglnx4dHJ6fpK3QZHqIafGr2LC8W3uA8EL3deKq7 8Yx2Q260Sp7fvxOv8d6pMcJs/PXB2YEl+Ax1pXClyIWVW7s7mgkn7VC49vQg YImRY+L3iln2vtLeep/oep/uswuB7ohowsHd7dVk3QzuimL+KuIV/IRO+T2x H1dwnNR0TZhFun8V/qrkQJmi1PEdjoorHPHiOUDi0sg2iBA2iBOsS3PTZlf9 +cOo2CtEJs5JG2tMTlqppY6F+HBcURLLP7H1/MPpK19nYoz0QlRIfKeY8n2d Y7AZlkEnsrv7jApeMqoIs16yee+wHuthPRkSAkL67MaJyf5xh+xjxXIjVE40 T+GGokCCHIh+F4dCN2S8BkOSrQR8TMb0D+7geANnvDFclXwjnh2pf2wZ3G7w fTdngbsH+cxXQ5IuEjwQK3x598HhkIGibMGYva4Kut+vD94cHbx/e/qXiP8T VWhhDAtaMvuli4igJ07pWFfmXkXrXDCH2pQh1Ikt0QOt0IZQMJ59Epb5ynXO vJTzS6WJbnDRsw0peiaFkkMXUCmV9ubte/WXm/ANEpOV8MGMmar0Jd3kzmP4 WvTCPr2GZl2RHiWQsg5GPG6Kw/RLKVJ4fhSNAHszneEOd02ZyG8TXBZVi73M NABMmglZWHQcpX5DuTN8CaSNZfDcUIsCUqgK9LWXl+3VLWtjGW9eQzAOjJR6 ZwBqrtXFBQFQ1ck/Cs59/Lrn4GdKNo9K3OXy8Oy0UbBZr54HDtep0kdjTcGU QWdPiGRLooxG3V3Ki+vYpIXW+abnvG+wZjhpRmMzIWvylgSfuvWmPPLsCB6d 0DDYqpRNVXYJRjWKe2NQHxmwQM44zE4BWPJWfcSw8eASwzooRVMCNiENM9j6 lnoJY1OyJWuuJrEY0E/ZU1eFwiDRvEUPx0yIR7IsiUIkDbRo1mx+HhegY0gn blNRXlfz69xfLuvZqnOiYayqkTDOZk31F6wxBDwuX7ZxHb0tKX8Df6LpWeTe ocr7U8WLEhXQxDNh4kASp07kVswtVNPu0Fx7R6oVFTsgo6YTTxzq3WH4C4M0 GHqBnKWbR1tAdjQ/QqBgOjWKDU7DtCVTmoM+SRx9/d2Y3HtylD5f3jkYzcyD SLi2I14QDSOulvBLTOvxdfKjzDOKm2DGAKyQBiwu0rUiHDS5TIAFWlQnm9ZV 06ki6prGTUxAEJ1oNbSRMfaorqerxel3FItUaz1OL7/Ix47QyjrUMzvYTx/8 YNWWSK64nQ76w4ORcPNr9p5yZ940dDjwBnooAUeMEcMOQDOwQdefP8P7zqzN xpn+8IFIH9r9ubR1MT8OFwvRkWIzFMfTunJvXUMHK3J0IqgYeYUCItnBmVNs FiMcPmGK0d0uKLLGi9VTJjW6tPP4fh4FCeuOxF9W3q6bEIWRiINoPzEqjMkC HdEk4hdg7nAlDdPqomF2y8oQcbORGlJe2qnoRMHmxCofebcgJc4l3A/m2iIr LGRjJSTQirqYg9ZXDwkQSQ5hyr2jEEK3TidNbOiO8+p8jZi4lLuxRDyRm4rG 2dSi7lYX73bLWtIqyxziOVRH3uO71ojIf4Zf0TuidN/fzKsmohGbH80fPr/R BQrhM5Sx4ufvsF6aUk9OxcwMCy0yPM8Suzo9Mhn7ZxoiQZ1uMFGDFitZXuRH dpyRvYfyXVCxo+z9STAXH7zvTapC2nRRxSHo8QOuZt192h+0oafQof4lsTSZ TB7cxQgGEoKZEc7R6kYDWtRTH1p0JuBruZzHevCfPsld+Tn/KMVQxT8YZWxW UT25bZucElAzlF5Gpy3mWn3Jc9oYanPZ62650fUT45yMRl3jadjTffpy459p vLVhUjTy05/9+/t36SZ5659+tbflrwVoqqsoB5RvMlbCZnNjyZCEg7PDk5Mx wubYq01LPvvxu5QfjCRMs6CCLyy20eUdc3THvretFr55i9jBQjUbr/M0ysPt FU3UgooaEQjp7Ow6ConrCtzFxPYKU49hi/jX2pyqkyPPXqLIfCPCIJ+T+aIj 3JaEasU0jsKJTrhxYBF/uRLnKFKnoTODodKTsRqs3OFg5UENqhWWzofT2Dfe G+4ueZRDEPL0YPsV/H98Vz/eUp1x7AbTI5rhErs/7omt1LGgWOpzvmufppLk JaM7bEHsG+2uUNyG6PZQhX1ZSYPouboQN9Zha9gNFH2bb0jgCsYzfxkuxcIY xrHMr+YJdEBnYdjZHO/+LN2EKzzeMue2CM2iTq/AbM/rJryd+Q+JmVBxapqj 8+WGahjoTmIJ0YH9etLZL/GxHmVwf9Jr1AHhvYtz8k8spA0dUR3VizkL+qWo dJTWBSoldQT3Ls2RsV6JKTA6jEa5Ki5Esi+QJ2L2b8U9E1yXsS+12J24yADd 9qLFlAN1gAPvH2PIF2OYJYZphMFLVYslzY3redKlN5SD6MtUL4I2G7WYgdT8 TiCQ8/vDeEx2C+1ggPyLQY80yGOq2XNTEbwZDz8ENi5cbHuI4h93T5Adr/jS WfrD4Z71KqOi1FIms1OuSMUpRr0xuYQAYlgwVbHzVms9SghQKJYEDhGvIkyN nHAU9aZReC2T9DX5EOUZIJRpToUbZW8q7K6rKaIW26F7BetIol6jA48gTpBm j+yOl0zbzHgf9grFkDaYzA+Hu45wHK8y4fuFVlOTcBd7lyZrgqwYPLu97tmx nfM9iLtcQEwjAbhSU79SEgtD0IkWLQGacSgiSyvbwwl0vqOySTnrGFqpKHht QBG7mDie619Kh+r2WF7h4l9Ng9obyXpqYptmmEE2psrYCy13j22V4+qV7EQm ZQJOHUdfzfOtwf3a7e4Xy6wjyQGzmi3cBNH10XZZYY3MfJK+5RKppmpYMX8e HJ/709uzY22LomEwRFkg+Eeofi59taWqrd5wfbtoZVHHZt452uj3LujDF2Nf zvjhnlzPMW0jrjzgJPkj0q3FVOQCQ8iJ+Tu6AlxW6s63PE7f/fDq1fa7H86+ x1fIKxmnCGx+jIctuEv5zljFWFmFTEE0Us9ZfCPKR50sVtuPu4w2XilMgKc9 Y3SMuE3ALh2/O/tzuileGOUYaK+anUpYRlkBkGg1LQYuOmuVdO5EHxdoYXPg nIs2EVVz3kOKHTxcuUPq4000QBnYcvCU1dbk0Wc4i9rK+84sFh82bNy9rlSt A/FBlBaEFX61XliX7a1cDYvuKJty2Lt7zK+OgtbADjClluaqWIZyLR1yY+Mn qII66pNR+vAp/P+LrbA0uWOseHmXs2MYhAkezztVoNlW8i/S18e+QFUR+vP5 aou9W1HGRxcHSEzOBWDorJ2eyu/Ugt3eLhV+9eeTI2a04ZdKArbdu7zdx8pv lSkUpbMM70X+OCPrfhh5OrHnA2joXV4bGfIwgM1py5/NP0MIMl8d+Onw6Z+B tG05ViiJl3uOT1NxNuT6pu/Yo33uv9Pl/rseDUJ+UsQ1U4zc/KOslmldbYYI x61jmZU3Up0jr0XHKbjqMFnNIRCH2FppUM6LERKn7Lx4lWwcMpSQpUNw8N8R TPBMf6KmP+5pIyQ96I1j0Gpv1HBgMgV9WbfZrXRX9kXU/TgTxrEi5Knj6lQ6 VuKm1m1NusmBAXLw4t5Q8seh97jiOQWgiu8dPNxUt5Xl9+pTmNh2jXbvwtSl 2m4FPlrNW1+8ElQg3yuWAuHo7gskRm70gS7JWrA+jlWyfcHNdAeYs/YQlrkK Up8yN7DMbMlxIBEQGpXEbbPOR4Oaa6zBvb+CDWvSn1DVpuiRW6y4MayEfhiX bx8mx4JOi3nlMBOSOn17Y2ff3qdyqX+u1HL6X3qslH3hDzalOroUV9Q08saC h7uTx8ytOfJuy6I1hBtv7bRdWI5S5hnox+UBLRdPbaKDNZ2zXZ8KNgQLduKp 0W6FV0IPg9iT7BmlXV6508ZpgF1ySR/pHDhFcVsRwc5wL6XqIkXh476hEf2g bWMTpzyT0MiYuChvQdcccu12KLAmHEW8L3HZSuVgocpRdNt8RvUjqsRvXnQH XVuQYUtgQi3kLKcsNAFKz7ip5p8/T9IzzjoiP0nEtQhtgLV/LcdbEsFFUVxI rXPKcJZAcOxpOA3GJ0idwlsfzMX6ZbE7wYhwSeiEyQll4XDYcsX78u4T0Ado DhNQpQwX+RBqzgnQGNq0yBsnklDJVJdURl3AnMrDrg+OwdVFswyqmZwT+yEx TVQigrCjgmVX3zk2YBQ9pnMtWGmhQh1ZiGfhVsbFOXy0ZGRUjfsTjoyDYtbv KromTY8QiGVrAqmRSyYh2juZGxnkYoU7pu/MJzqmTgHjTm2MGfk8Btoi+C46 FPDUPdN4KPdQgceDNceZCt1mpjIe2++l0SiyKOvXOekIpDJbWKQDlRseQgsb 8gVDRpUiP/PeNkqqk99hEQGtrsMjsJbHeVnWPkoAdc6XHMy9UKmFc+ECa0Vq kcQ7gxpRwG1AWc/IVWZMMGS533USpoCjyVdKsT7VibQeGrLPgniN3IQK44uu gHNHRYtLZDjpKhcjyB0W4YGpG5SOrTzO/o5uEz0bFs7h2AHv44hdEWZOkvnE 6oXrJCbvncTUbVLIPJl6fCHsZIdHIVNitLwYs0soCzOElBagWRWc3TDYP74n ve+8luT3EWdPmHjMzCRxUJGyvHxrYENRveoCXttD9k7MhRR1D7pj9QNrR0K7 /+q7a+e83eAq5aMUmkPLhLINRGZoxWJKzmf9ChUZkyahwWVrbWNwaC1D2ISy IrExKQsQrZ3qSKAF5Mpep7YVk/TIXij4apZQxm7kVkmhjIYqvxTkDybAQ12z g+VLrnzUJmPZHXGVfB4QHeYlovvNZ8R77Z6QVqxmkkd+ATZoRN6vOzu+XgLj o9NWZaGbJOy1B4PZ9NQUEcwdjevO+0CWcM/81fs7Ci3w5lzaZbDQJ6FbzAqU 2IPnLaEgNu+iL2j8WW7NPLdj8fhRX4WLhBQlErSV+OARTTMPDcb0RV2J1VOh puQCc4V0Q92iXitcaS9Om0s6KRdRgeepr0VouSRQMGPkaBTykHGAgd4cpOIy k3A7LQ1+/ZIi2OmuWfLB2xhrM18iSrVe/v+g+8PfQ+5K7PCi30PukU6Ok3iD QS7hdKBMcHyvY3AomgHeOaSMD872/FZrXrLktmqDMH+Wyo12u31FJTtPKKfp qJi2+ykoOVgNsuSvfgKNrNlPz6fLdDWlV8DtUzL0Gfi4BWlOLQOo01eKXb7S czDbszLDBk3ReNz5K9VWfZTOnvNwaTvHyMw1d4ACqw7dUaDNU6qMCC3s4x2N d9CifZfOESwwJT2tWKJXcJpSvJpvRHoD53G7APpHcoFrAsT7Ycr11aLREAtO v4JB4JJw/8STqIkRwxDSOvsR3Y4F+R2WiMD5j4bahUfjwazZuOK/UMs63B6Y RtZcAzOC3Z2CaPg7wuqWH4qP08Uy/bBMj96eSDJGNNy76h38PyKXJPkawx6c OIT3lT21/AG8U1JNynMwbJZwFTm/IhoQk89TfCe1eUI/pCh+72+XefoBiLTF esIwaF3g766RPSJpo9+NW6tH410Cza7OU857T70GHZqP59yLh/zWlKQe+s9T G+towKF6M9+BzYQp3v36Mr6cRTTMcJGGUNPAlyAIef6cHm+p8YRt/v8AB4Le mq4+AQA=[rfced] Formatting and XML: a.) There are several author comments present in the XML. Please review and confirm that none of these comments still need to be addressed. Note that the comments will be deleted prior to publication. b.) Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). c.) We note the following different uses regarding this document's use of <tt> styling and quotation marks. In the HTML and PDF outputs, the text enclosed in <tt> is output in fixed-width font. In the txt output, there are no changes to the font. Please review carefully and let us know if any updates should be made for consistency: the <tt>caPubs</tt> field the acp-node-name field (no quotes or <tt> styling) <tt>"brski-reg-cmp"</tt> brski-reg-cmp (no quotes or <tt> styling) <tt>"brski-registrar"</tt> <tt>"/.well-known/est/simpleenroll"</tt> <tt>"/.well-known/<enrollment-protocol>/<request>"</tt> <tt>"/fullcmc"</tt> endpoint <tt>"/simpleenroll"</tt> endpoint '<tt>est</tt>' '<tt>cmp</tt>' <tt><enrollment-protocol></tt> <tt><request></tt> The label <tt>[OPTIONAL forwarding]</tt> 'renewal' option "tls-unique" value the tls-unique value (no quotes) --> <!-- [rfced] Abbreviations: a.) FYI - We have updated the expansion of LDevID throughout the document as follows. Please review and let us know of any objections. Original: Locally significant Device IDentifier (LDevID) Current: Local Device Identifier (LDevID) b.) We note the following expanded forms of "PKI" are used after the abbreviation is introduced. May we update these instances below to the abbreviation? Public-Key Infrastructure public-key infrastructure c.) May we update instances of "local RA" to the abbreviation "LRA"? d.) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Autonomic Control Plane (ACP) Certificate Management over CMS (CMC) Cryptographic Message Syntax (CMS) Constrained Application Protocol (CoAP) Simple Certificate Enrollment Protocol (SCEP) --> <!-- [rfced] Please review the following changes and questions we have regarding the References section: a.) [UNISIG-Subset-137] The provided URL returns the message: "The requested page could not be found." We found the following URL from the European Union Agency for Railways (ERA) website, which matches the specification described in this reference, but it is a more up-to-date version from May 2023. Would you like to use this version and URL instead? <https://www.era.europa.eu/system/files/2023-09/index083_-_SUBSET-137_v400.pdf> Current: [UNISIG-Subset-137] UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset- 137, Version 1.0.0, December 2015, <https://www.era.europa.eu/sites/default/files/filesystem/ ertms/ccs_tsi_annex_a_-_mandatory_specifications/ set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_- _subset-137_v100.pdf>. b.) [BRSKI-AE-OVERVIEW] FYI - We have removed the text below from the <annotation> element in this reference. If you would like to include this note, we recommend placing it in the document where this reference is cited (rather than in the references section). "Graphics on slide 4 of the status update on the BRSKI-AE draft 04 at IETF 116." c.) [IEC-62351-9] Would you like to update to the newest version of this reference? The cited version of this reference has been withdrawn. In addition, this version of the document references the SCEP Internet-Draft rather than RFC 8894 (SCEP). RFC 8894 is cited in the 2023 version. Current: [IEC-62351-9] International Electrotechnical Commission, "Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment", IEC 62351-9:2017, May 2017, <https://webstore.iec.ch/en/publication/30287>. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>