rfc9733xml2.original.xml   rfc9733.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 2.6
.10) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc compact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc iprnotified="no"?> -ietf-anima-brski-ae-13" number="9733" category="std" consensus="true" submissio
<?rfc strict="yes"?> nType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" update
s="" obsoletes="" xml:lang="en">
<rfc ipr="trust200902" docName="draft-ietf-anima-brski-ae-13" category="std" con sensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="t rue">
<front> <front>
<title abbrev="BRSKI-AE">BRSKI-AE: Alternative Enrollment Protocols in BRSKI </title>
<author initials="D." surname="von&nbsp;Oheimb" fullname="David von&nbsp;Ohe <!--[rfced] Please note that the title of the document has been updated as
imb" role="editor"> 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 in BRSKI
Current:
BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative Enroll
ment
-->
<title abbrev="BRSKI-AE">BRSKI-AE: Bootstrapping Remote Secure Key Infrastru
cture with Alternative Enrollment</title>
<seriesInfo name="RFC" value="9733"/>
<author initials="D." surname="von Oheimb" fullname="David von Oheimb" role=
"editor">
<organization abbrev="Siemens">Siemens AG</organization> <organization abbrev="Siemens">Siemens AG</organization>
<address> <address>
<postal> <postal>
<street>Otto-Hahn-Ring 6</street> <street>Otto-Hahn-Ring 6</street>
<city>Munich</city> <city>Munich</city>
<code>81739</code> <code>81739</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>david.von.oheimb@siemens.com</email> <email>david.von.oheimb@siemens.com</email>
<uri>https://www.siemens.com/</uri> <uri>https://www.siemens.com/</uri>
skipping to change at line 60 skipping to change at line 67
<postal> <postal>
<street>Otto-Hahn-Ring 6</street> <street>Otto-Hahn-Ring 6</street>
<city>Munich</city> <city>Munich</city>
<code>81739</code> <code>81739</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>hendrik.brockhaus@siemens.com</email> <email>hendrik.brockhaus@siemens.com</email>
<uri>https://www.siemens.com/</uri> <uri>https://www.siemens.com/</uri>
</address> </address>
</author> </author>
<date year="2025" month="February"/>
<area>OPS</area>
<workgroup>anima</workgroup>
<date year="2024"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<area>Operations and Management</area> <keyword>example</keyword>
<workgroup>ANIMA WG</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document defines enhancements to the Bootstrapping Remote Secure
<?line 148?> Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative
Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate
<t>This document defines enhancements to the Bootstrapping Remote Secure Key enrollment mechanisms instead of the originally specified use of
Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative Enrollment).<br Enrollment over Secure Transport (EST). It supports certificate
/> enrollment protocols such as the Certificate Management Protocol (CMP)
BRSKI-AE extends BRSKI to support certificate enrollment mechanisms that use authenticated self-contained signed objects for certification
instead of the originally specified use of EST. messages, allowing for flexibility in network device onboarding
It supports certificate enrollment protocols, such as CMP, scenarios. The enhancements address use cases where the existing
that use authenticated self-contained signed objects for certification messages, enrollment mechanism may not be feasible or optimal, providing a
allowing for flexibility in network device onboarding scenarios.<br /> framework for integrating suitable alternative enrollment protocols.
The enhancements address use cases where the existing enrollment mechanism This document also updates the BRSKI reference architecture to
may not be feasible or optimal, providing a framework accommodate these alternative methods, ensuring secure and scalable
for integrating suitable alternative enrollment protocols.<br /> deployment across a range of network environments.</t>
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> </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/bro
wse/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> </front>
<middle> <middle>
<section anchor="introduction">
<name>Introduction</name>
<t>Bootstrapping Remote Secure Key Infrastructure (BRSKI) <xref target="RF
C8995"/> is typically used with Enrollment over Secure
Transport (EST) <xref 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.
<?line 164?>
<section anchor="introduction"><name>Introduction</name>
<t>BRSKI <xref target="RFC8995"/> is typically used with Enrollment over Secure
Transport
(EST, <xref target="RFC7030"/>) as the enrollment protocol
for operator-specific device certificates, employing HTTP over TLS for secure me
ssage 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 This enhancement of BRSKI is named BRSKI-AE, where AE stands for
**A**lternative **E**nrollment. **A**lternative **E**nrollment.
(while originally it was used to abbreviate **A**synchronous **E**nrollment) (while originally it was used to abbreviate **A**synchronous **E**nrollment)
-->
</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 certification requests while ensuring that the
integrity and authenticity of the enrollment messages are maintained with
full cryptographic strength.</t>
<t>This approach offers several distinct advantages. <t>This specification carries over the main characteristics of BRSKI,
It allows for the authentication of the origin of requests and responses namely:</t>
independently of message transfer mechanisms. <ul spacing="normal">
This capability facilitates end-to-end authentication <li>
(i.e., end-to-end proof of origin) across multiple transport hops
and supports the asynchronous operation of certificate enrollment. Consequently,
this provides architectural flexibility in determining the location and timing
for the ultimate authentication and authorization of certification requests,
while ensuring that the integrity and authenticity of the enrollment messages
is maintained with full cryptographic strength.</t>
<t>This specification carries over the main characteristics of BRSKI, namely:</t <!-- [rfced] We have updated the text below to improve readability. Please
> review to ensure these changes do not alter your intended meaning.
<t><list style="symbols"> Original:
<t>The pledge is assumed to have received its Initial Device IDentifier It uses them to authenticate itself to the
(IDevID, <xref target="IEEE_802.1AR-2018"/>) credentials during its manufacturin Manufacturer Authorized Signing Authority (MASA, [RFC8995]), and
g. to the registrar, which is the access point of the target domain,
It uses them to authenticate itself to the and to possibly further components of the domain where it will be
Manufacturer Authorized Signing Authority (MASA, <xref target="RFC8995"/>), operated.
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.</t>
<t>The pledge first obtains via the voucher <xref target="RFC8366"/> exchange
a trust anchor
for authenticating entities in the domain such as the domain registrar.</t>
<t>The pledge then obtains its
Locally significant Device IDentifier (IDevID, <xref target="IEEE_802.1AR-2018"/
>).
To this end, the pledge generates a private key, called LDevID secret,
and requests via the domain registrar from the PKI of its new domain
a domain-specific device certificate, called LDevID certificate.
On success, it receives the LDevID certificate along with its certificate chain.
</t>
</list></t>
<t>The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID certificat Current:
e It uses them to authenticate itself to the
enrollment through the use of an alternative protocol to EST that:</t> 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><list style="symbols"> <t>The pledge is assumed to have received its Initial Device
<t>Supports end-to-end authentication over multiple transport hops.</t> Identifier (IDevID) <xref target="IEEE_802.1AR-2018"/> credentials
<t>Facilitates secure message exchange over any type of transfer mechanism, during its manufacturing. It uses them to authenticate itself to
including asynchronous delivery.</t> the Manufacturer Authorized Signing Authority (MASA) <xref
</list></t> target="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>
</li>
<li>
<t>The pledge first obtains via the voucher exchange <xref
target="RFC8366"/> a trust anchor for authenticating entities in the
domain such as the domain registrar.</t>
</li>
<li>
<t>The pledge then obtains its Local Device Identifier
(LDevID) <xref target="IEEE_802.1AR-2018"/>. To this end, the
pledge generates a private key, called an "LDevID secret". Then, it
requests via the domain registrar from the PKI of its new domain a
domain-specific device certificate, called an "LDevID certificate".
On success, it receives the LDevID certificate along with its
certificate chain.</t>
</li>
</ul>
<t>The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID
certificate enrollment through the use of an alternative protocol to EST
that:</t>
<ul spacing="normal">
<li>
<t>supports end-to-end authentication over multiple transport hops and
</t>
</li>
<li>
<t>facilitates secure message exchanges over any type of transfer
mechanism, including asynchronous delivery.</t>
</li>
</ul>
<!--- not really: and <!--- not really: and
* defining a certificate waiting indication and handling, for the case that the * defining a certificate waiting indication and handling, for the case that the
certifying component is (temporarily) not available. certifying component is (temporarily) not available.
--> -->
<t>It may be observed that the BRSKI voucher exchange between the pledge, <t>It may be observed that the BRSKI voucher exchange between the
registrar, and MASA involves the use of authenticated self-contained objects, pledge, registrar, and MASA involves the use of authenticated
which inherently possess these properties.</t> self-contained objects, which inherently possess these properties.</t>
<t>The existing well-known URI structure used for BRSKI and EST messages <t>The existing well-known URI structure used for BRSKI and EST messages
is extended by introducing an additional path element is extended by introducing an additional path element that specifies the
that specifies the enrollment protocol being employed.</t> enrollment protocol being employed.</t>
<t>This specification allows the registrar to offer multiple enrollment protocol <t>This specification allows the registrar to offer multiple enrollment
s, protocols, enabling pledges and their developers to select the most
enabling pledges and their developers to select the most appropriate one appropriate one based on the defined overall approach and specific
based on the defined overall approach and specific endpoints.</t> endpoints.</t>
<t>It may be important to note that BRSKI (RFC 8995) specifies the use of <t>It may be important to note that BRSKI <xref target="RFC8995"/>
HTTP over TLS, but variations such as Constrained BRSKI specifies the use of HTTP over TLS, but variations such as Constrained
<xref target="I-D.ietf-anima-constrained-voucher"/> which uses CoAP over DTLS, BRSKI <xref target="I-D.ietf-anima-constrained-voucher"/>, which uses
are possible as well. In this context, the Constrained Application Protocol (CoAP) over DTLS, are possible as wel
'HTTP' and 'TLS' are used as references to the most common implementation, l. In this context, "HTTP" and "TLS"
though variants using CoAP and/or DTLS are implied where applicable, are used as references to the most common implementation, though
as the distinctions are not pertinent here.</t> 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 <t>This specification, together with its referenced documents, is
support BRSKI with the Certificate Management Protocol (CMP, <xref target="RFC94 sufficient to support BRSKI with the Certificate Management Protocol
80"/>) (CMP) <xref target="RFC9480"/> as profiled in the Lightweight CMP
as profiled in the Lightweight CMP Profile (LCMPP, <xref target="RFC9483"/>). Profile (LCMPP) <xref target="RFC9483"/>. Integrating BRSKI with an
Integrating BRSKI with an enrollment protocol or profile other than LCMPP enrollment protocol or profile other than LCMPP will necessitate
will necessitate additional IANA registrations, as detailed in this document. additional IANA registrations, as detailed in this document.
Furthermore, additional specifications may be required for the details Furthermore, additional specifications may be required for the details
of the protocol or profile, which fall outside the scope of this document.</t> of the protocol or profile, which fall outside the scope of this
document.</t>
<section anchor="sup-env"><name>Supported Scenarios</name> <section anchor="sup-env">
<name>Supported Scenarios</name>
<t>BRSKI-AE is designed for use in scenarios such as the following:</t>
<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>
</li>
<li>
<t>When the application context precludes the use of EST for
certificate enrollment due to factors such 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-possession methods as
those described in <xref target="RFC6955"/>. EST, which
relies on CSRs in PKCS #10 format <xref 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>
</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>
</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>
</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>
<t>BRSKI-AE is designed for use in scenarios such as the following:</t> <section anchor="terminology">
<name>Terminology and Abbreviations</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 in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t><list style="symbols"> <t>This document relies on the terminology defined in <xref
<t>Pledges and/or the target domain leverage an existing target="RFC8995"/>, <xref target="RFC5280"/>, and <xref
certificate enrollment protocol other than EST, such as CMP.</t> target="IEEE_802.1AR-2018"/>, which is partly repeated here. Several
<t>The application context precludes the use of EST further terms are also described here.</t>
for certificate enrollment due to factors such as: <list style="symbols">
<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>
<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>
<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-possession methods, as those described in <xref target="RFC
6955"/>.
EST, which relies on CSRs in PKCS #10 <xref target="RFC2986"/> format, 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>
<t>The pledge implementation employs security libraries that do not suppor
t EST
or uses a TLS library lacking support for the "tls-unique" value <xref target="R
FC5929"/>,
which EST requires for the strong binding of source authentication.</t>
</list></t>
<t>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 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>Bootstrapping may be managed in various ways depending on the application dom <t>To be independent of the terminology of a specific enrollment
ain. protocol, this document utilizes generic terminology regarding PKI
<xref target="app-examples"/> provides illustrative examples management operations.</t>
from different industrial control system environments and operational contexts
that motivate the support of alternative enrollment protocols.</t>
</section> <!-- [rfced] Please review the following questions and changes regarding the
</section> terminology list in Section 2:
<section anchor="terminology"><name>Terminology and abbreviations</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI a.) FYI - We have updated some list items to have a 1:1 relationship between
RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL abbreviation and expansion. Please carefully review these changes and let us
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO know of any objections.
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
<?line -18?> b.) As this list contains a mixture of definitions and abbreviations, may we
separate these items into two separate lists for readability?
<t>This document relies on the terminology defined in <xref target="RFC8995"/>, c.) We note that several abbreviations appear in this document that are not
<xref target="RFC5280"/>, included in the terminology list in Section 2 (see some examples
and <xref target="IEEE_802.1AR-2018"/>, partly repeated here. below). Please review and let us know if these or any other terms should be
Also several further terms are described here.</t> added.
<t>To be independent of the terminology of a specific enrollment protocol, this (Note that we have already added a list item for Certification Authority (CA)
document utilizes generic terminology regarding PKI management operations.</t> as this abbreviation appears in other definitions in this list.)
<dl> Key Encapsulation Mechanism (KEM)
<dt>asynchronous:</dt> Certificate Request Message Format (CRMF)
<dd> Simple Certificate Enrolment Protocol (SCEP)
<t>time-wise interrupted delivery of messages,<br /> Certificate Management over CMS (CMC)
here between a pledge and some backend system (e.g., an RA)</t> Autonomic Control Plane (ACP)
</dd> -->
<dt>attribute request:</dt>
<dd>
<t>message requesting content to be included in the certification request</t
>
</dd>
<dt>attribute response:</dt>
<dd>
<t>message providing the answer to the attribute request</t>
</dd>
<dt>authenticated self-contained object:</dt>
<dd>
<t>a data structure that is cryptographically bound to the identity of
its originator by an attached digital signature on the actual object,
using a private key of the originator such as the IDevID secret.</t>
</dd>
<dt>backend:</dt>
<dd>
<t>placement of a domain component separately from the domain registrar;
may be on-site or off-site</t>
</dd>
<dt>BRSKI:</dt>
<dd>
<t>Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995"/></
t>
</dd>
<dt>BRSKI-AE:</dt>
<dd>
<t>BRSKI with <strong>A</strong>lternative <strong>E</strong>nrollment, a va
riation of BRSKI <xref target="RFC8995"/>
in which BRSKI-EST, the enrollment protocol between pledge and the registrar,
is replaced by enrollment protocols that support end-to-end authentication
of the pledge to the RA, such as Lightweight CMP (see LCMPP).</t>
</dd>
<dt>CA certs request:</dt>
<dd>
<t>message requesting CA certificates</t>
</dd>
<dt>CA certs response:</dt>
<dd>
<t>message providing the answer to a CA certs request</t>
</dd>
<dt>certificate confirm:</dt>
<dd>
<t>message stating to the backend PKI that the requester of a certificate
received the new certificate and accepted it</t>
</dd>
<dt>certification request:</dt>
<dd>
<t>message requesting a certificate with proof of identity</t>
</dd>
<dt>certification response:</dt>
<dd>
<t>message providing the answer to a certification request</t>
</dd>
<dt>CMP:</dt>
<dd>
<t>Certificate Management Protocol <xref target="RFC4210"/> <xref target="RF
C9480"/></t>
</dd>
<dt>CSR:</dt>
<dd>
<t>Certificate Signing Request</t>
</dd>
<dt>EST:</dt>
<dd>
<t>Enrollment over Secure Transport <xref target="RFC7030"/></t>
</dd>
<dt>IDevID:</dt>
<dd>
<t>Initial Device IDentifier of a pledge, provided by the manufacturer
and comprising a private key and the related X.509 certificate with its chain</t
>
</dd>
<dt>LCMPP:</dt>
<dd>
<t>Lightweight CMP Profile <xref target="RFC9483"/></t>
</dd>
<dt>LDevID:</dt>
<dd>
<t>Locally significant Device IDentifier of a pledge, provided by its target
domain
and comprising a private key and the related X.509 certificate with its chain</t
>
</dd>
<dt>local RA (LRA):</dt>
<dd>
<t>a subordinate RA that is close to entities being enrolled and separate fr
om
a subsequent RA. In BRSKI-AE it is needed if a backend RA is used,
and in this case, the LRA is co-located with the registrar.</t>
</dd>
<dt>MASA:</dt>
<dd>
<t>Manufacturer Authorized Signing Authority, provides vouchers</t>
</dd>
<dt>off-site:</dt>
<dd>
<t>locality of component or service or functionality, such as RA or CA,
not at the site of the registrar.
This may be a central site or a cloud service,
to which connection may be intermittent.</t>
</dd>
<dt>on-site:</dt>
<dd>
<t>locality of a component or service or functionality
at the site of the registrar</t>
</dd>
<dt>PKI/registrar confirm:</dt>
<dd>
<t>acknowledgment of the PKI on the certificate confirm</t>
</dd>
<dt>pledge:</dt>
<dd>
<t>device that is to be bootstrapped into a target domain.
It requests an LDevID using IDevID credentials installed by its manufacturer.</t
>
</dd>
<dt>RA:</dt>
<dd>
<t>Registration Authority, the PKI component to which
a CA typically delegates certificate management functions
such as authenticating pledges and performing authorization checks
on certification requests</t>
</dd>
<dt>registrar:</dt>
<dd>
<t>short for domain registrar</t>
</dd>
<dt>site:</dt>
<dd>
<t>the locality where an entity, such as a pledge, registrar, or PKI compone
nt
is deployed. The target domain may have multiple sites.</t>
</dd>
<dt>synchronous:</dt>
<dd>
<t>time-wise uninterrupted delivery of messages,
here between a pledge and a registrar or backend system (e.g., the MASA)</t>
</dd>
<dt>target domain:</dt>
<dd>
<t>the domain that a pledge is going to be bootstrapped into</t>
</dd>
</dl>
</section> <dl newline="false" spacing="normal">
<section anchor="req-sol"><name>Basic Requirements and Mapping to Solutions</nam
e>
<t>Based on the intended target scenarios described in <xref target="sup-env"/> <dt>asynchronous:</dt>
and <dd>the time-wise interrupted delivery of messages, here, between a
the application examples described in <xref target="app-examples"/>, the followi pledge and some backend system (e.g., an RA).</dd>
ng
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> <dt>attribute request:</dt>
<dd>a message requesting content to be included in the certification req
uest.</dd>
<t><list style="symbols"> <dt>attribute response:</dt>
<t>Proof of possession: demonstrates access to the private <dd>a message providing the answer to the attribute request.</dd>
key corresponding to the public key contained in a certification request.
This is typically achieved by a self-signature using the corresponding
private key but can also be achieved indirectly, see <xref section="4.3" section
Format="comma" target="RFC4210"/>.</t>
<t>Proof of identity, also called proof of origin:
provides data origin authentication of the certification request.
Typically, this is achieved by a signature using the pledge IDevID secret
over some data, which needs to include a sufficiently strong identifier
of the pledge, such as the device serial number
typically included in the subject of the IDevID certificate.</t>
</list></t>
<t>The remainder of this section gives a non-exhaustive list of solution example <dt>authenticated self-contained object:</dt>
s, <dd>a data structure that is cryptographically bound to the identity
based on existing technology described in IETF documents.</t> of its originator by an attached digital signature on the actual
object, using a private key of the originator such as the IDevID
secret.</dd>
<section anchor="solutions-PoP"><name>Solution Options for Proof of Possession</ <dt>backend:</dt>
name> <dd>the placement of a domain component separately from the domain
registrar; it may be on-site or off-site.</dd>
<t>Certificate signing request (CSR) objects: CSRs are <dt>BRSKI:</dt>
data structures protecting only the integrity of the contained data <dd>Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995
and providing proof of possession for a (locally generated) private key. "/></dd>
Important types of CSR data structures are:</t>
<t><list style="symbols"> <dt>BRSKI-AE:</dt>
<t>PKCS #10 <xref target="RFC2986"/>. This very common form of CSR is <dd>BRSKI with Alternative Enrollment. Refers to a
self-signed to protect its integrity and to prove possession of variation of BRSKI <xref target="RFC8995"/> in which BRSKI-EST, the
the private key that corresponds to the public key included in the request.</t> enrollment protocol between the pledge and the registrar, is replaced
<t>Certificate Request Message Format (CRMF, <xref target="RFC4211"/>). by enrollment protocols that support end-to-end authentication of the
This less common but more general CSR format pledge to the RA, such as Lightweight CMP (see LCMPP).</dd>
supports several ways of integrity protection and proof of possession.
Typically a self-signature is used, which is generated over (part of) the
structure with the private key corresponding to the included public key.
CRMF also supports further proof-of-possession methods for types of keys
that do not have signing capability. For details see <xref section="4" sectionFo
rmat="comma" target="RFC4211"/>.</t>
</list></t>
<t>It should be noted that the integrity protection of CSRs includes the public <dt>CA:</dt>
key <dd>Certification Authority</dd>
because it is part of the data signed by the corresponding private key.
Yet this signature does not provide data origin authentication, i.e., <dt>CA certs request:</dt>
proof of identity of the requester because the key pair involved is new <dd>a message requesting CA certificates.</dd>
and therefore does not yet have a confirmed identity associated with it.
<dt>CA certs response:</dt>
<dd>a message providing the answer to a CA certs request.</dd>
<dt>certificate confirm:</dt>
<dd>a message stating to the backend PKI that the requester of a
certificate received the new certificate and accepted it.</dd>
<dt>certification request:</dt>
<dd>a message requesting a certificate with proof of identity.</dd>
<dt>certification response:</dt>
<dd>a message providing the answer to a certification request.</dd>
<dt>CMP:</dt>
<dd>Certificate Management Protocol <xref target="RFC4210"/> <xref target
="RFC9480"/></dd>
<dt>CSR:</dt>
<dd>Certificate Signing Request</dd>
<dt>EST:</dt>
<dd>Enrollment over Secure Transport <xref target="RFC7030"/></dd>
<dt>IDevID:</dt>
<dd>Initial Device Identifier (of a pledge, provided by
the manufacturer and comprising of a private key and the related X.509
certificate with its chain).</dd>
<dt>LCMPP:</dt>
<dd>Lightweight CMP Profile <xref target="RFC9483"/></dd>
<dt>LDevID:</dt>
<dd>Local Device Identifier (of a pledge, provided by
its target domain and comprising of a private key and the related X.509
certificate with its chain).</dd>
<dt>LRA:</dt>
<dd>Local Registration Authority. A subordinate RA that is close to
entities being enrolled and separate from a subsequent RA. In
BRSKI-AE, it is needed if a backend RA is used; in this case, the LRA
is co-located with the registrar.</dd>
<dt>MASA:</dt>
<dd>Manufacturer Authorized Signing Authority. Provides vouchers.</dd>
<dt>off-site:</dt>
<dd>the locality of a component, service, or functionality (such as RA
or CA) that is not at the site of the registrar. This may be a
central site or a cloud service, to which connection may be
intermittent.</dd>
<dt>on-site:</dt>
<dd>the locality of a component, service, or functionality at the site o
f
the registrar.</dd>
<dt>PKI/registrar confirm:</dt>
<dd>an acknowledgment of the PKI on the certificate confirm.</dd>
<dt>pledge:</dt>
<dd>a device that is to be bootstrapped into a target domain. It
requests an LDevID using IDevID credentials installed by its
manufacturer.</dd>
<dt>RA:</dt>
<dd>Registration Authority. The PKI component to which a CA typically
delegates certificate management functions such as authenticating
pledges and performing authorization checks on certification
requests.</dd>
<dt>registrar:</dt>
<dd>short for domain registrar.</dd>
<dt>site:</dt>
<dd>the locality where an entity such as a pledge, registrar, or PKI
component is deployed. The target domain may have multiple sites.</dd>
<dt>synchronous:</dt>
<dd>the time-wise uninterrupted delivery of messages, here, between a
pledge and a registrar or backend system (e.g., the MASA).</dd>
<dt>target domain:</dt>
<dd>the domain that a pledge is going to be bootstrapped into.</dd>
</dl>
</section>
<section anchor="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>
<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 achieved indirectly; see
<xref section="4.3" sectionFormat="comma" target="RFC4210"/>.</t>
</li>
<li>
<t>Proof of identity (also called "proof of origin"): provides data
origin authentication of the certification request. Typically, this
is achieved by a signature using the pledge IDevID secret over some
data, which needs to include a sufficiently strong identifier of the
pledge, such as the device serial number typically included in the
subject of the IDevID certificate.</t>
</li>
</ul>
<t>The remainder of this section gives a non-exhaustive list of solution
examples, based on existing technology described in IETF documents.</t>
<section anchor="solutions-PoP">
<name>Solution Options for Proof of Possession</name>
<t>Certificate Signing Request (CSR) objects are data structures
protecting only the integrity of the contained data and providing
proof of possession for a (locally generated) private key. Important
types of CSR data structures are:</t>
<ul spacing="normal">
<li>PKCS #10 <xref 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 the request.</li>
<li>Certificate Request Message Format (CRMF) <xref
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. For details, see <xref section="4"
sectionFormat="comma" 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. Yet, this signature does not provide data
origin authentication, (i.e., proof of identity of the requester)
because the key pair involved is new and therefore does not yet have a
confirmed identity associated with it.
<!-- already covered by the next paragraph: <!-- already covered by the next paragraph:
This extra property can be This extra property can be
achieved by an additional binding to the IDevID of the pledge. achieved by an additional binding to the IDevID of the pledge.
This binding to the source authentication supports the This binding to the source authentication supports the
authorization decision of the certification request. authorization decision of the certification request.
--></t> -->
</t>
</section>
<section anchor="solutions-PoI">
<name>Solution Options for Proof of Identity</name>
</section> <!-- [rfced] May we clarify the content in the parenthetical text below?
<section anchor="solutions-PoI"><name>Solution Options for Proof of Identity</na
me>
<t>Binding a certificate signing request (CSR) to an existing authenticated Original:
credential (the BRSKI context, the IDevID certificate) enables Binding a certificate signing request (CSR) to an existing
proof of origin, which in turn supports an authorization decision on the CSR.< authenticated credential (the BRSKI context, the IDevID certificate)
/t> enables proof of origin...
<t>The binding of data origin authentication to the CSR Perhaps:
is typically delegated to the protocol used for certificate management. Binding a Certificate Signing Request (CSR) to an existing
This binding may be achieved through security options in an authenticated credential (such as the BRSKI context or the IDevID certificate
underlying transport protocol such as TLS if the authorization of the )
certification request is (sufficiently) done at the next communication hop. enables proof of origin...
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 <t>Binding a Certificate Signing Request (CSR) to an existing
in various ways, such as:</t> 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>
<ul spacing="normal">
<li>
<t>EST <xref target="RFC7030"/> and its variant EST-coaps <xref
target="RFC9148"/> utilize PKCS #10 to encode CSRs. While such
a CSR has not been designed to include proof of origin, there is a
limited, indirect way of binding it to the source authentication
of the underlying TLS session. This is achieved by including in
the CSR the tls-unique value <xref target="RFC5929"/> resulting
from the TLS handshake. As this is optionally supported by the
EST <tt>"/simpleenroll"</tt> endpoint used in BRSKI, and the TLS
handshake employed in BRSKI includes certificate-based client
authentication of the pledge with its IDevID credentials, the
proof of pledge identity being an authenticated TLS client can be
bound to the CSR.</t>
<t><list style="symbols"> <!-- [rfced] FYI - For ease of the reader, we have broken up the following
<t>EST <xref target="RFC7030"/>, also its variant EST-coaps <xref target="RFC9 sentences below into two. Please let us know any objections.
148"/>,
utilizes PKCS #10 to encode Certificate Signing Requests (CSRs).
While such a CSR has not been designed
to include proof of origin, there is a limited, indirect way of
binding it to the source authentication of the underlying TLS session.
This is achieved by including in the CSR the tls-unique value <xref target="RFC5
929"/>
resulting from the TLS handshake. As this is optionally supported
by the EST <spanx style="verb">"/simpleenroll"</spanx> endpoint used in BRSKI
and the TLS handshake employed in BRSKI includes certificate-based client
authentication of the pledge with its IDevID credentials, the proof of
pledge identity being an authenticated TLS client can be bound to the CSR. <vsp
ace blankLines='1'/>
Yet this binding is only valid in the context of the TLS session
established with the registrar acting as the EST server and typically also
as an RA. So even such a cryptographic binding of the authenticated
pledge identity to the CSR is not visible nor verifiable to authorization
points outside the registrar, such as a (second) RA in the backend.
What the registrar needs to do is to authenticate and pre-authorize
the pledge and to indicate this to the (second) RA
by signing the forwarded certification request with its private key and
a related certificate that has the id-kp-cmcRA extended key usage attribute. <v
space blankLines='1'/>
<xref section="2.5" sectionFormat="comma" target="RFC7030"/> sketches wrapping P
KCS #10-formatted CSRs
with a Full PKI Request message sent to the <spanx style="verb">"/fullcmc"</span
x> 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>
<!-- 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 certificat
e
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 is
authenticate and pre-authorize the pledge and indicate this to the
(second) RA. This is done by signing the forwarded certification
request with its private key and a related certificate that has
the id-kp-cmcRA extended key usage attribute.</t>
<!--[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 <tt>"/fullcmc"</tt> endpoint. This would
allow for source authentication at the message level, such that
the registrar could forward it to external RAs in a meaningful
way. This approach is so far not sufficiently described and
likely has not been implemented.</t>
</li>
<!--
Note that, besides the existing enrollment protocols, there is Note that, besides the existing enrollment protocols, there is
ongoing work in the ACE WG to define an encapsulation of EST messages 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. in OSCORE, which will result in a TLS-independent way of protecting EST.
This approach {{draft.selander-ace-coap-est-oscore}} This approach {{draft.selander-ace-coap-est-oscore}}
may be considered as a further variant. may be considered as a further variant.
--> -->
<t><list style="symbols"> <li>
<t>SCEP <xref target="RFC8894"/> supports using a shared secret (passphrase) o <t>The Simple Certificate Enrolment Protocol (SCEP) <xref
r target="RFC8894"/> supports using a shared secret (passphrase) or
an existing certificate to protect CSRs based on an existing certificate to protect CSRs based on SCEP Secure
SCEP Secure Message Objects using CMS wrapping Message Objects using Cryptographic Message Syntax (CMS) wrapping <x
(<xref target="RFC5652"/>). Note that the wrapping using ref target="RFC5652"/>. Note
an existing IDevID in SCEP is referred to as 'renewal'. that the wrapping using an existing IDevID in SCEP is referred to
This way as "renewal". This way, SCEP does not rely on the security of the
SCEP does not rely on the security of the underlying message transfer.</t> underlying message transfer.</t>
<t>CMP <xref target="RFC4210"/> <xref target="RFC9480"/> supports using a shar </li>
ed secret (passphrase) <li>
or an existing <t>CMP <xref target="RFC4210"/> <xref target="RFC9480"/> supports
certificate, which may be an IDevID credential, to authenticate using a shared secret (passphrase) or an existing certificate,
certification requests via the PKIProtection structure in a PKIMessage. which may be an IDevID credential, to authenticate certification
The certification request is typically encoded utilizing CRMF, requests via the PKIProtection structure in a PKIMessage. The
while PKCS #10 is supported as an alternative. certification request is typically encoded utilizing CRMF, while
Thus, CMP does not rely on the security of the underlying message transfer.</t> PKCS #10 is supported as an alternative. Thus, CMP does not rely
<t>CMC <xref target="RFC5272"/> also supports utilizing a shared secret (passp on the security of the underlying message transfer.</t>
hrase) or </li>
an existing certificate to protect certification requests,
which can be either in CRMF or PKCS #10 structure.
The proof of identity can be provided as part of a FullCMCRequest,
based on CMS <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>
<t>To sum up, EST does not meet the requirements for authenticated self-containe
d
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> <!-- [rfced] We note the use of "FullCMCRequest" in the following sentence;
</section> however, RFC 7030 uses the term "Full CMC Request". May we update this instance
<section anchor="uc1"><name>Adaptations to BRSKI</name> for consistency with RFC 7030?
<t>To enable using alternative certificate enrollment protocols supporting end-t Original:
o-end The proof of identity can be provided as part of a FullCMCRequest, based on
authentication, asynchronous enrollment, and more general system architectures, CMS [RFC5652] and signed with an existing IDevID secret.
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 Perhaps:
the reuse of already defined architecture elements and interactions. The proof of identity can be provided as part of a Full CMC Request based on
In general, the communication follows the BRSKI model and utilizes the existing CMS [RFC5652] and signed with an existing IDevID secret.
BRSKI architecture elements. -->
In particular, the pledge initiates communication with the domain registrar and
interacts with the MASA as usual for voucher request and response processing.</t
>
<section anchor="architecture"><name>Architecture</name> <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 a 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>
</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>
<t>The key element of BRSKI-AE is that the authorization of a certification requ <section anchor="uc1">
est <name>Adaptations to BRSKI</name>
<bcp14>MUST</bcp14> be performed based on an authenticated self-contained object <t>To enable using alternative certificate enrollment protocols
. supporting end-to-end authentication, asynchronous enrollment, and more
The certification request is bound in a self-contained way general system architectures, BRSKI-AE provides some generalizations on
to a proof of origin based on the IDevID credentials. BRSKI <xref target="RFC8995"/>. This way, authenticated self-contained
Consequently, the certification request <bcp14>MAY</bcp14> be transferred using objects such as those described in <xref target="req-sol"/> above can be
any mechanism used for certificate enrollment, and RA functionality can be deployed
or protocol. Authentication and authorization of the certification request freely in the target domain. Parts of the RA functionality can even be
can be done by the domain registrar and/or by backend domain components. distributed over several nodes.</t>
As mentioned in <xref target="sup-env"/>, these components may be offline or off <t>The enhancements are kept to a minimum to ensure the reuse of already
-site. defined architecture elements and interactions. In general, the
The registrar and other on-site domain components communication follows the BRSKI model and utilizes the existing BRSKI
may have no or only temporary (intermittent) connectivity to them.</t> 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>
<t>This leads to generalizations in the <section anchor="architecture">
placement and enhancements of the logical elements as shown in <xref target="uc1 <name>Architecture</name>
figure"/>.</t> <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>
<figure anchor="uc1figure">
<figure title="Architecture Overview Using Backend PKI Components" anchor="uc1fi <name>Architecture Overview Using Backend PKI Components</name>
gure"><artset><artwork type="svg" align="left"><svg xmlns="http://www.w3.org/20 <artset>
00/svg" version="1.1" height="576" width="544" viewBox="0 0 544 576" class="diag <artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/
ram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lineca svg" version="1.1" height="576" width="544" viewBox="0 0 544 576" class="diagram
p="round"> " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="
<path d="M 8,208 L 8,336" fill="none" stroke="black"/> round">
<path d="M 32,48 L 32,200" fill="none" stroke="black"/> <path d="M 8,208 L 8,336" fill="none" stroke="black"/>
<path d="M 32,480 L 32,528" fill="none" stroke="black"/> <path d="M 32,48 L 32,200" fill="none" stroke="black"/>
<path d="M 80,208 L 80,336" fill="none" stroke="black"/> <path d="M 32,480 L 32,528" fill="none" stroke="black"/>
<path d="M 112,480 L 112,528" fill="none" stroke="black"/> <path d="M 80,208 L 80,336" fill="none" stroke="black"/>
<path d="M 152,240 L 152,304" fill="none" stroke="black"/> <path d="M 112,480 L 112,528" fill="none" stroke="black"/>
<path d="M 160,480 L 160,528" fill="none" stroke="black"/> <path d="M 152,240 L 152,304" fill="none" stroke="black"/>
<path d="M 216,240 L 216,304" fill="none" stroke="black"/> <path d="M 160,480 L 160,528" fill="none" stroke="black"/>
<path d="M 304,240 L 304,304" fill="none" stroke="black"/> <path d="M 216,240 L 216,304" fill="none" stroke="black"/>
<path d="M 336,32 L 336,144" fill="none" stroke="black"/> <path d="M 304,240 L 304,304" fill="none" stroke="black"/>
<path d="M 376,312 L 376,472" fill="none" stroke="black"/> <path d="M 336,32 L 336,144" fill="none" stroke="black"/>
<path d="M 424,240 L 424,304" fill="none" stroke="black"/> <path d="M 376,312 L 376,472" fill="none" stroke="black"/>
<path d="M 456,72 L 456,144" fill="none" stroke="black"/> <path d="M 424,240 L 424,304" fill="none" stroke="black"/>
<path d="M 472,152 L 472,256" fill="none" stroke="black"/> <path d="M 456,72 L 456,144" fill="none" stroke="black"/>
<path d="M 480,480 L 480,528" fill="none" stroke="black"/> <path d="M 472,152 L 472,256" fill="none" stroke="black"/>
<path d="M 536,32 L 536,144" fill="none" stroke="black"/> <path d="M 480,480 L 480,528" fill="none" stroke="black"/>
<path d="M 336,32 L 536,32" fill="none" stroke="black"/> <path d="M 536,32 L 536,144" fill="none" stroke="black"/>
<path d="M 32,48 L 144,48" fill="none" stroke="black"/> <path d="M 336,32 L 536,32" fill="none" stroke="black"/>
<path d="M 224,48 L 328,48" fill="none" stroke="black"/> <path d="M 32,48 L 144,48" fill="none" stroke="black"/>
<path d="M 336,64 L 536,64" fill="none" stroke="black"/> <path d="M 224,48 L 328,48" fill="none" stroke="black"/>
<path d="M 336,144 L 536,144" fill="none" stroke="black"/> <path d="M 336,64 L 536,64" fill="none" stroke="black"/>
<path d="M 8,208 L 80,208" fill="none" stroke="black"/> <path d="M 336,144 L 536,144" fill="none" stroke="black"/>
<path d="M 152,240 L 216,240" fill="none" stroke="black"/> <path d="M 8,208 L 80,208" fill="none" stroke="black"/>
<path d="M 304,240 L 424,240" fill="none" stroke="black"/> <path d="M 152,240 L 216,240" fill="none" stroke="black"/>
<path d="M 432,256 L 472,256" fill="none" stroke="black"/> <path d="M 304,240 L 424,240" fill="none" stroke="black"/>
<path d="M 88,272 L 144,272" fill="none" stroke="black"/> <path d="M 432,256 L 472,256" fill="none" stroke="black"/>
<path d="M 224,272 L 296,272" fill="none" stroke="black"/> <path d="M 88,272 L 144,272" fill="none" stroke="black"/>
<path d="M 152,304 L 216,304" fill="none" stroke="black"/> <path d="M 224,272 L 296,272" fill="none" stroke="black"/>
<path d="M 304,304 L 424,304" fill="none" stroke="black"/> <path d="M 152,304 L 216,304" fill="none" stroke="black"/>
<path d="M 8,336 L 80,336" fill="none" stroke="black"/> <path d="M 304,304 L 424,304" fill="none" stroke="black"/>
<path d="M 32,480 L 112,480" fill="none" stroke="black"/> <path d="M 8,336 L 80,336" fill="none" stroke="black"/>
<path d="M 160,480 L 480,480" fill="none" stroke="black"/> <path d="M 32,480 L 112,480" fill="none" stroke="black"/>
<path d="M 120,496 L 160,496" fill="none" stroke="black"/> <path d="M 160,480 L 480,480" fill="none" stroke="black"/>
<path d="M 112,512 L 152,512" fill="none" stroke="black"/> <path d="M 120,496 L 160,496" fill="none" stroke="black"/>
<path d="M 32,528 L 112,528" fill="none" stroke="black"/> <path d="M 112,512 L 152,512" fill="none" stroke="black"/>
<path d="M 160,528 L 480,528" fill="none" stroke="black"/> <path d="M 32,528 L 112,528" fill="none" stroke="black"/>
<polygon class="arrowhead" points="480,152 468,146.4 468,157.6" fill="black" tra <path d="M 160,528 L 480,528" fill="none" stroke="black"/>
nsform="rotate(270,472,152)"/> <polygon class="arrowhead" points="480,152 468,146.4 468,157.6"
<polygon class="arrowhead" points="440,256 428,250.4 428,261.6" fill="black" tra fill="black" transform="rotate(270,472,152)"/>
nsform="rotate(180,432,256)"/> <polygon class="arrowhead" points="440,256 428,250.4 428,261.6"
<polygon class="arrowhead" points="384,472 372,466.4 372,477.6" fill="black" tra fill="black" transform="rotate(180,432,256)"/>
nsform="rotate(90,376,472)"/> <polygon class="arrowhead" points="384,472 372,466.4 372,477.6"
<polygon class="arrowhead" points="384,312 372,306.4 372,317.6" fill="black" tra fill="black" transform="rotate(90,376,472)"/>
nsform="rotate(270,376,312)"/> <polygon class="arrowhead" points="384,312 372,306.4 372,317.6"
<polygon class="arrowhead" points="304,272 292,266.4 292,277.6" fill="black" tra fill="black" transform="rotate(270,376,312)"/>
nsform="rotate(0,296,272)"/> <polygon class="arrowhead" points="304,272 292,266.4 292,277.6"
<polygon class="arrowhead" points="232,272 220,266.4 220,277.6" fill="black" tra fill="black" transform="rotate(0,296,272)"/>
nsform="rotate(180,224,272)"/> <polygon class="arrowhead" points="232,272 220,266.4 220,277.6"
<polygon class="arrowhead" points="160,512 148,506.4 148,517.6" fill="black" tra fill="black" transform="rotate(180,224,272)"/>
nsform="rotate(0,152,512)"/> <polygon class="arrowhead" points="160,512 148,506.4 148,517.6"
<polygon class="arrowhead" points="152,272 140,266.4 140,277.6" fill="black" tra fill="black" transform="rotate(0,152,512)"/>
nsform="rotate(0,144,272)"/> <polygon class="arrowhead" points="152,272 140,266.4 140,277.6"
<polygon class="arrowhead" points="128,496 116,490.4 116,501.6" fill="black" tra fill="black" transform="rotate(0,144,272)"/>
nsform="rotate(180,120,496)"/> <polygon class="arrowhead" points="128,496 116,490.4 116,501.6"
<polygon class="arrowhead" points="96,272 84,266.4 84,277.6" fill="black" transf fill="black" transform="rotate(180,120,496)"/>
orm="rotate(180,88,272)"/> <polygon class="arrowhead" points="96,272 84,266.4 84,277.6" fil
<polygon class="arrowhead" points="40,200 28,194.4 28,205.6" fill="black" transf l="black" transform="rotate(180,88,272)"/>
orm="rotate(90,32,200)"/> <polygon class="arrowhead" points="40,200 28,194.4 28,205.6" fil
<g class="text"> l="black" transform="rotate(90,32,200)"/>
<text x="184" y="52">Drop-Ship</text> <g class="text">
<text x="372" y="52">Vendor</text> <text x="184" y="52">Drop-Ship</text>
<text x="432" y="52">Service</text> <text x="372" y="52">Vendor</text>
<text x="352" y="84">M</text> <text x="432" y="52">Service</text>
<text x="408" y="84">anufacturer</text> <text x="352" y="84">M</text>
<text x="352" y="100">A</text> <text x="408" y="84">anufacturer</text>
<text x="400" y="100">uthorized</text> <text x="352" y="100">A</text>
<text x="496" y="100">Ownership</text> <text x="400" y="100">uthorized</text>
<text x="352" y="116">S</text> <text x="496" y="100">Ownership</text>
<text x="388" y="116">igning</text> <text x="352" y="116">S</text>
<text x="488" y="116">Tracker</text> <text x="388" y="116">igning</text>
<text x="352" y="132">A</text> <text x="488" y="116">Tracker</text>
<text x="396" y="132">uthority</text> <text x="352" y="132">A</text>
<text x="508" y="196">BRSKI-</text> <text x="396" y="132">uthority</text>
<text x="288" y="212">.........................................</text> <text x="508" y="196">BRSKI-</text>
<text x="500" y="212">MASA</text> <text x="288" y="212">........................................
<text x="128" y="228">.</text> .</text>
<text x="448" y="228">.</text> <text x="500" y="212">MASA</text>
<text x="128" y="244">.</text> <text x="128" y="228">.</text>
<text x="448" y="244">.</text> <text x="448" y="228">.</text>
<text x="44" y="260">Pledge</text> <text x="128" y="244">.</text>
<text x="128" y="260">.</text> <text x="448" y="244">.</text>
<text x="180" y="260">Join</text> <text x="44" y="260">Pledge</text>
<text x="340" y="260">Domain</text> <text x="128" y="260">.</text>
<text x="184" y="276">Proxy</text> <text x="180" y="260">Join</text>
<text x="352" y="276">Registrar</text> <text x="340" y="260">Domain</text>
<text x="448" y="276">.</text> <text x="184" y="276">Proxy</text>
<text x="128" y="292">.</text> <text x="352" y="276">Registrar</text>
<text x="324" y="292">w/</text> <text x="448" y="276">.</text>
<text x="352" y="292">LRA</text> <text x="128" y="292">.</text>
<text x="380" y="292">or</text> <text x="324" y="292">w/</text>
<text x="404" y="292">RA</text> <text x="352" y="292">LRA</text>
<text x="448" y="292">.</text> <text x="380" y="292">or</text>
<text x="44" y="308">IDevID</text> <text x="404" y="292">RA</text>
<text x="128" y="308">.</text> <text x="448" y="292">.</text>
<text x="448" y="308">.</text> <text x="44" y="308">IDevID</text>
<text x="140" y="324">BRSKI-AE</text> <text x="128" y="308">.</text>
<text x="196" y="324">over</text> <text x="448" y="308">.</text>
<text x="232" y="324">TLS</text> <text x="140" y="324">BRSKI-AE</text>
<text x="448" y="324">.</text> <text x="196" y="324">over</text>
<text x="132" y="340">using,</text> <text x="232" y="324">TLS</text>
<text x="184" y="340">e.g.,</text> <text x="448" y="324">.</text>
<text x="232" y="340">LCMPP</text> <text x="132" y="340">using,</text>
<text x="448" y="340">.</text> <text x="184" y="340">e.g.,</text>
<text x="128" y="356">.</text> <text x="232" y="340">LCMPP</text>
<text x="448" y="356">.</text> <text x="448" y="340">.</text>
<text x="248" y="372">...............................</text> <text x="128" y="356">.</text>
<text x="416" y="372">.........</text> <text x="448" y="356">.</text>
<text x="128" y="388">on-site</text> <text x="248" y="372">...............................</text>
<text x="192" y="388">(local)</text> <text x="416" y="372">.........</text>
<text x="252" y="388">domain</text> <text x="128" y="388">on-site</text>
<text x="324" y="388">components</text> <text x="192" y="388">(local)</text>
<text x="408" y="420">e.g.,</text> <text x="252" y="388">domain</text>
<text x="456" y="420">LCMPP</text> <text x="324" y="388">components</text>
<text x="192" y="452">.............................................</text> <text x="408" y="420">e.g.,</text>
<text x="440" y="452">...............</text> <text x="456" y="420">LCMPP</text>
<text x="16" y="468">.</text> <text x="192" y="452">........................................
<text x="68" y="468">Public-Key</text> .....</text>
<text x="172" y="468">Infrastructure</text> <text x="440" y="452">...............</text>
<text x="496" y="468">.</text> <text x="16" y="468">.</text>
<text x="16" y="484">.</text> <text x="68" y="468">Public-Key</text>
<text x="496" y="484">.</text> <text x="172" y="468">Infrastructure</text>
<text x="16" y="500">.</text> <text x="496" y="468">.</text>
<text x="236" y="500">Registration</text> <text x="16" y="484">.</text>
<text x="328" y="500">Authority</text> <text x="496" y="484">.</text>
<text x="380" y="500">RA</text> <text x="16" y="500">.</text>
<text x="496" y="500">.</text> <text x="236" y="500">Registration</text>
<text x="16" y="516">.</text> <text x="328" y="500">Authority</text>
<text x="76" y="516">CA</text> <text x="380" y="500">RA</text>
<text x="216" y="516">(unless</text> <text x="496" y="500">.</text>
<text x="268" y="516">part</text> <text x="16" y="516">.</text>
<text x="300" y="516">of</text> <text x="76" y="516">CA</text>
<text x="340" y="516">Domain</text> <text x="216" y="516">(unless</text>
<text x="412" y="516">Registrar)</text> <text x="268" y="516">part</text>
<text x="496" y="516">.</text> <text x="300" y="516">of</text>
<text x="16" y="532">.</text> <text x="340" y="516">Domain</text>
<text x="496" y="532">.</text> <text x="412" y="516">Registrar)</text>
<text x="256" y="548">.......................................................... <text x="496" y="516">.</text>
...</text> <text x="16" y="532">.</text>
<text x="104" y="564">backend</text> <text x="496" y="532">.</text>
<text x="172" y="564">(central</text> <text x="256" y="548">........................................
<text x="220" y="564">or</text> .....................</text>
<text x="272" y="564">off-site)</text> <text x="104" y="564">backend</text>
<text x="340" y="564">domain</text> <text x="172" y="564">(central</text>
<text x="412" y="564">components</text> <text x="220" y="564">or</text>
</g> <text x="272" y="564">off-site)</text>
</svg> <text x="340" y="564">domain</text>
</artwork><artwork type="ascii-art" align="left"><![CDATA[ <text x="412" y="564">components</text>
</g>
</svg>
</artwork>
<artwork type="ascii-art" align="left"><![CDATA[
+------------------------+ +------------------------+
+--------------Drop-Ship--------------| Vendor Service | +--------------Drop-Ship--------------| Vendor Service |
| +------------------------+ | +------------------------+
| | M anufacturer| | | | M anufacturer| |
| | A uthorized |Ownership| | | A uthorized |Ownership|
| | S igning |Tracker | | | S igning |Tracker |
| | A uthority | | | | A uthority | |
| +--------------+---------+ | +--------------+---------+
| ^ | ^
| | | |
skipping to change at line 738 skipping to change at line 886
| e.g., LCMPP | e.g., LCMPP
| |
.............................................|............... .............................................|...............
. Public-Key Infrastructure v . . Public-Key Infrastructure v .
. +---------+ +---------------------------------------+ . . +---------+ +---------------------------------------+ .
. | |<----+ Registration Authority RA | . . | |<----+ Registration Authority RA | .
. | CA +---->| (unless part of Domain Registrar) | . . | CA +---->| (unless part of Domain Registrar) | .
. +---------+ +---------------------------------------+ . . +---------+ +---------------------------------------+ .
............................................................. .............................................................
backend (central or off-site) domain components backend (central or off-site) domain components
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>The architecture overview in <xref target="uc1figure"/> </figure>
has the same logical elements as BRSKI, but with a more flexible placement
of the authentication and authorization checks on certification requests.
Depending on the application scenario, the registrar <bcp14>MAY</bcp14> still do
all of these
checks (as is the case in BRSKI), or 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"> <t>The architecture overview in <xref target="uc1figure"/> has the
<t>Join Proxy: same requirements as in BRSKI, see <xref section="4" sectionFor same logical elements as BRSKI but with a more flexible placement of
mat="comma" target="RFC8995"/></t> the authentication and authorization checks on certification requests.
<t>Domain Registrar including LRA or RA functionality: in BRSKI-AE, Depending on the application scenario, the registrar
the domain registrar has mostly the same functionality as in BRSKI, namely <bcp14>MAY</bcp14> still do all of these checks (as is the case in
to act as the gatekeeper of the domain for onboarding new devices and BRSKI) or only do part of them.</t>
to facilitate the communication of pledges with their MASA and the domain PKI. <t>The following list describes the on-site components in the target
Yet there are some generalizations and specific requirements: <list style="numb domain of the pledge shown in <xref target="uc1figure"/>.</t>
ers"> <ul spacing="normal">
<t>The registrar <bcp14>MUST</bcp14> support at least one certificate enro <li>
llment protocol <t>Join Proxy: This has the same requirements as in BRSKI (see
with authenticated self-contained objects for certification requests. <xref section="4" sectionFormat="comma" target="RFC8995"/>).</t>
To this end, the URI scheme for addressing endpoints at the registrar </li>
is generalized (see <xref target="addressing"/>).</t>
<t>Rather than having full RA functionality, the registrar <bcp14>MAY</bcp
14> act as
a local registration authority (LRA) and delegate part of its involvement
in certificate enrollment to a backend RA.
In such scenarios, the registrar optionally checks certification requests
it receives from pledges and forwards them to the backend RA, which performs
the remaining parts of the enrollment request validation and authorization.
Note that to this end the backend RA may need information regarding
the authorization of pledges from the registrar or from other sources.
On the way back, the registrar forwards responses by the PKI
to the pledge on the same channel. <vspace blankLines='1'/>
To support end-to-end authentication of the pledge across the
registrar to the backend RA, the certification request signed by
the pledge needs to be upheld and forwarded by the registrar.
Therefore, the registrar cannot use for its communication with the PKI
an enrollment protocol that is different from
the enrollment protocol used between the pledge and the registrar.</t>
<t>The use of a certificate enrollment protocol with
authenticated self-contained objects gives freedom how to transfer
enrollment messages between the pledge and an RA.
BRSKI demands that the RA accept certification requests for LDevIDs
only with the consent of the registrar.
BRSKI-AE guarantees this also in case that the RA is not part of
the registrar, even if the message exchange with backend systems is unprotected
and involves further transport hops.
See <xref target="sec-consider"/> for details on how this can be achieved.</t>
</list></t>
</list></t>
<!-- is already covered by paragraph a little further below: <li>
<t>Domain Registrar (including LRA or RA functionality): In
BRSKI-AE, the domain registrar has mostly the same functionality
as in BRSKI, namely to act as the gatekeeper of the domain for
onboarding new devices and to facilitate the communication of
pledges with their MASA and the domain PKI. Yet, there are some
generalizations and specific requirements:</t>
<ol spacing="normal" type="1"><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 a Local Registration Authority (LRA)
and delegate part of its involvement in certificate enrollment
to a backend RA. In such scenarios, the registrar optionally
checks certification requests it receives from pledges and
forwards them to the backend RA, which performs the remaining
parts of the enrollment request validation and authorization.
Note that to this end, the backend RA may need information
regarding the authorization of pledges from the registrar or
from other sources. On the way back, the registrar forwards
responses by the PKI to the pledge on the same channel.</t>
<t>To support end-to-end authentication of the pledge across
the registrar to the backend RA, the certification request
signed by the pledge needs to be upheld and forwarded by the
registrar. Therefore, for its communication with the PKI, the
registrar cannot use an enrollment protocol that is different
from the enrollment protocol used between the pledge and the
registrar.</t>
</li>
<li>
<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 this in the case that the RA is not part of the
registrar, even if the message exchange with backend systems
is unprotected and involves further transport hops. See <xref
target="sec-consider"/> for details on how this can be
achieved.</t>
</li>
</ol>
</li>
</ul>
<!-- is already covered by paragraph a little further below:
Note: Note:
As far as (at least part of) the certificate enrollment traffic is routed 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 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 the channel that has been established in the BRSKI steps before between the
pledge and the registrar. Consequently, tunneling via this channel needs pledge and the registrar. Consequently, tunneling via this channel needs
to be supported by the certificate enrollment protocol. to be supported by the certificate enrollment protocol.
By default, this channel is based on HTTP over TLS, By default, this channel is based on HTTP over TLS,
but it may also be based on, for instance, CoAP over DTLS 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 context of Constrained BRSKI {{I-D.ietf-anima-constrained-voucher}}.
--> -->
<!-- <!--
In the latter scenario, In the latter scenario,
the EST-specific parts of that specification do not apply. the EST-specific parts of that specification do not apply.
--> -->
<t>Despite the above generalizations to the enrollment phase, the final <t>Despite the above generalizations of the enrollment phase, the final
step of BRSKI, namely the enrollment status telemetry, is kept as it is.</t> step of BRSKI, namely the enrollment status telemetry, is kept as it
is.</t>
<t>The following list describes the components provided by <t>The following list describes the components provided by the vendor
the vendor or manufacturer outside the target domain.</t> or manufacturer outside the target domain.</t>
<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 in BRSKI.</t>
<t><list style="symbols"> <!-- [rfced] In the sentence below, may we update "follows" for clarity?
<t>MASA: functionality as described in BRSKI <xref target="RFC8995"/>.
The voucher exchange with the MASA via the domain registrar
is performed as described in BRSKI. <vspace blankLines='1'/>
Note: From the definition of the interaction with the MASA in
<xref section="5" sectionFormat="comma" target="RFC8995"/> follows that it may b
e synchronous (using voucher
request with nonces) or asynchronous (using nonceless voucher requests).</t>
<t>Ownership tracker: as defined in BRSKI.</t>
</list></t>
<t>The following list describes backend target domain components, Original:
which may be located on-site or off-site in the target domain.</t> 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).
<t><list style="symbols"> Perhaps:
<t>RA: performs centralized certificate management functions Note: From the definition of the interaction with the MASA in
as a public-key infrastructure for the domain operator. Section 5 of [RFC8995], it may be synchronous (using
As far as not already done by the domain registrar, it performs the final voucher requests with nonces) or asynchronous (using nonceless
validation and authorization of certification requests. Otherwise, voucher requests).
the RA co-located with the domain registrar directly connects to the CA.</t> -->
<t>CA, also called domain CA: generates domain-specific certificates
according to certification requests that have been
authenticated and authorized by the registrar and/or an extra RA.</t>
</list></t>
<t>Based on the diagram in BRSKI <xref section="2.1" sectionFormat="comma" targe <t>Note: From the definition of the interaction with the MASA in
t="RFC8995"/> and the architectural <xref section="5" sectionFormat="comma" target="RFC8995"/> follows
changes, the original protocol flow is divided into several phases that it may be synchronous (using voucher requests with nonces) or
showing commonalities and differences to the original approach as follows.</t> asynchronous (using nonceless voucher requests).</t>
</li>
<li>
<t>Ownership Tracker: This is as defined in BRSKI.</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>
<ul spacing="normal">
<t><list style="symbols"> <!-- [rfced] How may we clarify what "as not already done" and "it" refer to
<t>Discovery phase: mostly as in BRSKI step (1). For details see <xref target= in the text below?
"discovery"/>.</t>
<t>Identification phase: same as in BRSKI step (2).</t>
<t>Voucher exchange phase: same as in BRSKI steps (3) and (4).</t>
<t>Voucher status telemetry: same as in BRSKI directly after step (4).</t>
<t>Certificate enrollment phase: the use of EST in step (5) is changed
to employing a certificate enrollment protocol that uses
an authenticated self-contained object for requesting the LDevID certificate. <
vspace blankLines='1'/>
For transporting the certificate enrollment request and response messages, the
(D)TLS channel established between pledge and registrar is <bcp14>REQUIRED</bcp
14> to use.
To this end, the enrollment protocol, the pledge, and the registrar need to supp
ort the use of this existing channel for certificate enrollment.
Due to this architecture, the pledge does not need to establish additional conne
ctions for certificate enrollment and the registrar retains full control over th
e certificate enrollment traffic.</t>
<t>Enrollment status telemetry: the final exchange of BRSKI step (5).</t>
</list></t>
</section> Original:
<section anchor="message_ex"><name>Message Exchange</name> * 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.
<t>The behavior of a pledge described in BRSKI <xref section="2.1" sectionFormat Perhaps:
="comma" target="RFC8995"/> * RA: This performs centralized certificate management functions as a
is kept, with one major exception. public-key infrastructure for the domain operator. As far as what is
After finishing the Imprint step (4), the Enroll step (5) <bcp14>MUST</bcp14> be not already done by the domain registrar, the RA performs the final
performed validation and authorization of certification requests.
with an enrollment protocol utilizing authenticated self-contained objects, -->
as explained in <xref target="req-sol"/>.
<!-- [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>
</li>
<li>
<t>CA (also called "domain CA"): This generates domain-specific
certificates according to certification requests that have been
authenticated and authorized by the registrar and/or an extra
RA.</t>
</li>
</ul>
<t>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 differences with the original approach as
follows.</t>
<ul spacing="normal">
<li>
<t>Discovery phase: This is mostly as in step (1) of <xref target="R
FC8995"/>. For details, see
<xref target="discovery"/>.</t>
</li>
<li>
<t>Identification phase: This is the same as in step (2) of <xref ta
rget="RFC8995"/>.</t>
</li>
<li>
<t>Voucher exchange phase: This is the same as in steps (3) and (4)
of <xref target="RFC8995"/>.</t>
</li>
<li>
<t>Voucher status telemetry: This is the same as directly after step
(4) in <xref target="RFC8995"/>.</t>
</li>
<li>
<t>Certificate enrollment phase: The use of EST in step (5) is
changed to employing a certificate enrollment protocol that uses
an authenticated self-contained object for requesting the LDevID
certificate.</t>
<!--[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 of step (
5) of <xref target="RFC8995"/>.</t>
</li>
</ul>
</section>
<section anchor="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 the certification request MUST be performed using an
authenticated self-contained object providing not only proof of possession authenticated self-contained object providing not only proof of possession
but also proof of identity (source authentication). but also proof of identity (source authentication).
--> -->
<xref target="exist_prot"/> discusses selected suitable enrollment protocols
and options applicable.</t>
<t>An abstract overview of the BRSKI-AE protocol <!-- [rfced] Should "options applicable" be updated to "applicable options"
can be found at <xref target="BRSKI-AE-overview"/>.</t> in the text below?
<section anchor="discovery"><name>Pledge - Registrar Discovery</name> Original:
Section 5 discusses selected suitable enrollment protocols and options
applicable.
<t>Discovery as specified in BRSKI <xref section="4" sectionFormat="comma" targe Perhaps:
t="RFC8995"/> does not support Section 5 discusses selected suitable enrollment protocols and applicable
the discovery of registrars with enhanced feature sets. options.
A pledge can not 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 <xref target="exist_prot"/> discusses selected suitable enrollment
to provide up-front information on the capabilities of registrars. protocols and options applicable.</t>
For further discussion, see <xref target="I-D.ietf-anima-brski-discovery"/>.</t> <t>An abstract overview of the BRSKI-AE protocol can be found at <xref
target="BRSKI-AE-OVERVIEW"/>.</t>
<t>In the absence of such a generally applicable solution, <section anchor="discovery">
BRSKI-AE deployments may use their particular way of doing discovery. <name>Pledge - Registrar Discovery</name>
<xref target="brski-cmp-instance"/> defines a minimalist approach that <bcp14>MA <t>Discovery as specified in BRSKI <xref section="4" sectionFormat="co
Y</bcp14> be used for CMP.</t> mma"
target="RFC8995"/> does not support the discovery of registrars with
enhanced feature sets. A pledge cannot find out in this way whether
discovered registrars support the certificate enrollment protocol it
expects, such as CMP.</t>
</section> <t>As a more general solution, the BRSKI discovery mechanism can be
<section anchor="pledge-registrar-masa-voucher-exchange"><name>Pledge - Registra extended to provide up-front information on the capabilities of
r - MASA Voucher Exchange</name> registrars. For further discussion, see <xref
target="I-D.ietf-anima-brski-discovery"/>.</t>
<t>The voucher exchange is performed as specified in <xref target="RFC8995"/>.</ <t>In the absence of such a generally applicable solution, BRSKI-AE
t> 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>
</section> <section anchor="pledge-registrar-masa-voucher-exchange">
<section anchor="pledge-registrar-masa-voucher-status-telemetry"><name>Pledge - <name>Pledge - Registrar - MASA Voucher Exchange</name>
Registrar - MASA Voucher Status Telemetry</name> <t>The voucher exchange is performed as specified in <xref
target="RFC8995"/>.</t>
</section>
<t>The voucher status telemetry is performed <section anchor="pledge-registrar-masa-voucher-status-telemetry">
as specified in <xref section="5.7" sectionFormat="comma" target="RFC8995"/>.</t <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>
</section> <!-- [rfced] As this sentence begins Section 4.2.4, may we clarify what
<section anchor="pledge-registrar-raca-certificate-enrollment"><name>Pledge - Re "This" refers to?
gistrar - RA/CA Certificate Enrollment</name>
<t>This replaces the EST integration for PKI bootstrapping described in Additionally, may we make a similar update in Appendix A.5?
<xref section="5.9" sectionFormat="comma" target="RFC8995"/>
(while <xref section="5.9.4" sectionFormat="comma" target="RFC8995"/> remains as
the final phase, see below).</t>
<t>The certificate enrollment phase may involve the transmission of several mess Original:
ages. 4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
Details can depend on the application scenario,
the employed enrollment protocol, and other factors. 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...
-->
<section anchor="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 final 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> <!-- <br>
In line with the generalizations described in {{architecture}}, In line with the generalizations described in {{architecture}},
It is RECOMMENDED to transfer these messages It is RECOMMENDED to transfer these messages
via the channel established between the pledge and the registrar. via the channel established between the pledge and the registrar.
-->
</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>The only message exchange <bcp14>REQUIRED</bcp14> is for <t>Note: The message exchanges marked <bcp14>OPTIONAL</bcp14> in
the actual certification request and response. <xref target="enrollfigure"/> below cover all those supported by the
Further message exchanges <bcp14>MAY</bcp14> be performed as needed.</t> use of EST in BRSKI. The last <bcp14>OPTIONAL</bcp14> one, namely
certificate confirmation, is not supported by EST but by CMP and
other enrollment protocols.</t>
<t>Note: <figure anchor="enrollfigure">
The message exchanges marked <bcp14>OPTIONAL</bcp14> in the below <xref target=" <name>Certificate Enrollment Message Flow</name>
enrollfigure"/> <artset>
cover all those supported by the use of EST in BRSKI. <artwork type="svg" align="left">
The last <bcp14>OPTIONAL</bcp14> one, namely certificate confirmation, <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="576
is not supported by EST, but by CMP and other enrollment protocols.</t> " width="560" viewBox="0 0 560 576" class="diagram" text-anchor="middle" font-fa
mily="monospace" font-size="13px" stroke-linecap="round">
<figure title="Certificate Enrollment Message Flow" anchor="enrollfigure"><artse <path d="M 8,32 L 8,96" fill="none" stroke="black"/>
t><artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/svg" vers <path d="M 16,104 L 16,560" fill="none" stroke="black"/>
ion="1.1" height="576" width="560" viewBox="0 0 560 576" class="diagram" text-an <path d="M 64,32 L 64,96" fill="none" stroke="black"/>
chor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 280,32 L 280,96" fill="none" stroke="black"/>
<path d="M 8,32 L 8,96" fill="none" stroke="black"/> <path d="M 320,104 L 320,560" fill="none" stroke="black"/>
<path d="M 16,104 L 16,560" fill="none" stroke="black"/> <path d="M 360,32 L 360,96" fill="none" stroke="black"/>
<path d="M 64,32 L 64,96" fill="none" stroke="black"/> <path d="M 480,32 L 480,96" fill="none" stroke="black"/>
<path d="M 280,32 L 280,96" fill="none" stroke="black"/> <path d="M 544,104 L 544,560" fill="none" stroke="black"/>
<path d="M 320,104 L 320,560" fill="none" stroke="black"/> <path d="M 552,32 L 552,96" fill="none" stroke="black"/>
<path d="M 360,32 L 360,96" fill="none" stroke="black"/> <path d="M 8,32 L 64,32" fill="none" stroke="black"/>
<path d="M 480,32 L 480,96" fill="none" stroke="black"/> <path d="M 280,32 L 360,32" fill="none" stroke="black"/>
<path d="M 544,104 L 544,560" fill="none" stroke="black"/> <path d="M 480,32 L 552,32" fill="none" stroke="black"/>
<path d="M 552,32 L 552,96" fill="none" stroke="black"/> <path d="M 8,96 L 64,96" fill="none" stroke="black"/>
<path d="M 8,32 L 64,32" fill="none" stroke="black"/> <path d="M 280,96 L 360,96" fill="none" stroke="black"/>
<path d="M 280,32 L 360,32" fill="none" stroke="black"/> <path d="M 480,96 L 552,96" fill="none" stroke="black"/>
<path d="M 480,32 L 552,32" fill="none" stroke="black"/> <path d="M 24,144 L 72,144" fill="none" stroke="black"/>
<path d="M 8,96 L 64,96" fill="none" stroke="black"/> <path d="M 256,144 L 312,144" fill="none" stroke="black"/>
<path d="M 280,96 L 360,96" fill="none" stroke="black"/> <path d="M 328,176 L 344,176" fill="none" stroke="black"/>
<path d="M 480,96 L 552,96" fill="none" stroke="black"/> <path d="M 496,176 L 536,176" fill="none" stroke="black"/>
<path d="M 24,144 L 72,144" fill="none" stroke="black"/> <path d="M 328,192 L 344,192" fill="none" stroke="black"/>
<path d="M 256,144 L 312,144" fill="none" stroke="black"/> <path d="M 504,192 L 536,192" fill="none" stroke="black"/>
<path d="M 328,176 L 344,176" fill="none" stroke="black"/> <path d="M 24,208 L 72,208" fill="none" stroke="black"/>
<path d="M 496,176 L 536,176" fill="none" stroke="black"/> <path d="M 264,208 L 312,208" fill="none" stroke="black"/>
<path d="M 328,192 L 344,192" fill="none" stroke="black"/> <path d="M 24,272 L 72,272" fill="none" stroke="black"/>
<path d="M 504,192 L 536,192" fill="none" stroke="black"/> <path d="M 264,272 L 312,272" fill="none" stroke="black"/>
<path d="M 24,208 L 72,208" fill="none" stroke="black"/> <path d="M 328,304 L 344,304" fill="none" stroke="black"/>
<path d="M 264,208 L 312,208" fill="none" stroke="black"/> <path d="M 504,304 L 536,304" fill="none" stroke="black"/>
<path d="M 24,272 L 72,272" fill="none" stroke="black"/> <path d="M 328,320 L 344,320" fill="none" stroke="black"/>
<path d="M 264,272 L 312,272" fill="none" stroke="black"/> <path d="M 512,320 L 536,320" fill="none" stroke="black"/>
<path d="M 328,304 L 344,304" fill="none" stroke="black"/> <path d="M 24,336 L 72,336" fill="none" stroke="black"/>
<path d="M 504,304 L 536,304" fill="none" stroke="black"/> <path d="M 272,336 L 312,336" fill="none" stroke="black"/>
<path d="M 328,320 L 344,320" fill="none" stroke="black"/> <path d="M 24,384 L 72,384" fill="none" stroke="black"/>
<path d="M 512,320 L 536,320" fill="none" stroke="black"/> <path d="M 296,384 L 312,384" fill="none" stroke="black"/>
<path d="M 24,336 L 72,336" fill="none" stroke="black"/> <path d="M 328,416 L 344,416" fill="none" stroke="black"/>
<path d="M 272,336 L 312,336" fill="none" stroke="black"/> <path d="M 520,416 L 536,416" fill="none" stroke="black"/>
<path d="M 24,384 L 72,384" fill="none" stroke="black"/> <path d="M 328,432 L 344,432" fill="none" stroke="black"/>
<path d="M 296,384 L 312,384" fill="none" stroke="black"/> <path d="M 520,432 L 536,432" fill="none" stroke="black"/>
<path d="M 328,416 L 344,416" fill="none" stroke="black"/> <path d="M 24,448 L 64,448" fill="none" stroke="black"/>
<path d="M 520,416 L 536,416" fill="none" stroke="black"/> <path d="M 296,448 L 312,448" fill="none" stroke="black"/>
<path d="M 328,432 L 344,432" fill="none" stroke="black"/> <path d="M 24,496 L 72,496" fill="none" stroke="black"/>
<path d="M 520,432 L 536,432" fill="none" stroke="black"/> <path d="M 280,496 L 312,496" fill="none" stroke="black"/>
<path d="M 24,448 L 64,448" fill="none" stroke="black"/> <path d="M 328,528 L 344,528" fill="none" stroke="black"/>
<path d="M 296,448 L 312,448" fill="none" stroke="black"/> <path d="M 512,528 L 536,528" fill="none" stroke="black"/>
<path d="M 24,496 L 72,496" fill="none" stroke="black"/> <path d="M 328,544 L 344,544" fill="none" stroke="black"/>
<path d="M 280,496 L 312,496" fill="none" stroke="black"/> <path d="M 456,544 L 536,544" fill="none" stroke="black"/>
<path d="M 328,528 L 344,528" fill="none" stroke="black"/> <path d="M 24,560 L 72,560" fill="none" stroke="black"/>
<path d="M 512,528 L 536,528" fill="none" stroke="black"/> <path d="M 296,560 L 312,560" fill="none" stroke="black"/>
<path d="M 328,544 L 344,544" fill="none" stroke="black"/> <polygon class="arrowhead" points="544,528 532,522.4 532,533.6
<path d="M 456,544 L 536,544" fill="none" stroke="black"/> " fill="black" transform="rotate(0,536,528)"/>
<path d="M 24,560 L 72,560" fill="none" stroke="black"/> <polygon class="arrowhead" points="544,416 532,410.4 532,421.6
<path d="M 296,560 L 312,560" fill="none" stroke="black"/> " fill="black" transform="rotate(0,536,416)"/>
<polygon class="arrowhead" points="544,528 532,522.4 532,533.6" fill="black" tra <polygon class="arrowhead" points="544,304 532,298.4 532,309.6
nsform="rotate(0,536,528)"/> " fill="black" transform="rotate(0,536,304)"/>
<polygon class="arrowhead" points="544,416 532,410.4 532,421.6" fill="black" tra <polygon class="arrowhead" points="544,176 532,170.4 532,181.6
nsform="rotate(0,536,416)"/> " fill="black" transform="rotate(0,536,176)"/>
<polygon class="arrowhead" points="544,304 532,298.4 532,309.6" fill="black" tra <polygon class="arrowhead" points="336,544 324,538.4 324,549.6
nsform="rotate(0,536,304)"/> " fill="black" transform="rotate(180,328,544)"/>
<polygon class="arrowhead" points="544,176 532,170.4 532,181.6" fill="black" tra <polygon class="arrowhead" points="336,432 324,426.4 324,437.6
nsform="rotate(0,536,176)"/> " fill="black" transform="rotate(180,328,432)"/>
<polygon class="arrowhead" points="336,544 324,538.4 324,549.6" fill="black" tra <polygon class="arrowhead" points="336,320 324,314.4 324,325.6
nsform="rotate(180,328,544)"/> " fill="black" transform="rotate(180,328,320)"/>
<polygon class="arrowhead" points="336,432 324,426.4 324,437.6" fill="black" tra <polygon class="arrowhead" points="336,192 324,186.4 324,197.6
nsform="rotate(180,328,432)"/> " fill="black" transform="rotate(180,328,192)"/>
<polygon class="arrowhead" points="336,320 324,314.4 324,325.6" fill="black" tra <polygon class="arrowhead" points="320,496 308,490.4 308,501.6
nsform="rotate(180,328,320)"/> " fill="black" transform="rotate(0,312,496)"/>
<polygon class="arrowhead" points="336,192 324,186.4 324,197.6" fill="black" tra <polygon class="arrowhead" points="320,384 308,378.4 308,389.6
nsform="rotate(180,328,192)"/> " fill="black" transform="rotate(0,312,384)"/>
<polygon class="arrowhead" points="320,496 308,490.4 308,501.6" fill="black" tra <polygon class="arrowhead" points="320,272 308,266.4 308,277.6
nsform="rotate(0,312,496)"/> " fill="black" transform="rotate(0,312,272)"/>
<polygon class="arrowhead" points="320,384 308,378.4 308,389.6" fill="black" tra <polygon class="arrowhead" points="320,144 308,138.4 308,149.6
nsform="rotate(0,312,384)"/> " fill="black" transform="rotate(0,312,144)"/>
<polygon class="arrowhead" points="320,272 308,266.4 308,277.6" fill="black" tra <polygon class="arrowhead" points="32,560 20,554.4 20,565.6" f
nsform="rotate(0,312,272)"/> ill="black" transform="rotate(180,24,560)"/>
<polygon class="arrowhead" points="320,144 308,138.4 308,149.6" fill="black" tra <polygon class="arrowhead" points="32,448 20,442.4 20,453.6" f
nsform="rotate(0,312,144)"/> ill="black" transform="rotate(180,24,448)"/>
<polygon class="arrowhead" points="32,560 20,554.4 20,565.6" fill="black" transf <polygon class="arrowhead" points="32,336 20,330.4 20,341.6" f
orm="rotate(180,24,560)"/> ill="black" transform="rotate(180,24,336)"/>
<polygon class="arrowhead" points="32,448 20,442.4 20,453.6" fill="black" transf <polygon class="arrowhead" points="32,208 20,202.4 20,213.6" f
orm="rotate(180,24,448)"/> ill="black" transform="rotate(180,24,208)"/>
<polygon class="arrowhead" points="32,336 20,330.4 20,341.6" fill="black" transf <g class="text">
orm="rotate(180,24,336)"/> <text x="36" y="52">Pledge</text>
<polygon class="arrowhead" points="32,208 20,202.4 20,213.6" fill="black" transf <text x="308" y="52">Domain</text>
orm="rotate(180,24,208)"/> <text x="516" y="52">Operator</text>
<g class="text"> <text x="320" y="68">Registrar</text>
<text x="36" y="52">Pledge</text> <text x="504" y="68">RA/CA</text>
<text x="308" y="52">Domain</text> <text x="304" y="84">(JRC)</text>
<text x="516" y="52">Operator</text> <text x="504" y="84">(PKI)</text>
<text x="320" y="68">Registrar</text> <text x="56" y="132">[OPTIONAL</text>
<text x="504" y="68">RA/CA</text> <text x="128" y="132">request</text>
<text x="304" y="84">(JRC)</text> <text x="172" y="132">of</text>
<text x="504" y="84">(PKI)</text> <text x="196" y="132">CA</text>
<text x="56" y="132">[OPTIONAL</text> <text x="264" y="132">certificates]</text>
<text x="128" y="132">request</text> <text x="92" y="148">CA</text>
<text x="172" y="132">of</text> <text x="128" y="148">Certs</text>
<text x="196" y="132">CA</text> <text x="184" y="148">Request</text>
<text x="264" y="132">certificates]</text> <text x="232" y="148">(1)</text>
<text x="92" y="148">CA</text> <text x="368" y="164">[OPTIONAL</text>
<text x="128" y="148">Certs</text> <text x="456" y="164">forwarding]</text>
<text x="184" y="148">Request</text> <text x="364" y="180">CA</text>
<text x="232" y="148">(1)</text> <text x="400" y="180">Certs</text>
<text x="368" y="164">[OPTIONAL</text> <text x="456" y="180">Request</text>
<text x="456" y="164">forwarding]</text> <text x="364" y="196">CA</text>
<text x="364" y="180">CA</text> <text x="400" y="196">Certs</text>
<text x="400" y="180">Certs</text> <text x="460" y="196">Response</text>
<text x="456" y="180">Request</text> <text x="92" y="212">CA</text>
<text x="364" y="196">CA</text> <text x="128" y="212">Certs</text>
<text x="400" y="196">Certs</text> <text x="188" y="212">Response</text>
<text x="460" y="196">Response</text> <text x="240" y="212">(2)</text>
<text x="92" y="212">CA</text> <text x="56" y="244">[OPTIONAL</text>
<text x="128" y="212">Certs</text> <text x="128" y="244">request</text>
<text x="188" y="212">Response</text> <text x="172" y="244">of</text>
<text x="240" y="212">(2)</text> <text x="228" y="244">attributes</text>
<text x="56" y="244">[OPTIONAL</text> <text x="36" y="260">to</text>
<text x="128" y="244">request</text> <text x="80" y="260">include</text>
<text x="172" y="244">of</text> <text x="124" y="260">in</text>
<text x="228" y="244">attributes</text> <text x="192" y="260">Certification</text>
<text x="36" y="260">to</text> <text x="284" y="260">Request]</text>
<text x="80" y="260">include</text> <text x="120" y="276">Attribute</text>
<text x="124" y="260">in</text> <text x="192" y="276">Request</text>
<text x="192" y="260">Certification</text> <text x="240" y="276">(3)</text>
<text x="284" y="260">Request]</text> <text x="368" y="292">[OPTIONAL</text>
<text x="120" y="276">Attribute</text> <text x="456" y="292">forwarding]</text>
<text x="192" y="276">Request</text> <text x="392" y="308">Attribute</text>
<text x="240" y="276">(3)</text> <text x="464" y="308">Request</text>
<text x="368" y="292">[OPTIONAL</text> <text x="392" y="324">Attribute</text>
<text x="456" y="292">forwarding]</text> <text x="468" y="324">Response</text>
<text x="392" y="308">Attribute</text> <text x="120" y="340">Attribute</text>
<text x="464" y="308">Request</text> <text x="196" y="340">Response</text>
<text x="392" y="324">Attribute</text> <text x="248" y="340">(4)</text>
<text x="468" y="324">Response</text> <text x="56" y="372">[REQUIRED</text>
<text x="120" y="340">Attribute</text> <text x="152" y="372">certification</text>
<text x="196" y="340">Response</text> <text x="244" y="372">request]</text>
<text x="248" y="340">(4)</text> <text x="136" y="388">Certification</text>
<text x="56" y="372">[REQUIRED</text> <text x="224" y="388">Request</text>
<text x="152" y="372">certification</text> <text x="272" y="388">(5)</text>
<text x="244" y="372">request]</text> <text x="368" y="404">[OPTIONAL</text>
<text x="136" y="388">Certification</text> <text x="456" y="404">forwarding]</text>
<text x="224" y="388">Request</text> <text x="400" y="420">Certification</text>
<text x="272" y="388">(5)</text> <text x="488" y="420">Request</text>
<text x="368" y="404">[OPTIONAL</text> <text x="400" y="436">Certification</text>
<text x="456" y="404">forwarding]</text> <text x="480" y="436">Resp.</text>
<text x="400" y="420">Certification</text> <text x="128" y="452">Certification</text>
<text x="488" y="420">Request</text> <text x="220" y="452">Response</text>
<text x="400" y="436">Certification</text> <text x="272" y="452">(6)</text>
<text x="480" y="436">Resp.</text> <text x="56" y="484">[OPTIONAL</text>
<text x="128" y="452">Certification</text> <text x="144" y="484">certificate</text>
<text x="220" y="452">Response</text> <text x="248" y="484">confirmation]</text>
<text x="272" y="452">(6)</text> <text x="128" y="500">Certificate</text>
<text x="56" y="484">[OPTIONAL</text> <text x="208" y="500">Confirm</text>
<text x="144" y="484">certificate</text> <text x="256" y="500">(7)</text>
<text x="248" y="484">confirmation]</text> <text x="368" y="516">[OPTIONAL</text>
<text x="128" y="500">Certificate</text> <text x="456" y="516">forwarding]</text>
<text x="208" y="500">Confirm</text> <text x="400" y="532">Certificate</text>
<text x="256" y="500">(7)</text> <text x="480" y="532">Confirm</text>
<text x="368" y="516">[OPTIONAL</text> <text x="368" y="548">PKI</text>
<text x="456" y="516">forwarding]</text> <text x="416" y="548">Confirm</text>
<text x="400" y="532">Certificate</text> <text x="136" y="564">PKI/Registrar</text>
<text x="480" y="532">Confirm</text> <text x="224" y="564">Confirm</text>
<text x="368" y="548">PKI</text> <text x="272" y="564">(8)</text>
<text x="416" y="548">Confirm</text> </g>
<text x="136" y="564">PKI/Registrar</text> </svg>
<text x="224" y="564">Confirm</text> </artwork>
<text x="272" y="564">(8)</text> <artwork type="ascii-art" align="left"><![CDATA[
</g>
</svg>
</artwork><artwork type="ascii-art" align="left"><![CDATA[
+------+ +---------+ +--------+ +------+ +---------+ +--------+
|Pledge| |Domain | |Operator| |Pledge| |Domain | |Operator|
| | |Registrar| |RA/CA | | | |Registrar| |RA/CA |
| | |(JRC) | |(PKI) | | | |(JRC) | |(PKI) |
+------+ +---------+ +--------+ +------+ +---------+ +--------+
| | | | | |
|[OPTIONAL request of CA certificates]| | |[OPTIONAL request of CA certificates]| |
|------- CA Certs Request (1) ------->| | |------- CA Certs Request (1) ------->| |
| | [OPTIONAL forwarding] | | | [OPTIONAL forwarding] |
| |--- CA Certs Request ----->| | |--- CA Certs Request ----->|
skipping to change at line 1104 skipping to change at line 1461
| |---Certification Request-->| | |---Certification Request-->|
| |<--Certification Resp. ---| | |<--Certification Resp. ---|
|<----- Certification Response (6) ---| | |<----- Certification Response (6) ---| |
| | | | | |
|[OPTIONAL certificate confirmation] | | |[OPTIONAL certificate confirmation] | |
|------- Certificate Confirm (7) ---->| | |------- Certificate Confirm (7) ---->| |
| | [OPTIONAL forwarding] | | | [OPTIONAL forwarding] |
| |--- Certificate Confirm--->| | |--- Certificate Confirm--->|
| |<-- PKI Confirm -----------| | |<-- PKI Confirm -----------|
|<------ PKI/Registrar Confirm (8) ---| | |<------ PKI/Registrar Confirm (8) ---| |
]]></artwork></artset></figure> ]]></artwork>
</artset>
<t>It may be noted that connections between the registrar and the PKI components </figure>
of the operator (RA, CA, etc.) may be intermittent or off-line. <t>It may be noted that connections between the registrar and the PKI
components
of the operator (RA, CA, etc.) may be intermittent or offline.
Messages should be sent as soon as sufficient transfer capacity is available.</t > Messages should be sent as soon as sufficient transfer capacity is available.</t >
<t>The label <tt>[OPTIONAL forwarding]</tt> in <xref target="enrollfig
<t>The label <spanx style="verb">[OPTIONAL forwarding]</spanx> in <xref target=" ure"/>
enrollfigure"/> means that on receiving a request message of the given type from a pledge,
means that on receiving from a pledge a request message of the given type,
the registrar <bcp14>MAY</bcp14> answer the request directly. the registrar <bcp14>MAY</bcp14> answer the request directly.
In this case, it <bcp14>MUST</bcp14> authenticate its responses with the same cr edentials In this case, it <bcp14>MUST</bcp14> authenticate its responses with the same cr edentials
as used for authenticating itself at the TLS level for the voucher exchange. 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 Otherwise, the registrar <bcp14>MUST</bcp14> forward the request to the RA
and forward any resulting response back to the pledge.</t> 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 dep end <t>The decision of whether to forward a request or to answer it directly can dep end
on various static and dynamic factors. They include the application scenario, on various static and dynamic factors. They include the application scenario,
the capabilities of the registrar and of the local RA possibly co-located the capabilities of the registrar and of the local RA possibly co-located
with the registrar, the enrollment protocol being used, and the specific with the registrar, the enrollment protocol being used, and the specific
contents of the request.</t> contents of the request.</t>
<t>Note that <t>Note that there are several options for how the registrar could be able to di
there are several options for how the registrar could be able to directly answer rectly answer
requests for CA certificates or for certification request attributes. requests for CA certificates or for certification request attributes.
It could cache responses obtained from the domain PKI and It could cache responses obtained from the domain PKI and
later use their contents for responding to requests asking for the same data. later use their contents for responding to requests asking for the same data.
The contents could also be explicitly provisioned at the registrar.</t> The contents could also be explicitly provisioned at the registrar.</t>
<t>Further note that <t>Further note that certification requests typically need to be handled by the
certification requests typically need to be handled by the backend PKI, backend PKI,
but the registrar can answer them directly with an error response but the registrar can answer them directly with an error response
in case it determines that such a request should be rejected, in case it determines that such a request should be rejected,
for instance, because is not properly authenticated or not authorized.<!--br--> for instance, because it is not properly authenticated or authorized.<!--br-->
Also, certificate confirmation messages Also, certificate confirmation messages
will usually be forwarded to the backend PKI, will usually be forwarded to the backend PKI,
but if the registrar knows that they are not needed or wanted there but if the registrar knows that they are not needed or wanted there,
it can acknowledge such messages directly.</t> it can acknowledge such messages directly.</t>
<t>The following list provides an abstract description of the flow <t>The following list provides an abstract description of the flow
depicted in <xref target="enrollfigure"/>.</t> depicted in <xref target="enrollfigure"/>.</t>
<ul spacing="normal">
<t><list style="symbols">
<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>
<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>
<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
include in the Certification Request (5) additional attributes that are
specific to the target domain. To get these attributes in
advance, the attribute request may be used.</t>
<t>Attribute Response (4): This <bcp14>MUST</bcp14> contain the attributes req
uested in (3)
to be included in the subsequent Certification Request (5). <vspace blankLines=
'1'/>
For example, <xref section="6.11.7.2" sectionFormat="comma" target="RFC8994"/> s
pecifies
how the attribute request is used to signal to the pledge
the acp-node-name field required for enrollment into an ACP domain.</t>
<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>
<t>Certification Response (6): This <bcp14>MUST</bcp14> contain on success
the requested certificate and <bcp14>MAY</bcp14> include further information,
like certificates of intermediate CAs and any additional trust anchors.</t>
<t>Certificate Confirm (7): An optional confirmation sent
after the requested certificate has been received and validated.
If sent, it <bcp14>MUST</bcp14> contain a positive or negative confirmation by t
he pledge to
the PKI whether the certificate was successfully enrolled and fits its needs.</t
>
<t>PKI/Registrar Confirm (8): An acknowledgment by the PKI
that <bcp14>MUST</bcp14> be sent on reception of the Certificate Confirm.</t>
</list></t>
<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 <li>
described above is independent of the mandatory enrollment status telemetry <t>CA Certs Request (1): The pledge optionally requests the latest
done between the pledge and the registrar in the final phase of BRSKI-AE, relevant
described next.</t> 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 int
ermediate 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
include additional attributes
that are specific to the target domain in the Certification Reques
t (5). To get these attributes
in advance, the attribute request may be used.</t>
</li>
</section> <li>
<section anchor="pledge-registrar-enrollment-status-telemetry"><name>Pledge - Re <t>Attribute Response (4): This <bcp14>MUST</bcp14> contain the
gistrar Enrollment Status Telemetry</name> attributes requested in (3) to be included in the subsequent
Certification Request (5).</t>
<t>The enrollment status telemetry is performed <t>For example, <xref section="6.11.7.2" sectionFormat="comma"
as specified in <xref section="5.9.4" sectionFormat="comma" target="RFC8995"/>.< target="RFC8994"/> specifies how the attribute request is used
/t> to signal to the pledge the acp-node-name field required for
enrollment into an Autonomic Control Plane (ACP) domain.</t>
</li>
<t>In BRSKI this is described as part of the certificate enrollment step, but <li>
due to the generalization on the enrollment protocol described in this document <t>Certification Request (5): This <bcp14>MUST</bcp14> contain
it is regarded as a separate phase here.</t> 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): On success, this <bcp14>MUST</bcp14
> contain
the requested certificate and <bcp14>MAY</bcp14>
include further information, like certificates of intermediate
CAs and any additional trust anchors.</t>
</li>
<li>
<t>Certificate Confirm (7): This is an optional confirmation that
is sent after
the requested certificate has been received and validated. If
sent, it <bcp14>MUST</bcp14> contain a positive or negative
confirmation by the pledge to the PKI whether the certificate
was successfully enrolled and fits its needs.</t>
</li>
<li>
<t>PKI/Registrar Confirm (8): This is an acknowledgment by the PKI
that
<bcp14>MUST</bcp14> be sent on reception of the Certificate
Confirm.</t>
</li>
</ul>
<t>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>
</section> <t>Note that the optional certificate confirmation by the pledge to
</section> the PKI described above is independent of the mandatory enrollment
<section anchor="addressing"><name>Enhancements to the Endpoint Addressing Schem status telemetry done between the pledge and the registrar in the
e of BRSKI</name> final phase of BRSKI-AE, which is described next.</t>
</section>
<t>BRSKI-AE extends the addressing scheme outlined in <xref section="5" sectionF <section anchor="pledge-registrar-enrollment-status-telemetry">
ormat="comma" target="RFC8995"/>, <name>Pledge - Registrar Enrollment Status Telemetry</name>
to support alternative enrollment protocols that utilize authenticated, <t>The enrollment status telemetry is performed as specified in
self-contained objects for certification requests -- see also <xref target="exis <xref section="5.9.4" sectionFormat="comma" target="RFC8995"/>.</t>
t_prot"/>). <t>In BRSKI, this is described as part of the certificate enrollment
These extensions are designed to be compatible with existing Registration step, but due to the generalization of the enrollment protocol
Authorities (RAs) and Certification Authorities (CAs) that already support such described in this document, it is regarded as a separate phase
enrollment protocols, enabling their use without requiring any modifications.</t here.</t>
> </section>
</section>
<t>The addressing scheme in BRSKI for certification requests and <section anchor="addressing">
the related CA certificates and CSR attributes retrieval functions <name>Enhancements to the Endpoint Addressing Scheme of BRSKI</name>
uses the definition from EST <xref target="RFC7030"/>. <t>BRSKI-AE extends the addressing scheme outlined in <xref
Here is the example of simple enrollment: <spanx style="verb">"/.well-known/est/ section="5" sectionFormat="comma" target="RFC8995"/> to support
simpleenroll"</spanx>. alternative enrollment protocols that utilize authenticated,
This approach is generalized to the following notation: self-contained objects for certification requests (also see <xref
<spanx style="verb">"/.well-known/&lt;enrollment-protocol&gt;/&lt;request&gt;"</ target="exist_prot"/>). These extensions are designed to be
spanx> compatible with existing Registration Authorities (RAs) and
in which <spanx style="verb">&lt;enrollment-protocol&gt;</spanx> refers to a cer Certification Authorities (CAs) that already support such enrollment
tificate enrollment protocol. protocols, enabling their use without requiring any modifications.</t>
Note that enrollment is considered here a message sequence <t>The addressing scheme in BRSKI for certification requests,
that contains at least a certification request and a certification response. related CA certificates, and CSR attributes retrieval functions uses the
The following conventions are used to provide maximal compatibility with BRSKI:< definition from EST <xref target="RFC7030"/>. An example of
/t> simple enrollment is: <tt>"/.well-known/est/simpleenroll"</tt>. This
approach is generalized to the following notation:
<tt>"/.well-known/&lt;enrollment-protocol&gt;/&lt;request&gt;"</tt> in
which <tt>&lt;enrollment-protocol&gt;</tt> refers to a certificate
enrollment protocol. Note that here, enrollment is considered a
message sequence that contains at least a certification request and a
certification response. The following conventions are used to provide
maximal compatibility with BRSKI:</t>
<ul spacing="normal">
<li>
<t><tt>&lt;enrollment-protocol&gt;</tt>: This <bcp14>MUST</bcp14>
reference the protocol being used. Existing values include
'<tt>est</tt>' <xref target="RFC7030"/> as in BRSKI and
'<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 as newly defined
protocols, are outside the scope of this document. For use of the
<tt>&lt;enrollment-protocol&gt;</tt> and <tt>&lt;request&gt;</tt>
URI components, they would need to be specified in a suitable RFC
and placed into the "Well-Known URIs" registry, just as EST in <xref
target="RFC7030"/>.</t>
</li>
<li>
<t><tt>&lt;request&gt;</tt>: If present, this path component
<bcp14>MUST</bcp14> describe the operation requested depending on
the enrollment protocol being used. Enrollment protocols are
expected to define their request endpoints, as is done by existing
protocols (also see <xref target="exist_prot"/>).</t>
</li>
</ul>
<!-- ## Domain Registrar Support of Alternative Enrollment Protocols -->
<t><list style="symbols"> <t>Well-known URIs for various endpoints on the domain registrar are
<t><spanx style="verb">&lt;enrollment-protocol&gt;</spanx>: <bcp14>MUST</bcp14 already defined as part of the base BRSKI specification or indirectly
> reference the protocol being used. by EST. In addition, alternative enrollment endpoints
Existing values include '<spanx style="verb">est</spanx>' <xref target="RFC7030" <bcp14>MAY</bcp14> be supported by the registrar.</t>
/> as in BRSKI and '<spanx style="verb">cmp</spanx>' as in
<xref target="RFC9483"/> and <xref target="brski-cmp-instance"/> below.
Values for other existing protocols such as CMC and SCEP,
as well as for newly defined protocols are outside the scope of this document.
For use of the <spanx style="verb">&lt;enrollment-protocol&gt;</spanx> and <span
x style="verb">&lt;request&gt;</spanx> URI components,
they would need to be specified in a suitable RFC and
placed into the Well-Known URIs registry, just as EST in <xref target="RFC7030"/
>.</t>
<t><spanx style="verb">&lt;request&gt;</spanx>: if present, this path componen
t <bcp14>MUST</bcp14> describe,
depending on the enrollment protocol being used, the operation requested.
Enrollment protocols are expected to define their request endpoints,
as done by existing protocols (see also <xref target="exist_prot"/>).</t>
</list></t>
<!-- ## Domain Registrar Support of Alternative Enrollment Protocols --> <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 domain registrar. This is done by
sending the request to the respective endpoint according to the above
addressing scheme and then evaluating the HTTP status code of the
response. If the pledge uses endpoints that are not standardized, it
risks that the registrar does not recognize a request and thus may
reject it even if the registrar supports the intended protocol and
operation.</t>
<t>Well-known URIs for various endpoints on the domain registrar are <t>The following list of endpoints provides an illustrative example of
already defined as part of the base BRSKI specification or indirectly by EST. a domain registrar supporting several options for EST as well as for
In addition, alternative enrollment endpoints <bcp14>MAY</bcp14> be supported by CMP to be used in BRSKI-AE. The listing contains the supported
the registrar.</t> 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>
<t>A pledge <bcp14>SHOULD</bcp14> use the endpoints defined for the enrollment p <!--[rfced] Should the following artwork element be reformatted as
rotocol(s) a bulleted list, per text from the preceding paragraph?
that it can use.
It will recognize whether the protocol it uses and the specific request it wants
to perform are understood and supported by the domain registrar
by sending the request to the respective endpoint according to the above
addressing scheme and then evaluating the HTTP status code of the response.
If the pledge uses endpoints that are not standardized,
it risks that the registrar does not recognize a request and thus may reject it,
even if the registrar supports the intended protocol and operation.</t>
<t>The following list of endpoints provides an illustrative example of Original:
a domain registrar supporting several options for EST as well as for The following list of endpoints provides an illustrative example of a
CMP to be used in BRSKI-AE. The listing contains the supported domain registrar supporting several options for EST as well as for
endpoints to which the pledge may connect for bootstrapping. This CMP to be used in BRSKI-AE.
includes the voucher handling as well as the enrollment endpoints. ...
The CMP-related enrollment endpoints are defined as well-known URIs /.well-known/brski/voucherrequest
in CMP Updates <xref target="RFC9480"/> and the Lightweight CMP Profile <xref ta /.well-known/brski/voucher_status
rget="RFC9483"/>.</t> /.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
-->
<figure><artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
/.well-known/brski/voucherrequest /.well-known/brski/voucherrequest
/.well-known/brski/voucher_status /.well-known/brski/voucher_status
/.well-known/brski/enrollstatus /.well-known/brski/enrollstatus
/.well-known/est/cacerts /.well-known/est/cacerts
/.well-known/est/csrattrs /.well-known/est/csrattrs
/.well-known/est/fullcmc /.well-known/est/fullcmc
/.well-known/cmp/getcacerts /.well-known/cmp/getcacerts
/.well-known/cmp/getcertreqtemplate /.well-known/cmp/getcertreqtemplate
/.well-known/cmp/initialization /.well-known/cmp/initialization
/.well-known/cmp/pkcs10 /.well-known/cmp/pkcs10
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="exist_prot">
<section anchor="exist_prot"><name>Instantiation with Existing Enrollment Protoc <name>Instantiation with Existing Enrollment Protocols</name>
ols</name> <t>This section maps the generic requirements to support proof of possessi
on
<t>This section maps the generic requirements to support proof of possession
and proof of identity to selected existing certificate enrollment protocols and proof of identity to selected existing certificate enrollment protocols
and specifies further aspects of using such enrollment protocols in BRSKI-AE.</t > and specifies further aspects of using such enrollment protocols in BRSKI-AE.</t >
<section anchor="brski-cmp-instance">
<section anchor="brski-cmp-instance"><name>BRSKI-CMP: BRSKI-AE instantiated with <name>BRSKI-CMP: BRSKI-AE Instantiated with CMP</name>
CMP</name> <t>In this document, references to CMP follow the Lightweight CMP Profil
e (LCMPP)
<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 <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> defined in LCMPP sufficiently meets the required functionality.</t>
<t>Adherence to the LCMPP <xref target="RFC9483"/> is <bcp14>REQUIRED</b
<t>Adherence to the LCMPP <xref target="RFC9483"></xref> is <bcp14>REQUIRED</bcp cp14> when using CMP.
14> when using CMP.
The following specific requirements apply (refer to <xref target="enrollfigure"/ >):</t> The following specific requirements apply (refer to <xref target="enrollfigure"/ >):</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The validation of server response messages performed by the CMP client <t>The validation of server response messages performed by the CMP
within the pledge <bcp14>MUST</bcp14> be based on the trust anchor established b client within the pledge <bcp14>MUST</bcp14> be based on the trust
eforehand anchor established beforehand via the BRSKI voucher, i.e., on the
via the BRSKI voucher, i.e., on the pinned-domain-cert. <vspace blankLines='1'/ pinned-domain-cert.</t>
> <t>Note that the integrity and authenticity checks on the RA/CA by
Note that the integrity and authenticity checks on the RA/CA the CMP client can be stronger than for EST because they do not
by the CMP client can be stronger than for EST because need to be performed hop-by-hop but are usually end-to-end.</t>
they do not need to be performed hop-by-hop, but are usually end-to-end.</t> </li>
<t>CA Certs Request (1) and Response (2):<br /> <li>
Requesting CA certificates is <bcp14>OPTIONAL</bcp14>.<br /> <t>CA Certs Request (1) and Response (2): Requesting CA
If supported, it <bcp14>SHALL</bcp14> be implemented as specified in certificates is <bcp14>OPTIONAL</bcp14>. If supported, it
<xref section="4.3.1" sectionFormat="comma" target="RFC9483"/>.</t> <bcp14>SHALL</bcp14> be implemented as specified in <xref
<t>Attribute Request (3) and Response (4):<br /> section="4.3.1" sectionFormat="comma" target="RFC9483"/>.</t>
Requesting certification request attributes is <bcp14>OPTIONAL</bcp14>.<br /> </li>
If supported, it <bcp14>SHALL</bcp14> be implemented as specified in <li>
<xref section="4.3.3" sectionFormat="comma" target="RFC9483"/>. <vspace blankLi <t>Attribute Request (3) and Response (4): Requesting
nes='1'/> certification request attributes is <bcp14>OPTIONAL</bcp14>. If
Alternatively, the registrar <bcp14>MAY</bcp14> modify supported, it <bcp14>SHALL</bcp14> be implemented as specified in
the requested certificate contents <xref section="4.3.3" sectionFormat="comma" target="RFC9483"/>.</t>
as specified in <xref section="5.2.3.2" sectionFormat="comma" target="RFC9483"/> <t>Alternatively, the registrar <bcp14>MAY</bcp14> modify the
.</t> requested certificate contents as specified in <xref
<t>Certification Request (5) and Response (6):<br /> section="5.2.3.2" sectionFormat="comma" target="RFC9483"/>.</t>
Certificates <bcp14>SHALL</bcp14> be requested and provided </li>
as specified in LCMPP <li>
<xref section="4.1.1" sectionFormat="comma" target="RFC9483"/> (based on CRMF) o <t>Certification Request (5) and Response (6): Certificates
r <bcp14>SHALL</bcp14> be requested and provided as specified in
<xref section="4.1.4" sectionFormat="comma" target="RFC9483"/> (based on PKCS #1 LCMPP <xref section="4.1.1" sectionFormat="comma"
0). <vspace blankLines='1'/> target="RFC9483"/> (based on CRMF) or <xref section="4.1.4"
Proof of possession <bcp14>SHALL</bcp14> be provided in a manner suitable for th sectionFormat="comma" target="RFC9483"/> (based on PKCS #10).
e key type. </t>
Proof of identity <bcp14>SHALL</bcp14> be provided by signature-based <t>
protection of the certification request message Proof of possession <bcp14>SHALL</bcp14> be provided in a manner
as outlined in <xref section="3.2" sectionFormat="comma" target="RFC9483"/>, usi suitable for the key type. Proof of identity
ng the IDevID secret. <vspace blankLines='1'/> <bcp14>SHALL</bcp14> be provided by signature-based protection
When the registrar forwards a certification request from the pledge to of the certification request message as outlined in <xref
a backend RA/CA, it is <bcp14>RECOMMENDED</bcp14> that the registrar wraps the o section="3.2" sectionFormat="comma" target="RFC9483"/> using
riginal the IDevID secret.</t>
certification request in a nested message signed with its own credentials, <t>
as described in <xref section="5.2.2.1" sectionFormat="comma" target="RFC9483"/> When the registrar forwards a certification request from the
. pledge to a backend RA/CA, it is <bcp14>RECOMMENDED</bcp14> that
This approach explicitly conveys the registrar's consent to the RA the registrar wraps the original certification request in a
while retaining the original certification request nested message signed with its own credentials, as described in
with the proof of origin provided by the pledge's signature. <vspace blankLines <xref section="5.2.2.1" sectionFormat="comma"
='1'/> target="RFC9483"/>. This approach explicitly conveys the
If additional trust anchors, beyond the pinned-domain-cert, registrar's consent to the RA while retaining the original
need to be conveyed to the pledge, certification request with the proof of origin provided by the
this <bcp14>SHOULD</bcp14> be done in the <spanx style="verb">caPubs</spanx> fie pledge's signature. </t>
ld of the certification response <t>
rather than through a CA Certs Response.</t> If additional trust anchors beyond the pinned-domain-cert need
<t>Certificate Confirm (7) and PKI/Registrar Confirm (8):<br /> to be conveyed to the pledge, this <bcp14>SHOULD</bcp14> be done
Explicit confirmation of new certificates to the RA/CA in the <tt>caPubs</tt> field of the certification response
<bcp14>MAY</bcp14> be used as specified in <xref section="4.1.1" sectionFormat=" rather than through a CA Certs Response.</t>
comma" target="RFC9483"/>. <vspace blankLines='1'/> </li>
Note that independent of the certificate confirmation within CMP, <li>
enrollment status telemetry with the registrar at the BRSKI level <t>Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit
will be performed as described in <xref section="5.9.4" sectionFormat="comma" ta confirmation of new certificates to the RA/CA <bcp14>MAY</bcp14>
rget="RFC8995"/>.</t> be used as specified in <xref section="4.1.1"
<t>If delayed delivery of CMP messages is needed sectionFormat="comma" target="RFC9483"/>.</t>
(e.g., to support enrollment over an asynchronous channel), <t>Note that independent of the certificate confirmation within
it <bcp14>SHALL</bcp14> be performed as specified in CMP, enrollment status telemetry with the registrar at the BRSKI
Section <xref target="RFC9483" section="4.4" sectionFormat="bare"/> and Section level will be performed as described in <xref section="5.9.4"
<xref target="RFC9483" section="5.1.2" sectionFormat="bare"/> of <xref target="R sectionFormat="comma" target="RFC8995"/>.</t>
FC9483"/>.</t> </li>
</list></t> <li>
<t>If delayed delivery of CMP messages is needed (e.g., to support
<t>The mechanisms for exchanging messages between the registrar and backend PKI enrollment over an asynchronous channel), it <bcp14>SHALL</bcp14>
components (i.e., RA and/or CA) are outside the scope of this document. be performed as specified in Sections <xref target="RFC9483"
CMP's independence from the message transfer mechanism allows for flexibility section="4.4" sectionFormat="bare"/> and <xref
in choosing the appropriate exchange method based on the application scenario. target="RFC9483" section="5.1.2" sectionFormat="bare"/> of <xref
For the applicable security and privacy considerations, target="RFC9483"/>.</t>
refer to <xref target="sec-consider"/> and <xref target="priv-consider"/>. </li>
Further guidance can be found in <xref section="6" sectionFormat="comma" target= </ul>
"RFC9483"/>.</t> <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 <xref target="sec-consider" fo
rmat="counter"/> and
<xref target="priv-consider" format="counter"/>. Further guidance can b
e found in
<xref section="6" sectionFormat="comma" target="RFC9483"/>.</t>
<!--
CMP Updates {{RFC9480}} and CMP Updates {{RFC9480}} and
the LCMPP {{RFC9483}} the LCMPP {{RFC9483}}
provide requirements for interoperability. provide requirements for interoperability.
--> -->
<t>BRSKI-AE with CMP can also be combined with <t>BRSKI-AE with CMP can also be combined with Constrained BRSKI <xref
Constrained BRSKI <xref target="I-D.ietf-anima-constrained-voucher"/>, target="I-D.ietf-anima-constrained-voucher"/>, using CoAP for
using CoAP for enrollment message transport as described by enrollment message transport as described by CoAP Transfer for CMP <xref
CoAP Transport for CMP <xref target="RFC9482"/>. target="RFC9482"/>. In such scenarios, the EST-specific parts
In such scenarios, the EST-specific parts of <xref target="I-D.ietf-anima-constrained-voucher"/> do not
of <xref target="I-D.ietf-anima-constrained-voucher"/> do not apply.</t> 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:
perform discovery as defined in BRSKI <xref section="B" sectionFormat="comma" ta
rget="RFC8995"/>, but use
the service name <spanx style="verb">"brski-reg-cmp"</spanx> (as defined in <xre
f target="iana-consider"/>)
instead of <spanx style="verb">"brski-registrar"</spanx> (as defined in <xref se
ction="8.6" sectionFormat="comma" target="RFC8995"/>).
Note that this approach does not support join proxies.</t>
</section> <t>For BRSKI-AE scenarios where a general solution for discovering
<section anchor="support-of-other-enrollment-protocols"><name>Support of Other E registrars with CMP support is not available (cf. <xref
nrollment Protocols</name> target="discovery"/>), the following minimalist approach
<bcp14>MAY</bcp14> be used: Perform discovery as defined in BRSKI <xref
target="RFC8995" sectionFormat="comma" section="B"/>, but use the servic
e
name <tt>"brski-reg-cmp"</tt> (as defined in <xref
target="iana-consider"/>) instead of <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>
<t>Further instantiations of BRSKI-AE can be done. They are left for future wor <section anchor="support-of-other-enrollment-protocols">
k.</t> <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 authent <t>In particular, CMC <xref target="RFC5272"/> (using its in-band
ication options) source authentication options) and SCEP <xref target="RFC8894"/>
and SCEP <xref target="RFC8894"/> (using its 'renewal' option) could be used.</t (using its 'renewal' option) could be used.</t>
>
<t>The fullCMC variant of EST sketched in <xref section="2.5" sectionFormat="com <t>The fullCMC variant of EST sketched in <xref section="2.5"
ma" target="RFC7030"/> sectionFormat="comma" target="RFC7030"/> might also be used here. For
might also be used here. For EST-fullCMC further specification is necessary. EST-fullCMC, further specification is necessary.
<!-- <!--
Yet most likely it will not be followed up Yet most likely it will not be followed up
because, by now, no implementations of this EST variant are known, 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. and no reasons are known why it could be preferable over using BRSKI-CMP.
-->
<!-- </t>
<!--
## BRSKI-EST-fullCMC: Application to EST ## BRSKI-EST-fullCMC: Application to EST
When using EST {{RFC7030}}, the following aspects and constraints When using EST {{RFC7030}}, the following aspects and constraints
need to be considered and the given extra requirements need to be fulfilled, need to be considered and the given extra requirements need to be fulfilled,
which adapt BRSKI {{RFC8995, Section 5.9.3}}: which adapt BRSKI {{RFC8995, Section 5.9.3}}:
* Proof of possession is provided typically by using the specified PKCS #10 * Proof of possession is provided typically by using the specified PKCS #10
structure in the request. structure in the request.
Together with Full PKI requests, also CRMF can be used. Together with Full PKI requests, also CRMF can be used.
skipping to change at line 1424 skipping to change at line 1874
<!-- <!--
Note that the work in the ACE WG described in Note that the work in the ACE WG described in
{{draft-selander-ace-coap-est-oscore}} may be considered here as well, {{draft-selander-ace-coap-est-oscore}} may be considered here as well,
as it also addresses the encapsulation of EST in a way that as it also addresses the encapsulation of EST in a way that
makes it independent of the underlying TLS channel using OSCORE, makes it independent of the underlying TLS channel using OSCORE,
which also entails that authenticated self-contained objects are used. which also entails that authenticated self-contained objects are used.
--> -->
</section> </section>
</section> </section>
<section anchor="iana-consider"><name>IANA Considerations</name> <section anchor="iana-consider">
<name>IANA Considerations</name>
<t>This document requires one IANA action: register in the <t>IANA has registered the following service name in the <eref
<eref target="https://www.iana.org/assignments/service-names-port-numbers/servic target="https://www.iana.org/assignments/service-names-port-numbers/servic
e-names-port-numbers.xhtml">Service Name and Transport Protocol Port Number Regi e-names-port-numbers.xhtml" brackets="angle">"Service
stry</eref> Name and Transport Protocol Port Number Registry"</eref>.</t>
the following service name.</t> <dl spacing="compact" newline="false">
<dt>Service Name:</dt><dd>brski-reg-cmp</dd>
<t><strong>Service Name:</strong> brski-reg-cmp<br /> <dt>Transport Protocol(s):</dt><dd>tcp</dd>
<strong>Transport Protocol(s):</strong> tcp<br /> <dt>Description:</dt><dd>Bootstrapping Remote Secure Key
<strong>Assignee:</strong> IESG <eref target="mailto:iesg@ietf.org">iesg@ietf.or Infrastructure registrar with CMP capabilities according to the
g</eref><br /> Lightweight CMP Profile (LCMPP) <xref target="RFC9483"/></dd>
<strong>Contact:</strong> IETF <eref target="mailto:chair@ietf.org">chair@ietf.o <dt>Assignee:</dt><dd>IESG <eref target="mailto:iesg@ietf.org">iesg@ietf
rg</eref><br /> .org</eref></dd>
<strong>Description:</strong> Bootstrapping Remote Secure Key Infrastructure reg <dt>Contact:</dt><dd>IETF <eref target="mailto:chair@ietf.org">chair@iet
istrar with f.org</eref></dd>
CMP capabilities according to the Lightweight CMP Profile (LCMPP, <xref target=" <dt>Reference:</dt><dd>RFC 9733</dd>
RFC9483"/>)<br /> </dl>
<strong>Reference:</strong> [THISRFC]</t> <t>Note: We chose the suffix "cmp" here rather than some other
abbreviation like "lcmpp" mainly because this document defines the
<t>Note: normative CMP instantiation of BRSKI-AE, which implies adherence to
We chose here the suffix "cmp" rather than some other abbreviation like "lcmpp" LCMPP is necessary and sufficient.</t>
mainly because this document defines the normative CMP instantiation of </section>
BRSKI-AE, which implies adherence to LCMPP is necessary and sufficient.</t>
</section>
<section anchor="sec-consider"><name>Security Considerations</name>
<t>The security considerations laid out in BRSKI <xref section="11" sectionForma
t="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 this pertains also to obtaining a valid domain-specific certificate,
it must be made sure that a pledge can not circumvent the registrar
in the decision of whether it is granted an LDevID certificate by the CA.
There are various ways how to fulfill this, including:</t>
<t><list style="symbols">
<t>implicit consent</t>
<t>the registrar signals its consent to the RA out-of-band before or during
the enrollment phase, for instance by entering the pledge identity in a database
.</t>
<t>the registrar provides its consent using an extra message that is transferr
ed
on the same channel as the enrollment messages, possibly in a TLS tunnel.</t>
<t>the registrar explicitly states its consent by signing, in addition to the
pledge,
the authenticated self-contained certificate enrollment request message.</t>
</list></t>
<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 in the
LCMPP <xref target="RFC9483"/> apply.</t>
</section>
<section anchor="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 turn 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 encry
pted.
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 <section anchor="sec-consider">
for their input and discussion on use cases and call flows.</t> <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 this also
pertains to obtaining a valid domain-specific certificate, it must
be made sure that a pledge cannot circumvent the registrar in the
decision of whether it is granted an LDevID certificate by the CA.
There are various ways to fulfill this, including:</t>
<t>Moreover, <ul spacing="normal">
we thank Toerless Eckert (document shepherd), <li>
Barry Leiba (SECdir review), <t>implicit consent;</t>
Mahesh Jethanandani (IETF area director), </li>
Meral Shirazipour (Gen-ART reviewer), <li>
Reshad Rahman (YANGDOCTORS reviewer), <t>the registrar signaling its consent to the RA out-of-band before or
Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Danyliw, during the enrollment phase, for instance, by entering the pledge
and Éric Vyncke (IESG reviewers), identity in a database;</t>
Michael Richardson (ANIMA design team member), </li>
as well as Rajeev Ranjan, Rufus Buschart, <li>
Andreas Reiter, and Szofia Fazekas-Zisch (Siemens colleagues) <t>the registrar providing its consent using an extra message that is
for their reviews with suggestions for improvements.</t> transferred on the same channel as the enrollment messages, possibly
in a TLS tunnel; and</t>
</li>
<li>
<t>the registrar explicitly stating its consent by signing the
authenticated self-contained certificate enrollment request 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 in LCMPP <xref t
arget="RFC9483"/> apply.</t>
</section>
</section> <section anchor="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. In 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>
</middle> </middle>
<back> <back>
<references title='Normative References' anchor="sec-normative-references"> <displayreference target="I-D.ietf-anima-brski-discovery" to="BRSKI-DISCOVERY"/>
<displayreference target="I-D.ietf-anima-constrained-voucher" to="cBRSKI"/>
<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 re
vocation list (CRL) for use in the Internet. An overview of this approach and mo
del is provided as an introduction. The X.509 v3 certificate format is described
in detail, with additional information regarding the format and semantics of In
ternet name forms. Standard certificate extensions are described and two Interne
t-specific extensions are defined. A set of required certificate extensions is s
pecified. The X.509 v2 CRL format is described in detail along with standard and
Internet-specific extensions. An algorithm for X.509 certification path validat
ion 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 us
ing manufacturer-installed X.509 certificates, in combination with a manufacture
r's authorizing service, both online and offline. We call this process the Boots
trapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new
device can occur when using a routable address and a cloud service, only link-lo
cal connectivity, or limited/disconnected networks. Support for deployment model
s with less stringent security requirements is included. Bootstrapping is comple
te 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 manageme
nt operations covering typical use cases of industrial and Internet of Things (I
oT) scenarios. This is achieved by profiling the Certificate Management Protocol
(CMP), the related Certificate Request Message Format (CRMF), and transfer base
d on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficien
tly detailed and self-contained way. To make secure certificate management for s
imple scenarios and constrained devices as lightweight as possible, only the mos
t crucial types of operations and options are specified as mandatory. More speci
alized 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>
<reference anchor="IEEE_802.1AR-2018" target="https://ieeexplore.ieee.org/docume
nt/8423794">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Secure Devic
e Identity</title>
<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 docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument 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 specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE 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>
</references>
<references title='Informative References' anchor="sec-informative-reference
s">
<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 of a domain owner. This protocol is designed for
constrained networks, which may have limited data throughput or may
experience frequent packet loss. cBRSKI is a variant of the BRSKI
protocol, which uses an artifact signed by the device manufacturer
called the &quot;voucher&quot; which enables a new device and the owner&#x27;
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> <references>
</abstract> <name>References</name>
</front> <references anchor="sec-normative-references">
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher <name>Normative References</name>
-25"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
995.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
483.xml"/>
</reference> <!-- [IEEE_802.1AR-2018] -->
<reference anchor="IEEE_802.1AR-2018" target="https://ieeexplore.ieee.or
g/document/8423794">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Secu
re Device Identity</title>
<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="BRSKI-AE-overview" > <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>BRSKI-AE Protocol Overview</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author initials="" surname="S.&nbsp;Fries" fullname="S.&nbsp;Fries"> 174.xml"/>
<organization></organization>
</author>
<author initials="D." surname="von&nbsp;Oheimb">
<organization></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"> </references>
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</tit
le>
<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 Laborato
ries' Public-Key Cryptography Standards (PKCS) series, and change control is ret
ained within the PKCS process. The body of this document, except for the securit
y considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #1
0 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"> <references anchor="sec-informative-references">
<front> <name>Informative References</name>
<title>Internet X.509 Public Key Infrastructure Certificate Management Proto
col (CMP)</title>
<author fullname="C. Adams" initials="C." surname="Adams"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="T. Kause" initials="T." surname="Kause"/>
<author fullname="T. Mononen" initials="T." surname="Mononen"/>
<date month="September" year="2005"/>
<abstract>
<t>This document describes the Internet X.509 Public Key Infrastructure (P
KI) Certificate Management Protocol (CMP). Protocol messages are defined for X.5
09v3 certificate creation and management. CMP provides on-line interactions betw
een 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"> <!-- [I-D.ietf-anima-constrained-voucher] IESG State: I-D Exists as of 10/28/202
<front> 4; WG State: In WG Last Call as of 10/28/2024 -->
<title>Internet X.509 Public Key Infrastructure Certificate Request Message <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
Format (CRMF)</title> .ietf-anima-constrained-voucher.xml"/>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="September" year="2005"/>
<abstract>
<t>This document describes the Certificate Request Message Format (CRMF) s
yntax and semantics. This syntax is used to convey a request for a certificate t
o a Certification Authority (CA), possibly via a Registration Authority (RA), fo
r the purposes of X.509 certificate production. The request will typically inclu
de a public key and the associated registration information. This document does
not define a certificate request protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4211"/>
<seriesInfo name="DOI" value="10.17487/RFC4211"/>
</reference>
<reference anchor="RFC5272"> <reference anchor="BRSKI-AE-OVERVIEW" target="https://datatracker.ietf.o
<front> rg/meeting/116/materials/slides-116-anima-update-on-brski-ae-alternative-enrollm
<title>Certificate Management over CMS (CMC)</title> ent-protocols-in-brski-00">
<author fullname="J. Schaad" initials="J." surname="Schaad"/> <front>
<author fullname="M. Myers" initials="M." surname="Myers"/> <title>Update on BRSKI-AE: Alternative Enrollment Protocols in BRSKI
<date month="June" year="2008"/> </title>
<abstract> <author initials="D." surname="von Oheimb" fullname="David von Oheim
<t>This document defines the base syntax for CMC, a Certificate Management b" role="editor">
protocol using the Cryptographic Message Syntax (CMS). This protocol addresses <organization/>
two immediate needs within the Internet Public Key Infrastructure (PKI) communit </author>
y:</t> <author initials="S." surname="Fries" fullname="Steffen Fries">
<t>1. The need for an interface to public key certification products and s <organization/>
ervices based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t> </author>
<t>2. The need for a PKI enrollment protocol for encryption only keys due <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhau
to algorithm or hardware design.</t> s">
<t>CMC also requires the use of the transport document and the requirement <organization/>
s usage document along with this document for a full definition. [STANDARDS-TRAC </author>
K]</t> <date year="2023" month="March"/>
</abstract> </front>
</front> <refcontent>IETF 116 - ANIMA Working Group Presentation</refcontent>
<seriesInfo name="RFC" value="5272"/> </reference>
<seriesInfo name="DOI" value="10.17487/RFC5272"/>
</reference>
<reference anchor="RFC5652"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 986.xml"/>
<title>Cryptographic Message Syntax (CMS)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="R. Housley" initials="R." surname="Housley"/> 210.xml"/>
<date month="September" year="2009"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<abstract> 211.xml"/>
<t>This document describes the Cryptographic Message Syntax (CMS). This sy <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
ntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messa 272.xml"/>
ge content. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</abstract> 652.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name="STD" value="70"/> 929.xml"/>
<seriesInfo name="RFC" value="5652"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<seriesInfo name="DOI" value="10.17487/RFC5652"/> 955.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
030.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
366.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
894.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
994.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
148.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
480.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
482.xml"/>
<reference anchor="RFC5929"> <!-- TH TODO: The normative references for the 2017 version do not
<front> include RFC 8894 (SCEP). Rather, they reference the SCEP Internet-Draft. RFC
<title>Channel Bindings for TLS</title> 8894 is referenced in the 2023 version.-->
<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 S
ecurity (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in a
ccordance 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"> <reference anchor="IEC-62351-9" target="https://webstore.iec.ch/en/publi
<front> cation/30287">
<title>Diffie-Hellman Proof-of-Possession Algorithms</title> <front>
<author fullname="J. Schaad" initials="J." surname="Schaad"/> <title>Power systems management and associated information exchange
<author fullname="H. Prafullchandra" initials="H." surname="Prafullchandra"/ - Data and communications security - Part 9: Cyber security key management for p
> ower system equipment</title>
<date month="May" year="2013"/> <author>
<abstract> <organization>International Electrotechnical Commission</organizat
<t>This document describes two methods for producing an integrity check va ion>
lue from a Diffie-Hellman key pair and one method for producing an integrity che </author>
ck value from an Elliptic Curve key pair. This behavior is needed for such opera <date year="2017" month="May"/>
tions as creating the signature of a Public-Key Cryptography Standards (PKCS) #1 </front>
0 Certification Request. These algorithms are designed to provide a Proof-of-Pos <seriesInfo name="IEC" value="62351-9:2017"/>
session of the private key and not to be a general purpose signing algorithm.</t </reference>
>
<t>This document obsoletes RFC 2875.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6955"/>
<seriesInfo name="DOI" value="10.17487/RFC6955"/>
</reference>
<reference anchor="RFC7030"> <!-- XML for 2023 version of [IEC-62351-9]:
<front> <reference anchor="IEC-62351-9" target="https://webstore.iec.ch/en/publi
<title>Enrollment over Secure Transport</title> cation/66864">
<author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin <front>
"/> <title>Power systems management and associated information exchange
<author fullname="P. Yee" initials="P." role="editor" surname="Yee"/> - Data and communications security - Part 9: Cyber security key management for p
<author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/ ower system equipment</title>
> <author>
<date month="October" year="2013"/> <organization>International Electrotechnical Commission</organizat
<abstract> ion>
<t>This document profiles certificate enrollment for clients using Certifi </author>
cate Management over CMS (CMC) messages over a secure transport. This profile, c <date year="2023" month="June"/>
alled Enrollment over Secure Transport (EST), describes a simple, yet functional </front>
, certificate management protocol targeting Public Key Infrastructure (PKI) clie <seriesInfo name="IEC" value="62351-9:2023"/>
nts that need to acquire client certificates and associated Certification Author </reference>
ity (CA) certificates. It also supports client-generated public/private key pair -->
s 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"> <reference anchor="NERC-CIP-005-5" target="">
<front> <front>
<title>A Voucher Artifact for Bootstrapping Protocols</title> <title>Cyber Security - Electronic Security Perimeter</title>
<author fullname="K. Watsen" initials="K." surname="Watsen"/> <author>
<author fullname="M. Richardson" initials="M." surname="Richardson"/> <organization>North American Electric Reliability Council</organiz
<author fullname="M. Pritikin" initials="M." surname="Pritikin"/> ation>
<author fullname="T. Eckert" initials="T." surname="Eckert"/> </author>
<date month="May" year="2018"/> <date year="2013" month="December"/>
<abstract> </front>
<t>This document defines a strategy to securely assign a pledge to an owne <seriesInfo name="CIP" value="005-5"/>
r using an artifact signed, directly or indirectly, by the pledge's manufacturer </reference>
. This artifact is known as a "voucher".</t>
<t>This document defines an artifact format as a YANG-defined JSON documen
t that has been signed using a Cryptographic Message Syntax (CMS) structure. Oth
er YANG-derived formats are possible. The voucher artifact is normally generated
by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authori
ty (MASA)).</t>
<t>This document only defines the voucher artifact, leaving it to other do
cuments 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"> <!-- [ISO-IEC-15118-2] Note to PE: The correct series number for this
<front> reference is "ISO 15118-2:2014", rather than "ISO/IEC 15118-2". Although some
<title>Simple Certificate Enrolment Protocol</title> sources say this reference is also an IEC doc (for example:
<author fullname="P. Gutmann" initials="P." surname="Gutmann"/> https://en.wikipedia.org/wiki/ISO_15118) the correct SDO is simply ISO. It may
<date month="September" year="2020"/> be a good idea to update the cite tag to [ISO-15118-2], since I was unable to
<abstract> find any versions of this reference which mention IEC. -->
<t>This document specifies the Simple Certificate Enrolment Protocol (SCEP
), a PKI protocol that leverages existing technology by using Cryptographic Mess
age Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the
evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wid
e support in both client and server implementations, as well as being relied upo
n 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"> <reference anchor="ISO-IEC-15118-2" target="https://www.iso.org/standard
<front> /55366.html">
<title>An Autonomic Control Plane (ACP)</title> <front>
<author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/> <title>Road vehicles - Vehicle-to-Grid Communication Interface - Par
<author fullname="M. Behringer" initials="M." role="editor" surname="Behring t 2: Network and application protocol requirements</title>
er"/> <author>
<author fullname="S. Bjarnason" initials="S." surname="Bjarnason"/> <organization>International Organization for Standardization</orga
<date month="May" year="2021"/> nization>
<abstract> </author>
<t>Autonomic functions need a control plane to communicate, which depends <date year="2014" month="April"/>
on some addressing and routing. This Autonomic Control Plane should ideally be s </front>
elf-managing and be as independent as possible of configuration. This document d <seriesInfo name="ISO" value="15118-2:2014"/>
efines such a plane and calls it the "Autonomic Control Plane", with the primary </reference>
use as a control plane for autonomic functions. It also serves as a "virtual ou
t-of-band channel" for Operations, Administration, and Management (OAM) communic
ations over a network that provides automatically configured, hop-by-hop authent
icated 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"> <!-- [UNISIG-Subset-137]
<front>
<title>EST-coaps: Enrollment over Secure Transport with the Secure Constrain
ed 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 provisi
oning protocol over HTTPS. Low-resource devices often use the lightweight Constr
ained Application Protocol (CoAP) for message exchanges. This document defines h
ow to transport EST payloads over secure CoAP (EST-coaps), which allows constrai
ned devices to use existing EST functionality for provisioning certificates.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9148"/>
<seriesInfo name="DOI" value="10.17487/RFC9148"/>
</reference>
<reference anchor="RFC9480"> For RE/PE during AUTH 48 - Updated XML for [UNISIG-Subset-137]:
<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 Ma
nagement Protocol (CMP) version 2 and its HTTP transfer mechanism. This document
updates RFCs 4210, 5912, and 6712.</t>
<t>The aspects of CMP updated in this document are using EnvelopedData ins
tead of EncryptedValue, clarifying the handling of p10cr messages, improving the
crypto agility, as well as adding new general message types, extended key usage
s to identify certificates for use with CMP, and well-known URI path segments.</
t>
<t>CMP version 3 is introduced to enable signaling support of EnvelopedDat
a instead of EncryptedValue and signal the use of an explicit hash AlgorithmIden
tifier in certConf messages, as far as needed.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9480"/>
<seriesInfo name="DOI" value="10.17487/RFC9480"/>
</reference>
<reference anchor="RFC9482"> <reference anchor="UNISIG-Subset-137" target="">
<front> <front>
<title>Constrained Application Protocol (CoAP) Transfer for the Certificate <title>ERTMS/ETCS On-line Key Management FFFIS</title>
Management Protocol</title> <author>
<author fullname="M. Sahni" initials="M." role="editor" surname="Sahni"/> <organization>UNISIG</organization>
<author fullname="S. Tripathi" initials="S." role="editor" surname="Tripathi </author>
"/> <date year="2023" month="May"/>
<date month="November" year="2023"/> </front>
<abstract> <refcontent>Subset-137, Version 4.0.0</refcontent>
<t>This document specifies the use of the Constrained Application Protocol </reference>
(CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). C
MP defines the interaction between various PKI entities for the purpose of certi
ficate creation and management. CoAP is an HTTP-like client-server protocol used
by various constrained devices in the Internet of Things space.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9482"/>
<seriesInfo name="DOI" value="10.17487/RFC9482"/>
</reference>
<reference anchor="IEC-62351-9" > -->
<front>
<title>IEC 62351 - Power systems management and associated information excha
nge - Data and communications security - Part 9: Cyber security key management f
or power system equipment</title>
<author >
<organization>International Electrotechnical Commission</organization>
</author>
<date year="2017" month="May"/>
</front>
<seriesInfo name="IEC" value="62351-9 "/>
</reference>
<reference anchor="NERC-CIP-005-5" >
<front>
<title>Cyber Security - Electronic Security Perimeter</title>
<author >
<organization>North American Reliability Council</organization>
</author>
<date year="2013" month="December"/>
</front>
<seriesInfo name="CIP" value="005-5"/>
</reference>
<reference anchor="ISO-IEC-15118-2" >
<front>
<title>ISO/IEC 15118-2 Road vehicles - Vehicle-to-Grid Communication Interfa
ce - Part 2: Network and application protocol requirements</title>
<author >
<organization>International Standardization Organization / International E
lectrotechnical Commission</organization>
</author>
<date year="2014" month="April"/>
</front>
<seriesInfo name="ISO/IEC" value="15118-2 "/>
</reference>
<reference anchor="UNISIG-Subset-137" >
<front>
<title>Subset-137; ERTMS/ETCS On-line Key Management FFFIS; V1.0.0</title>
<author >
<organization>UNISIG</organization>
</author>
<date year="2015" month="December"/>
</front>
<format type="PDF" target="https://www.era.europa.eu/sites/default/files/files
ystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/set_of_specifications_3_e
tcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf"/>
<annotation>http://www.kmc-subset137.eu/index.php/download/</annotation></refere
nce>
<reference anchor="OCPP" >
<front>
<title>Open Charge Point Protocol 2.0.1 (Draft)</title>
<author >
<organization>Open Charge Alliance</organization>
</author>
<date year="2019" month="December"/>
</front>
</reference>
<reference anchor="I-D.ietf-anima-brski-discovery"> <reference anchor="UNISIG-Subset-137" target="https://www.era.europa.eu/
<front> sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/
<title>Discovery for BRSKI variations</title> set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf">
<author fullname="Toerless Eckert" initials="T. T." surname="Eckert"> <front>
<organization>Futurewei USA</organization> <title>ERTMS/ETCS On-line Key Management FFFIS</title>
</author> <author>
<author fullname="Esko Dijk" initials="E." surname="Dijk"> <organization>UNISIG</organization>
<organization>IoTconsultancy.nl</organization> </author>
</author> <date year="2015" month="December"/>
<date day="25" month="July" year="2024"/> </front>
<abstract> <refcontent>Subset-137, Version 1.0.0</refcontent>
<t> This document specifies how BRSKI entities, such as registrars, </reference>
proxies, pledges or others that are acting as responders, can be
discovered and selected by BRSKI entities acting as initiators.
</t> <reference anchor="OCPP">
</abstract> <front>
</front> <title>Open Charge Point Protocol 2.0.1 (Draft)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-discovery-04" <author>
/> <organization>Open Charge Alliance</organization>
</author>
<date year="2019" month="December"/>
</front>
</reference>
</reference> <!-- [I-D.ietf-anima-brski-discovery] IESG State: I-D Exists as of 10/28/2024 --
>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-anima-brski-discovery.xml"/>
</references>
</references> </references>
<?line 1287?>
<?line 1287?> <section anchor="app-examples">
<name>Application Examples</name>
<section anchor="app-examples"><name>Application Examples</name> <t>This informative annex provides some details about application examples
.</t>
<t>This informative annex provides some detail about application examples.</t>
<section anchor="rolling-stock"><name>Rolling Stock</name>
<t>Rolling stock or railroad cars contain a variety of sensors,
actuators, and controllers, which communicate within the railroad car
but also exchange information between railroad cars forming a train,
with track-side equipment, and/or possibly with backend systems.
These devices are typically unaware of backend system connectivity.
Enrolling certificates may be done during maintenance cycles
of the railroad car, but can already be prepared during operation.
Such asynchronous enrollment will include generating certification requests,
which are collected and later forwarded for processing whenever
the railroad car gets connectivity with the backend PKI of the operator.
The authorization of the certification request is then done based on
the operator's asset/inventory information in the backend.</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 the Subset-137 specifying the ETRAM/ETCS
online key management for train control systems <xref target="UNISIG-Subset-137"
/>.</t>
</section>
<section anchor="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 a situation a service technician collects the necessary data
and transfers it between the local network and the central building management
system, e.g., using a laptop or a mobile phone.
This data may comprise parameters and settings
required in the operational phase of the sensors/actuators, like a
component certificate issued by the operator to authenticate against other
components and services.</t>
<t>The collected data may be provided by a domain registrar
already existing in the local network. In this case
connectivity to the backend PKI may be facilitated by the service
technician's laptop.
Alternatively, the data can also be collected from the
pledges directly and provided to a domain registrar deployed in a
different network in preparation for the operational phase.
In this case, connectivity to the domain registrar
may also be facilitated by the service technician's laptop.</t>
</section>
<section anchor="substation-automation"><name>Substation Automation</name>
<t>In electrical substation automation scenarios, a control center typically hos
ts
PKI services to issue certificates for Intelligent Electronic Devices operated
in a substation. Communication between the substation and control center
is performed through a proxy/gateway/DMZ, which terminates protocol flows.
Note that <xref target="NERC-CIP-005-5"/> requires inspection of protocols
at the boundary of a security perimeter (the substation in this case).
In addition, security management in substation automation assumes
central support of several enrollment protocols to support
the various capabilities of IEDs from different vendors.
The IEC standard IEC62351-9 <xref target="IEC-62351-9"/>
specifies for the infrastructure side mandatory support of
two enrollment protocols: SCEP <xref target="RFC8894"/> and EST <xref target="RF
C7030"/>,
while an Intelligent Electronic Device may support only one of them.</t>
</section>
<section anchor="electric-vehicle-charging-infrastructure"><name>Electric Vehicl
e 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. 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,
among others, on the selected backend connectivity protocol.
In the case of OCPP, this protocol is meant to be the only communication
protocol between the charging point and the backend, carrying all
information to control the charging operations and maintain the
charging point itself. This means that the certificate management
needs to be handled in-band of OCPP. This requires the ability to
encapsulate the certificate management messages in a transport-independent way.
Authenticated self-containment will support this by
allowing the transport without a separate enrollment protocol,
binding the messages to the identity of the communicating endpoints.</t>
</section> <section anchor="rolling-stock">
<section anchor="infrastructure-isolation"><name>Infrastructure Isolation Policy <name>Rolling Stock</name>
</name> <t>Rolling stock or railroad cars contain a variety of sensors,
actuators, and controllers. These communicate within the railroad car
but also exchange information between railroad cars, forming a train
with track-side equipment and/or possibly with backend systems.
These devices are typically unaware of backend system connectivity.
Enrolling certificates may be done during maintenance cycles of the
railroad car but can already be prepared during operation. Such
asynchronous enrollment will include generating certification
requests, which are collected and later forwarded for processing
whenever the railroad car gets connectivity with the backend PKI of
the operator. The authorization of the certification request is then
done based on the operator's asset/inventory information in the
backend.</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 the Subset-137, which specifies the ETRAM/ETCS online
key management for train control systems <xref
target="UNISIG-Subset-137"/>.</t>
</section>
<t>This refers to any case in which network infrastructure is normally <section anchor="building-automation">
isolated from the Internet as a matter of policy, most likely for <name>Building Automation</name>
security reasons. In such a case, limited access to external PKI <t>In building automation scenarios, a detached building or the
services will be allowed in carefully controlled short periods of basement of a building may be equipped with sensors, actuators, and
time, for example when a batch of new devices is deployed, and controllers that are connected to each other in a local network but
forbidden or prevented at other times.</t> with only limited or no connectivity to a central building management
system. This problem may occur during installation time but also
during operation. In such a situation, a service technician collects
the necessary data and transfers it between the local network and the
central building management system, e.g., using a laptop or a mobile
phone. This data may comprise parameters and settings required in the
operational phase of the sensors/actuators, like a component
certificate issued by the operator to authenticate against other
components and services.</t>
<t>The collected data may be provided by a domain registrar already
existing in the local network. In this case, connectivity to the
backend PKI may be facilitated by the service technician's laptop.
Alternatively, the data can also be collected from the pledges
directly and provided to a domain registrar deployed in a different
network in preparation for the operational phase. In this case,
connectivity to the domain registrar may also be facilitated by the
service technician's laptop.</t>
</section>
<section anchor="substation-automation">
<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 (in this case, the substation).
In addition, security management in substation automation assumes
central support of several enrollment protocols to support the various
capabilities of IEDs from different vendors. The IEC standard
IEC62351-9 <xref target="IEC-62351-9"/> specifies mandatory support of
two enrollment protocols for the infrastructure side, SCEP <xref
target="RFC8894"/> and EST <xref target="RFC7030"/>, while an
IED may support only one of them.</t>
</section>
<section anchor="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., 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, among other things, on the selec
ted
backend connectivity protocol. In the case of OCPP, this protocol is
meant to be the only communication protocol between the charging point
and the backend, carrying all information to control the charging
operations and maintain the charging point itself. This means that the
certificate management needs to be handled in-band of OCPP. This
requires the ability to encapsulate the certificate management
messages in a transport-independent way. Authenticated
self-containment will support this by allowing the transport without a
separate enrollment protocol, binding the messages to the identity of
the communicating endpoints.</t>
</section>
<section anchor="infrastructure-isolation">
<name>Infrastructure Isolation Policy</name>
</section> <t>This refers to any case in which network infrastructure is normally
<section anchor="sites-with-insufficient-level-of-operational-security"><name>Si isolated from the Internet as a matter of policy, most likely for
tes with Insufficient Level of Operational Security</name> security reasons. In such a case, limited access to external PKI
services will be allowed in carefully controlled short periods of
time (for example, when a batch of new devices is deployed) and
forbidden or prevented at other times.</t>
</section>
<t>The RA performing (at least part of) the authorization of a <section anchor="sites-with-insufficient-level-of-operational-security">
certification request is a critical PKI component and therefore requires higher <name>Sites with Insufficient Levels of Operational Security</name>
operational security than components utilizing the issued <t>The RA performing (at least part of) the authorization of a
certificates for their security features. CAs may also demand higher certification request is a critical PKI component and therefore
security in the registration procedures from RAs, which domain registrars requires higher operational security than components utilizing the
with co-located RAs may not be able to fulfill. issued certificates for their security features. CAs may also demand
Especially the CA/Browser forum currently increases the security requirements higher security in the registration procedures from RAs, which domain
in the certificate issuance procedures for publicly trusted certificates, registrars with co-located RAs may not be able to fulfill. In
i.e., those placed in trust stores of browsers, particular, the CA/Browser forum currently increases the security
which may be used to connect with devices in the domain. requirements in the certificate issuance procedures for publicly
In case the on-site components of the target domain can not be operated securely trusted certificates, i.e., those placed in trust stores of browsers,
enough for the needs of an RA, this service should be transferred to which may be used to connect with devices in the domain. In case the
an off-site backend component that has a sufficient level of security.</t> on-site components of the target domain cannot be operated securely
enough for the needs of an RA, this service should be transferred to
an off-site backend component that has a sufficient level of
security.</t>
</section>
</section>
<!--
clarify that messages of the cert enrollment phase are RECOMMENDED to be
transmitted on the existing channel between the pledge and the registrar
-->
<!--
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>
</section>
<section anchor="app_history"><name>History of Changes TBD RFC Editor: please de
lete</name>
<t>List of reviewers:</t>
<t><list style="symbols"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f
<t>Toerless Eckert (document shepherd)</t> alse">
<t>Barry Leiba (SECdir)</t> <name>Contributors</name>
<t>Mahesh Jethanandani (IETF area director)</t> <contact initials="E." surname="Lear" fullname="Eliot Lear">
<t>Meral Shirazipour (Gen-ART reviewer)</t> <organization>Cisco Systems</organization>
<t>Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Dany <address>
liw, <postal>
and Éric Vyncke (IESG reviewers)</t> <street>Richtistrasse 7</street>
<t>Michael Richardson (ANIMA design team)</t> <city>Wallisellen</city>
<t>Rajeev Ranjan, Rufus Buschart, Szofia Fazekas-Zisch, etc. (Siemens)</t> <code>8304</code>
<t>Reshad Rahman (YANGDOCTORS reviewer). Note that <country>Switzerland</country>
<eref target="https://datatracker.ietf.org/doc/review-ietf-anima-brski-async-enr </postal>
oll-03-yangdoctors-early-rahman-2021-08-15/">YANGDOCTORS Early review of 2021-08 <phone>+41 44 878 9200</phone>
-15</eref> <email>lear@cisco.com</email>
referred to the PRM aspect of <eref target="https://datatracker.ietf.org/doc/dra </address>
ft-ietf-anima-brski-async-enroll/03/">draft-ietf-anima-brski-async-enroll-03</er </contact>
ef>. </section>
This has been carved out of the draft to a different one and thus is no more </back>
applicable here.</t>
</list></t>
<t>IETF draft ae-12 -&gt; ae-13:</t>
<t><list style="symbols">
<t>Due to IANA requirement, shorten service name <spanx style="verb">"brski-re
gistrar-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 ancho
r explicit.
<br />
Including the vouchers in <xref target="enrollfigure"/> would not fit because th
e 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"/>, f
ully 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 conside
rations.</t>
<t>Address Éric Vyncke's comment by replacing 'production' by 'manufacturing'<
/t>
</list></t>
<t>IETF draft ae-11 -&gt; 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 -&gt; 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 sec
tion</t>
<t>reconsider normative language, replacing one 'may' by '<bcp14>MAY</bcp1
4>' 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 -&gt; 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 -&gt; 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="solutio
ns-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 -&gt; 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 -&gt; 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,<b
r />
in response to SECDIR Last Call Review of ae-06 by Barry Leiba</t>
</list></t>
<t>IETF draft ae-05 -&gt; ae-06:</t> <!-- [rfced] Formatting and XML:
<t><list style="symbols"> a.) There are several author comments present in the XML. Please
<t>Extend section on discovery according to discussion in the design team</t> review and confirm that none of these comments still need to be
<t>Make explicit that MASA voucher status telemetry is as in BRSKI</t> addressed. Note that the comments will be deleted prior to
<t>Add note that on delegation, RA may need info on pledge authorization</t> publication.
</list></t>
<t>IETF draft ae-04 -&gt; ae-05:</t> 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)
.
<t><list style="symbols"> c.) We note the following different uses regarding this document's use of <tt>
<t>Remove entries from the terminology section that should be clear from BRSKI styling and quotation marks. In the HTML and PDF outputs, the text enclosed in
</t> <tt> is output in fixed-width font. In the txt output, there are no changes to
<t>Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by RA/CA</t> the font. Please review carefully and let us know if any updates should be made
<t>Add the abbreviation 'LCMPP' for Lightweight CMP Profile to the terminology for consistency:
section</t>
<t>State clearly in <xref target="brski-cmp-instance"/> that LCMPP is mandator
y when using CMP</t>
<t>Change URL of BRSKI-AE-overview graphics to slide on IETF 116 meeting mater
ial</t>
</list></t>
<t>IETF draft ae-03 -&gt; ae-04:</t> the <tt>caPubs</tt> field
the acp-node-name field (no quotes or <tt> styling)
<t><list style="symbols"> <tt>"brski-reg-cmp"</tt>
<t>In response to SECDIR Early Review of ae-03 by Barry Leiba, brski-reg-cmp (no quotes or <tt> styling)
<list style="symbols">
<t>replace 'end-to-end security' by the more clear 'end-to-end authenticat
ion'</t>
<t>restrict the meaning of the abbreviation 'AE' to 'Alternative Enrollmen
t'</t>
<t>replace '<bcp14>MAY</bcp14>' by 'may' in requirement on delegated regis
trar actions</t>
<t>re-phrase requirement on certification request exchange, avoiding MANDA
TORY</t>
<t>mention that further protocol names need be put in Well-Known URIs regi
stry</t>
<t>explain consequence of using non-standard endpoints, not following <bcp
14>SHOULD</bcp14></t>
<t>remove requirement that 'caPubs' field in CMP responses <bcp14>SHOULD N
OT</bcp14> be used</t>
<t>add paragraph in security considerations on additional use of TLS for C
MP</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 motivation
s 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 compon
ents</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="RFC
8995"/> (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>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 trans
ported 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 consi
stent</t>
</list></t>
</list></t>
<t>IETF draft ae-02 -&gt; ae-03:</t> <tt>"brski-registrar"</tt>
<tt>"/.well-known/est/simpleenroll"</tt>
<tt>"/.well-known/&lt;enrollment-protocol&gt;/&lt;request&gt;"</tt>
<tt>"/fullcmc"</tt> endpoint
<tt>"/simpleenroll"</tt> endpoint
<t><list style="symbols"> '<tt>est</tt>'
<t>In response to review by Toerless Eckert, '<tt>cmp</tt>'
<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> sup
port this.</t>
<t>clarify that the enrollment protocol chosen between pledge and registra
r
<bcp14>MUST</bcp14> also be used for the upstream enrollment exchange with the P
KI.</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 t
he pledge.</t>
</list></t>
<t>Change "The registrar <bcp14>MAY</bcp14> offer different enrollment protoco
ls" to
"The registrar <bcp14>MUST</bcp14> support at least one certificate enrollment p
rotocol ..."</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="address
ing"/>
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 acknowledgm
ents</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 -&gt; ae-02:</t> <tt>&lt;enrollment-protocol&gt;</tt>
<tt>&lt;request&gt;</tt>
The label <tt>[OPTIONAL forwarding]</tt>
<t><list style="symbols"> 'renewal' option
<t>Architecture: clarify registrar role including RA/LRA/enrollment proxy</t> "tls-unique" value
<t>CMP: add reference to CoAP Transport for CMPV2 and Constrained BRSKI</t> the tls-unique value (no quotes)
<t>Include venue information</t> -->
</list></t>
<t>From IETF draft 05 -&gt; IETF draft ae-01:</t> <!-- [rfced] Abbreviations:
<t><list style="symbols"> a.) FYI - We have updated the expansion of LDevID throughout the document
<t>Renamed the repo and files from 'anima-brski-async-enroll' to 'anima-brski- as follows. Please review and let us know of any objections.
ae'</t>
<t>Added graphics for abstract protocol overview as suggested by Toerless Ecke
rt</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 -&gt; IETF draft 05:</t> Original:
Locally significant Device IDentifier (LDevID)
<t><list style="symbols"> Current:
<t>David von Oheimb became the editor.</t> Local Device Identifier (LDevID)
<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 -&gt; IETF draft 04:</t> 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?
<t><list style="symbols"> Public-Key Infrastructure
<t>Moved UC2-related parts defining the pledge in responder mode to a public-key infrastructure
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 -&gt; IETF draft 03:</t> c.) May we update instances of "local RA" to the abbreviation "LRA"?
<t><list style="symbols"> d.) FYI - We have added expansions for abbreviations upon first use
<t>Housekeeping, deleted open issue regarding YANG voucher-request per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
in UC2 as voucher-request was enhanced with additional leaf.</t> expansion in the document carefully to ensure correctness.
<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 -&gt; IETF draft 02:</t> Autonomic Control Plane (ACP)
Certificate Management over CMS (CMC)
Cryptographic Message Syntax (CMS)
Constrained Application Protocol (CoAP)
Simple Certificate Enrollment Protocol (SCEP)
-->
<t><list style="symbols"> <!-- [rfced] Please review the following changes and questions we have
<t>Defined call flow and objects for interactions in UC2. Object format regarding the References section:
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 -&gt; registrar-agent to
better underline agent relation.</t>
<t>Terminology change: issue #3 PULL/PUSH -&gt; 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 -&gt; IETF draft 01:</t> a.) [UNISIG-Subset-137]
<t><list style="symbols"> The provided URL returns the message: "The requested page could not be found."
<t>Update of scope in <xref target="sup-env"/> to include in We found the following URL from the European Union Agency for Railways (ERA)
which the pledge acts as a server. This is one main motivation website, which matches the specification described in this reference, but it
for use case 2.</t> is a more up-to-date version from May 2023. Would you like to use this version
<t>Rework of use case 2 to consider the and URL instead?
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 -&gt; IETF draft 00:</t> <https://www.era.europa.eu/system/files/2023-09/index083_-_SUBSET-137_v400.pdf>
<t><list style="symbols"> Current:
<t>Inclusion of discovery options of enrollment endpoints at [UNISIG-Subset-137]
the domain registrar based on well-known endpoints in UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
<xref target="addressing"/> as replacement of section 5.1.3 137, Version 1.0.0, December 2015,
in the individual draft. This is intended to support both use <https://www.era.europa.eu/sites/default/files/filesystem/
cases in the document. An illustrative example is provided.</t> ertms/ccs_tsi_annex_a_-_mandatory_specifications/
<t>Missing details provided for the description and call flow in set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
pledge-agent use case UC2, e.g. to _subset-137_v100.pdf>.
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 do
ubling 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 -&gt; 03:</t> b.) [BRSKI-AE-OVERVIEW]
<t><list style="symbols"> FYI - We have removed the text below from the <annotation> element in this
<t>Update of terminology from self-contained to authenticated reference. If you would like to include this note, we recommend placing it in
self-contained object to be consistent in the wording and to the document where this reference is cited (rather than in the references
underline the protection of the object with an existing section).
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 -&gt; 02:</t> "Graphics on slide 4 of the status update on the BRSKI-AE draft 04 at IETF 11 6."
<t><list style="symbols"> c.) [IEC-62351-9]
<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 -&gt; 01:</t> 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.
<t><list style="symbols"> Current:
<t>Update of examples, specifically for building automation as [IEC-62351-9]
well as two new application use cases in <xref target="app-examples"/>.</t> International Electrotechnical Commission, "Power systems
<t>Deletion of asynchronous interaction with MASA to not management and associated information exchange - Data and
complicate the use case. Note that the voucher exchange can communications security - Part 9: Cyber security key
already be handled in an asynchronous manner and is therefore management for power system equipment", IEC 62351-9:2017,
not considered further. This resulted in removal of the May 2017, <https://webstore.iec.ch/en/publication/30287>.
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> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f and let us know if any changes are needed. Updates of this nature typically
alse"> result in more precise language, which is helpful for readers.
<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>
<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=
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->
</rfc> </rfc>
 End of changes. 189 change blocks. 
3066 lines changed or deleted 2148 lines changed or added

This html diff was produced by rfcdiff 1.48.