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" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 2.6
.10) -->
<!DOCTYPE rfc [ <!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 abbrev="BRSKI-AE">BRSKI with Alternative Enrollment (BRSKI-AE) Protoc
</title> ol</title>
<seriesInfo name="RFC" value="9733"/>
<author initials="D." surname="von&nbsp;Oheimb" fullname="David von&nbsp;Ohe <author initials="D." surname="von Oheimb" fullname="David von Oheimb" role=
imb" role="editor"> "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 54
<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"/> <keyword>BRSKI</keyword>
<keyword>IoT</keyword>
<area>Operations and Management</area> <keyword>zero-touch onboarding</keyword>
<workgroup>ANIMA WG</workgroup> <keyword>alternative enrollment protocols</keyword>
<keyword>Internet-Draft</keyword> <keyword>CMP</keyword>
<keyword>self-contained signed objects</keyword>
<keyword>end-to-end proof of origin</keyword>
<keyword>auditable source authentication</keyword>
<abstract> <abstract>
<t>This document defines enhancements to the Bootstrapping Remote Secure
Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative
Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate
enrollment mechanisms instead of the originally specified use of
Enrollment over Secure Transport (EST). It supports certificate
enrollment protocols such as the Certificate Management Protocol (CMP)
that use authenticated self-contained signed objects for certification
messages, allowing for flexibility in network device onboarding
scenarios. The enhancements address use cases where the existing
enrollment mechanism may not be feasible or optimal, providing a
framework for integrating suitable alternative enrollment protocols.
This document also updates the BRSKI reference architecture to
accommodate these alternative methods, ensuring secure and scalable
deployment across a range of network environments.</t>
</abstract>
</front>
<?line 148?> <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.
</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 document defines enhancements to the Bootstrapping Remote Secure Key <t>This specification carries over the main characteristics of BRSKI,
Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative Enrollment).<br namely:</t>
/> <ul spacing="normal">
BRSKI-AE extends BRSKI to support certificate enrollment mechanisms <li>
instead of the originally specified use of EST. <t>The pledge is assumed to have received its Initial Device
It supports certificate enrollment protocols, such as CMP, IDentifier (IDevID) <xref target="IEEE_802.1AR-2018"/> credentials
that use authenticated self-contained signed objects for certification messages, during its manufacturing. It uses them to authenticate itself to
allowing for flexibility in network device onboarding scenarios.<br /> the Manufacturer Authorized Signing Authority (MASA) <xref
The enhancements address use cases where the existing enrollment mechanism target="RFC8995"/>, to the registrar (which is the access point
may not be feasible or optimal, providing a framework of the target domain), and to possibly further components of the
for integrating suitable alternative enrollment protocols.<br /> domain where it will be operated.</t>
This document also updates the BRSKI reference architecture </li>
to accommodate these alternative methods, <li>
ensuring secure and scalable deployment across a range of network environments.< <t>The pledge first obtains via the voucher <xref target="RFC8366"/> e
/t> xchange a trust anchor for authenticating entities in the
domain such as the domain registrar.</t>
</li>
<li>
<t>The pledge then obtains its Locally Significant 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>
</abstract> <t>It may be observed that the BRSKI voucher exchange between the
pledge, registrar, and MASA involves the use of authenticated
self-contained objects, which inherently possess these properties.</t>
<note title="About This Document" removeInRFC="true"> <t>The existing well-known URI structure used for BRSKI and EST messages
<t> is extended by introducing an additional path element that specifies the
Status information for this document may be found at <eref target="https enrollment protocol being employed.</t>
://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> <t>This specification allows the registrar to offer multiple enrollment
protocols, enabling pledges and their developers to select the most
appropriate one based on the defined overall approach and specific
endpoints.</t>
<middle> <t>It may be important to note that <xref target="RFC8995"/>
specifies the use of HTTP over TLS, but variations such as Constrained
BRSKI <xref target="I-D.ietf-anima-constrained-voucher"/>, which uses
the Constrained Application Protocol (CoAP) over DTLS, are possible as wel
l. In this context, "HTTP" and "TLS"
are used as references to the most common implementation, though
variants using CoAP and/or DTLS are implied where applicable, as the
distinctions are not pertinent here.</t>
<?line 164?> <t>This specification, together with its referenced documents, is
sufficient to support BRSKI with the Certificate Management Protocol
(CMP) <xref target="RFC9480"/> as profiled in the Lightweight CMP
Profile (LCMPP) <xref target="RFC9483"/>. Integrating BRSKI with an
enrollment protocol or profile other than the LCMPP will necessitate
additional IANA registrations, as detailed in this document.
Furthermore, additional specifications may be required for the details
of the protocol or profile, which fall outside the scope of this
document.</t>
<section anchor="introduction"><name>Introduction</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.
</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.
</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 <xref target="RFC8995"/> is typically used with Enrollment over Secure <section anchor="terminology-and-abbreviations">
Transport <name>Terminology and Abbreviations</name>
(EST, <xref target="RFC7030"/>) as the enrollment protocol <t>
for operator-specific device certificates, employing HTTP over TLS for secure me The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
ssage transfer. "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
BRSKI-AE is a variant using alternative enrollment protocols with ",
authenticated self-contained objects for the device certificate enrollment. "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<!-- "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
This enhancement of BRSKI is named BRSKI-AE, where AE stands for "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
**A**lternative **E**nrollment. be
(while originally it was used to abbreviate **A**synchronous **E**nrollment) 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>This approach offers several distinct advantages. <t>This document relies on the terminology defined in <xref
It allows for the authentication of the origin of requests and responses target="RFC8995"/>, <xref target="RFC5280"/>, and <xref
independently of message transfer mechanisms. target="IEEE_802.1AR-2018"/>, which is partly repeated here. Several
This capability facilitates end-to-end authentication further terms are also described here.</t>
(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 <t>To be independent of the terminology of a specific enrollment
> protocol, this document utilizes generic terminology regarding PKI
management operations.</t>
<t><list style="symbols"> <t>The following terminology is used in this document:</t>
<t>The pledge is assumed to have received its Initial Device IDentifier
(IDevID, <xref target="IEEE_802.1AR-2018"/>) credentials during its manufacturin
g.
It uses them to authenticate itself to the
Manufacturer Authorized Signing Authority (MASA, <xref target="RFC8995"/>),
and to the registrar, which is the access point of the target domain,
and to possibly further components of the domain where it will be operated.</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 <dl newline="false" spacing="normal">
e
enrollment through the use of an alternative protocol to EST that:</t>
<t><list style="symbols"> <dt>asynchronous:</dt>
<t>Supports end-to-end authentication over multiple transport hops.</t> <dd>the time-wise interrupted delivery of messages, here, between a
<t>Facilitates secure message exchange over any type of transfer mechanism, pledge and some backend system (e.g., an RA).</dd>
including asynchronous delivery.</t>
</list></t>
<!--- not really: and <dt>attribute request:</dt>
* defining a certificate waiting indication and handling, for the case that the <dd>a message requesting content to be included in the certification req
certifying component is (temporarily) not available. uest.</dd>
<t>It may be observed that the BRSKI voucher exchange between the pledge, <dt>attribute response:</dt>
registrar, and MASA involves the use of authenticated self-contained objects, <dd>a message providing the answer to the attribute request.</dd>
which inherently possess these properties.</t>
<t>The existing well-known URI structure used for BRSKI and EST messages <dt>authenticated self-contained object:</dt>
is extended by introducing an additional path element <dd>a data structure that is cryptographically bound to the identity
that specifies the enrollment protocol being employed.</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>
<t>This specification allows the registrar to offer multiple enrollment protocol <dt>backend:</dt>
s, <dd>the placement of a domain component separately from the domain
enabling pledges and their developers to select the most appropriate one registrar; it may be on-site or off-site.</dd>
based on the defined overall approach and specific endpoints.</t>
<t>It may be important to note that BRSKI (RFC 8995) specifies the use of <dt>CA certs request:</dt>
HTTP over TLS, but variations such as Constrained BRSKI <dd>a message requesting CA certificates.</dd>
<xref target="I-D.ietf-anima-constrained-voucher"/> which uses CoAP over DTLS,
are possible as well. In this context,
'HTTP' and 'TLS' are used as references to the most common implementation,
though variants using CoAP and/or DTLS are implied where applicable,
as the distinctions are not pertinent here.</t>
<t>This specification, together with its referenced documents, is sufficient to <dt>CA certs response:</dt>
support BRSKI with the Certificate Management Protocol (CMP, <xref target="RFC94 <dd>a message providing the answer to a CA certs request.</dd>
80"/>)
as profiled in the Lightweight CMP Profile (LCMPP, <xref target="RFC9483"/>).
Integrating BRSKI with an enrollment protocol or profile other than LCMPP
will necessitate additional IANA registrations, as detailed in this document.
Furthermore, additional specifications may be required for the details
of the protocol or profile, which fall outside the scope of this document.</t>
<section anchor="sup-env"><name>Supported Scenarios</name> <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>
<t>BRSKI-AE is designed for use in scenarios such as the following:</t> <dt>certification request:</dt>
<dd>a message requesting a certificate with proof of identity.</dd>
<t><list style="symbols"> <dt>certification response:</dt>
<t>Pledges and/or the target domain leverage an existing <dd>a message providing the answer to a certification request.</dd>
certificate enrollment protocol other than EST, such as CMP.</t>
<t>The application context precludes the use of EST
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 <dt>local RA:</dt>
ain. <dd>the same as LRA.</dd>
<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> <dt>off-site:</dt>
</section> <dd>the locality of a component, service, or functionality (such as RA
<section anchor="terminology"><name>Terminology and abbreviations</name> 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>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI <dt>on-site:</dt>
RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <dd>the locality of a component, service, or functionality at the site o
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO f
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", the registrar.</dd>
"<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?> <dt>PKI/registrar confirm:</dt>
<dd>an acknowledgment of the PKI on the certificate confirm.</dd>
<t>This document relies on the terminology defined in <xref target="RFC8995"/>, <dt>pledge:</dt>
<xref target="RFC5280"/>, <dd>a device that is to be bootstrapped into a target domain. It
and <xref target="IEEE_802.1AR-2018"/>, partly repeated here. requests an LDevID using IDevID credentials installed by its
Also several further terms are described here.</t> manufacturer.</dd>
<t>To be independent of the terminology of a specific enrollment protocol, this <dt>registrar:</dt>
document utilizes generic terminology regarding PKI management operations.</t> <dd>short for domain registrar.</dd>
<dl> <dt>site:</dt>
<dt>asynchronous:</dt> <dd>the locality where an entity such as a pledge, registrar, or PKI
<dd> component is deployed. The target domain may have multiple sites.</dd>
<t>time-wise interrupted delivery of messages,<br />
here between a pledge and some backend system (e.g., an RA)</t>
</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> <dt>synchronous:</dt>
<section anchor="req-sol"><name>Basic Requirements and Mapping to Solutions</nam <dd>the time-wise uninterrupted delivery of messages, here, between a
e> pledge and a registrar or backend system (e.g., the MASA).</dd>
<t>Based on the intended target scenarios described in <xref target="sup-env"/> <dt>target domain:</dt>
and <dd>the domain that a pledge is going to be bootstrapped into.</dd>
the application examples described in <xref target="app-examples"/>, the followi
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> </dl>
<t><list style="symbols"> <t>The following abbreviations are used in this document:</t>
<t>Proof of possession: demonstrates access to the private <dl newline="false" spacing="normal">
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>BRSKI:</dt>
s, <dd>Bootstrapping Remote Secure Key Infrastructure <xref target="RFC8995
based on existing technology described in IETF documents.</t> "/></dd>
<section anchor="solutions-PoP"><name>Solution Options for Proof of Possession</ <dt>BRSKI-AE:</dt>
name> <dd>BRSKI with Alternative Enrollment. Refers to a
variation of BRSKI <xref target="RFC8995"/> in which BRSKI-EST, the
enrollment protocol between the pledge and the registrar, is replaced
by enrollment protocols that support end-to-end authentication of the
pledge to the RA, such as CMP.</dd>
<t>Certificate signing request (CSR) objects: CSRs are <dt>CA:</dt>
data structures protecting only the integrity of the contained data <dd>Certification Authority</dd>
and providing proof of possession for a (locally generated) private key.
Important types of CSR data structures are:</t>
<t><list style="symbols"> <dt>CMC:</dt>
<t>PKCS #10 <xref target="RFC2986"/>. This very common form of CSR is <dd>Certificate Management over CMS</dd>
self-signed to protect its integrity and to prove possession of
the private key that corresponds to the public key included in the request.</t>
<t>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" sectionFo
rmat="comma" target="RFC4211"/>.</t>
</list></t>
<t>It should be noted that the integrity protection of CSRs includes the public <dt>CMP:</dt>
key <dd>Certificate Management Protocol <xref target="RFC4210"/> <xref target
because it is part of the data signed by the corresponding private key. ="RFC9480"/></dd>
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:
This extra property can be
achieved by an additional binding to the IDevID of the pledge.
This binding to the source authentication supports the
authorization decision of the certification request.
--></t>
</section> <dt>CMS:</dt>
<section anchor="solutions-PoI"><name>Solution Options for Proof of Identity</na <dd>Cryptographic Message Syntax</dd>
me>
<t>Binding a certificate signing request (CSR) to an existing authenticated <dt>CRMF:</dt>
credential (the BRSKI context, the IDevID certificate) enables <dd>Certificate Request Message Format</dd>
proof of origin, which in turn supports an authorization decision on the CSR.<
/t>
<t>The binding of data origin authentication to the CSR <dt>CSR:</dt>
is typically delegated to the protocol used for certificate management. <dd>Certificate Signing Request</dd>
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 <dt>EST:</dt>
in various ways, such as:</t> <dd>Enrollment over Secure Transport <xref target="RFC7030"/></dd>
<t><list style="symbols"> <dt>IDevID:</dt>
<t>EST <xref target="RFC7030"/>, also its variant EST-coaps <xref target="RFC9 <dd>Initial Device IDentifier (of a pledge, provided by
148"/>, the manufacturer and comprising of a private key and the related X.509
utilizes PKCS #10 to encode Certificate Signing Requests (CSRs). certificate with its chain).</dd>
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>
<!-- <dt>LCMPP:</dt>
Note that, besides the existing enrollment protocols, there is <dd>Lightweight CMP Profile <xref target="RFC9483"/></dd>
ongoing work in the ACE WG to define an encapsulation of EST messages
in OSCORE, which will result in a TLS-independent way of protecting EST.
This approach {{draft.selander-ace-coap-est-oscore}}
may be considered as a further variant.
<t><list style="symbols"> <dt>LDevID:</dt>
<t>SCEP <xref target="RFC8894"/> supports using a shared secret (passphrase) o <dd>Locally Significant Device IDentifier (of a pledge, provided by
r its target domain and comprising of a private key and the related X.509
an existing certificate to protect CSRs based on certificate with its chain).</dd>
SCEP Secure Message Objects using CMS wrapping
(<xref target="RFC5652"/>). Note that the wrapping using
an existing IDevID in SCEP is referred to as 'renewal'.
This way
SCEP does not rely on the security of the underlying message transfer.</t>
<t>CMP <xref target="RFC4210"/> <xref target="RFC9480"/> supports using a shar
ed secret (passphrase)
or an existing
certificate, which may be an IDevID credential, to authenticate
certification requests via the PKIProtection structure in a PKIMessage.
The certification request is typically encoded utilizing CRMF,
while PKCS #10 is supported as an alternative.
Thus, CMP does not rely on the security of the underlying message transfer.</t>
<t>CMC <xref target="RFC5272"/> also supports utilizing a shared secret (passp
hrase) or
an existing certificate to protect certification requests,
which can be either in CRMF or PKCS #10 structure.
The proof of identity can be provided as part of a FullCMCRequest,
based on CMS <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 <dt>LRA:</dt>
d <dd>Local Registration Authority. A subordinate RA that is close to
objects, but SCEP, CMP, and CMC do. This document primarily focuses on CMP as entities being enrolled and separate from a subsequent RA. In
it has more industry adoption than CMC and SCEP has issues not detailed here.</t BRSKI-AE, it is needed if a backend RA is used; in this case, the LRA
> is co-located with the registrar.</dd>
</section> <dt>MASA:</dt>
</section> <dd>Manufacturer Authorized Signing Authority. Provides vouchers.</dd>
<section anchor="uc1"><name>Adaptations to BRSKI</name>
<t>To enable using alternative certificate enrollment protocols supporting end-t <dt>RA:</dt>
o-end <dd>Registration Authority. The PKI component to which a CA typically
authentication, asynchronous enrollment, and more general system architectures, delegates certificate management functions such as authenticating
BRSKI-AE provides some generalizations on BRSKI <xref target="RFC8995"/>. pledges and performing authorization checks on certification
This way, authenticated self-contained objects such as those described in requests.</dd>
<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 <dt>SCEP:</dt>
the reuse of already defined architecture elements and interactions. <dd>Simple Certificate Enrolment Protocol</dd>
In general, the communication follows the BRSKI model and utilizes the existing
BRSKI architecture elements.
In particular, the pledge initiates communication with the domain registrar and
interacts with the MASA as usual for voucher request and response processing.</t
>
<section anchor="architecture"><name>Architecture</name> </dl>
</section>
<t>The key element of BRSKI-AE is that the authorization of a certification requ <section anchor="req-sol">
est <name>Basic Requirements and Mapping to Solutions</name>
<bcp14>MUST</bcp14> be performed based on an authenticated self-contained object <t>Based on the intended target scenarios described in <xref
. target="sup-env"/> and the application examples described in <xref
The certification request is bound in a self-contained way target="app-examples"/>, the following requirements are derived to
to a proof of origin based on the IDevID credentials. support authenticated self-contained objects as containers carrying
Consequently, the certification request <bcp14>MAY</bcp14> be transferred using certification requests.</t>
any mechanism <t>The following properties are required for a certification request:</t>
or protocol. Authentication and authorization of the certification request <ul spacing="normal">
can be done by the domain registrar and/or by backend domain components. <li>
As mentioned in <xref target="sup-env"/>, these components may be offline or off <t>Proof of possession: demonstrates access to the private key
-site. corresponding to the public key contained in a certification
The registrar and other on-site domain components request. This is typically achieved by a self-signature using the
may have no or only temporary (intermittent) connectivity to them.</t> 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>
<t>This leads to generalizations in the <section anchor="solutions-PoP">
placement and enhancements of the logical elements as shown in <xref target="uc1 <name>Solution Options for Proof of Possession</name>
figure"/>.</t> <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.
</t>
</section>
<section anchor="solutions-PoI">
<name>Solution Options for Proof of Identity</name>
<figure title="Architecture Overview Using Backend PKI Components" anchor="uc1fi <t>Binding a Certificate Signing Request (CSR) to an existing
gure"><artset><artwork type="svg" align="left"><svg xmlns="http://www.w3.org/20 authenticated credential (which in the BRSKI context is the IDevID certi
00/svg" version="1.1" height="576" width="544" viewBox="0 0 544 576" class="diag ficate)
ram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lineca enables proof of origin, which in turn supports an authorization
p="round"> decision on the CSR.</t>
<path d="M 8,208 L 8,336" fill="none" stroke="black"/>
<path d="M 32,48 L 32,200" fill="none" stroke="black"/> <t>The binding of data origin authentication to the CSR is typically
<path d="M 32,480 L 32,528" fill="none" stroke="black"/> delegated to the protocol used for certificate management. This
<path d="M 80,208 L 80,336" fill="none" stroke="black"/> binding may be achieved through security options in an underlying
<path d="M 112,480 L 112,528" fill="none" stroke="black"/> transport protocol such as TLS if the authorization of the
<path d="M 152,240 L 152,304" fill="none" stroke="black"/> certification request is (sufficiently) done at the next communication
<path d="M 160,480 L 160,528" fill="none" stroke="black"/> hop. Depending on the key type, the binding can also be done in a
<path d="M 216,240 L 216,304" fill="none" stroke="black"/> stronger, transport-independent way by wrapping the CSR with a
<path d="M 304,240 L 304,304" fill="none" stroke="black"/> signature.</t>
<path d="M 336,32 L 336,144" fill="none" stroke="black"/> <t>This requirement is addressed by existing enrollment protocols in
<path d="M 376,312 L 376,472" fill="none" stroke="black"/> various ways, such as:</t>
<path d="M 424,240 L 424,304" fill="none" stroke="black"/> <ul spacing="normal">
<path d="M 456,72 L 456,144" fill="none" stroke="black"/> <li>
<path d="M 472,152 L 472,256" fill="none" stroke="black"/> <t>EST <xref target="RFC7030"/> and its variant EST-coaps <xref
<path d="M 480,480 L 480,528" fill="none" stroke="black"/> target="RFC9148"/> utilize PKCS #10 to encode CSRs. While such
<path d="M 536,32 L 536,144" fill="none" stroke="black"/> a CSR has not been designed to include proof of origin, there is a
<path d="M 336,32 L 536,32" fill="none" stroke="black"/> limited, indirect way of binding it to the source authentication
<path d="M 32,48 L 144,48" fill="none" stroke="black"/> of the underlying TLS session. This is achieved by including in
<path d="M 224,48 L 328,48" fill="none" stroke="black"/> the CSR the "tls-unique" value <xref target="RFC5929"/> resulting
<path d="M 336,64 L 536,64" fill="none" stroke="black"/> from the TLS handshake. As this is optionally supported by the
<path d="M 336,144 L 536,144" fill="none" stroke="black"/> EST <tt>"/simpleenroll"</tt> endpoint used in BRSKI, and the TLS
<path d="M 8,208 L 80,208" fill="none" stroke="black"/> handshake employed in BRSKI includes certificate-based client
<path d="M 152,240 L 216,240" fill="none" stroke="black"/> authentication of the pledge with its IDevID credentials, the
<path d="M 304,240 L 424,240" fill="none" stroke="black"/> proof of pledge identity being an authenticated TLS client can be
<path d="M 432,256 L 472,256" fill="none" stroke="black"/> bound to the CSR.</t>
<path d="M 88,272 L 144,272" fill="none" stroke="black"/>
<path d="M 224,272 L 296,272" fill="none" stroke="black"/> <t>Yet, this binding is only valid in the context of the TLS
<path d="M 152,304 L 216,304" fill="none" stroke="black"/> session established with the registrar acting as the EST server
<path d="M 304,304 L 424,304" fill="none" stroke="black"/> and typically also as an RA. So even such a cryptographic binding
<path d="M 8,336 L 80,336" fill="none" stroke="black"/> of the authenticated pledge identity to the CSR is not visible nor
<path d="M 32,480 L 112,480" fill="none" stroke="black"/> verifiable to authorization points outside the registrar, such as
<path d="M 160,480 L 480,480" fill="none" stroke="black"/> a (second) RA in the backend. What the registrar needs to do is
<path d="M 120,496 L 160,496" fill="none" stroke="black"/> authenticate and pre-authorize the pledge and indicate this to the
<path d="M 112,512 L 152,512" fill="none" stroke="black"/> (second) RA. This is done by signing the forwarded certification
<path d="M 32,528 L 112,528" fill="none" stroke="black"/> request with its private key and a related certificate that has
<path d="M 160,528 L 480,528" fill="none" stroke="black"/> the id-kp-cmcRA extended key usage attribute.</t>
<polygon class="arrowhead" points="480,152 468,146.4 468,157.6" fill="black" tra
nsform="rotate(270,472,152)"/> <t><xref section="2.5" sectionFormat="comma" target="RFC7030"/>
<polygon class="arrowhead" points="440,256 428,250.4 428,261.6" fill="black" tra sketches wrapping CSRs formatted per PKCS #10 with a Full PKI Reques
nsform="rotate(180,432,256)"/> t
<polygon class="arrowhead" points="384,472 372,466.4 372,477.6" fill="black" tra message sent to the <tt>"/fullcmc"</tt> endpoint. This would
nsform="rotate(90,376,472)"/> allow for source authentication at the message level, such that
<polygon class="arrowhead" points="384,312 372,306.4 372,317.6" fill="black" tra the registrar could forward it to external RAs in a meaningful
nsform="rotate(270,376,312)"/> way. This approach is so far not sufficiently described and
<polygon class="arrowhead" points="304,272 292,266.4 292,277.6" fill="black" tra likely has not been implemented.</t>
nsform="rotate(0,296,272)"/> </li>
<polygon class="arrowhead" points="232,272 220,266.4 220,277.6" fill="black" tra <li>
nsform="rotate(180,224,272)"/> <t>The Simple Certificate Enrolment Protocol (SCEP) <xref
<polygon class="arrowhead" points="160,512 148,506.4 148,517.6" fill="black" tra target="RFC8894"/> supports using a shared secret (passphrase) or
nsform="rotate(0,152,512)"/> an existing certificate to protect CSRs based on SCEP Secure
<polygon class="arrowhead" points="152,272 140,266.4 140,277.6" fill="black" tra Message Objects using Cryptographic Message Syntax (CMS) wrapping <x
nsform="rotate(0,144,272)"/> ref target="RFC5652"/>. Note
<polygon class="arrowhead" points="128,496 116,490.4 116,501.6" fill="black" tra that the wrapping using an existing IDevID in SCEP is referred to
nsform="rotate(180,120,496)"/> as "renewal". This way, SCEP does not rely on the security of the
<polygon class="arrowhead" points="96,272 84,266.4 84,277.6" fill="black" transf underlying message transfer.</t>
orm="rotate(180,88,272)"/> </li>
<polygon class="arrowhead" points="40,200 28,194.4 28,205.6" fill="black" transf <li>
orm="rotate(90,32,200)"/> <t>CMP <xref target="RFC4210"/> <xref target="RFC9480"/> supports
<g class="text"> using a shared secret (passphrase) or an existing certificate,
<text x="184" y="52">Drop-Ship</text> which may be an IDevID credential, to authenticate certification
<text x="372" y="52">Vendor</text> requests via the PKIProtection structure in a PKIMessage. The
<text x="432" y="52">Service</text> certification request is typically encoded utilizing CRMF, while
<text x="352" y="84">M</text> PKCS #10 is supported as an alternative. Thus, CMP does not rely
<text x="408" y="84">anufacturer</text> on the security of the underlying message transfer.</t>
<text x="352" y="100">A</text> </li>
<text x="400" y="100">uthorized</text> <li>
<text x="496" y="100">Ownership</text> <t>Certificate Management over CMS (CMC) <xref target="RFC5272"/>
<text x="352" y="116">S</text> also supports utilizing a shared secret (passphrase) or an
<text x="388" y="116">igning</text> existing certificate to protect certification requests, which can
<text x="488" y="116">Tracker</text> be either in a CRMF or PKCS #10 structure. The proof of identity
<text x="352" y="132">A</text> can be provided as part of a Full CMC Request based on CMS <xref
<text x="396" y="132">uthority</text> target="RFC5652"/> and signed with an existing IDevID secret.
<text x="508" y="196">BRSKI-</text> Thus, CMC does not rely on the security of the underlying message
<text x="288" y="212">.........................................</text> transfer.</t>
<text x="500" y="212">MASA</text> </li>
<text x="128" y="228">.</text> </ul>
<text x="448" y="228">.</text> <t>To sum up, EST does not meet the requirements for authenticated
<text x="128" y="244">.</text> self-contained objects, but SCEP, CMP, and CMC do. This document
<text x="448" y="244">.</text> primarily focuses on CMP as it has more industry adoption than CMC and
<text x="44" y="260">Pledge</text> SCEP has issues not detailed here.</t>
<text x="128" y="260">.</text> </section>
<text x="180" y="260">Join</text> </section>
<text x="340" y="260">Domain</text>
<text x="184" y="276">Proxy</text> <section anchor="uc1">
<text x="352" y="276">Registrar</text> <name>Adaptations to BRSKI</name>
<text x="448" y="276">.</text> <t>To enable using alternative certificate enrollment protocols
<text x="128" y="292">.</text> supporting end-to-end authentication, asynchronous enrollment, and more
<text x="324" y="292">w/</text> general system architectures, BRSKI-AE provides some generalizations on
<text x="352" y="292">LRA</text> BRSKI <xref target="RFC8995"/>. This way, authenticated self-contained
<text x="380" y="292">or</text> objects such as those described in <xref target="req-sol"/> above can be
<text x="404" y="292">RA</text> used for certificate enrollment, and RA functionality can be deployed
<text x="448" y="292">.</text> freely in the target domain. Parts of the RA functionality can even be
<text x="44" y="308">IDevID</text> distributed over several nodes.</t>
<text x="128" y="308">.</text> <t>The enhancements are kept to a minimum to ensure the reuse of already
<text x="448" y="308">.</text> defined architecture elements and interactions. In general, the
<text x="140" y="324">BRSKI-AE</text> communication follows the BRSKI model and utilizes the existing BRSKI
<text x="196" y="324">over</text> architecture elements. In particular, the pledge initiates
<text x="232" y="324">TLS</text> communication with the domain registrar and interacts with the MASA as
<text x="448" y="324">.</text> usual for voucher request and response processing.</t>
<text x="132" y="340">using,</text>
<text x="184" y="340">e.g.,</text> <section anchor="architecture">
<text x="232" y="340">LCMPP</text> <name>Architecture</name>
<text x="448" y="340">.</text> <t>The key element of BRSKI-AE is that the authorization of a
<text x="128" y="356">.</text> certification request <bcp14>MUST</bcp14> be performed based on an
<text x="448" y="356">.</text> authenticated self-contained object. The certification request is
<text x="248" y="372">...............................</text> bound in a self-contained way to a proof of origin based on the IDevID
<text x="416" y="372">.........</text> credentials. Consequently, the certification request
<text x="128" y="388">on-site</text> <bcp14>MAY</bcp14> be transferred using any mechanism or
<text x="192" y="388">(local)</text> protocol. Authentication and authorization of the certification
<text x="252" y="388">domain</text> request can be done by the domain registrar and/or by backend domain
<text x="324" y="388">components</text> components. As mentioned in <xref target="sup-env"/>, these
<text x="408" y="420">e.g.,</text> components may be offline or off-site. The registrar and other
<text x="456" y="420">LCMPP</text> on-site domain components may have no or only temporary (intermittent)
<text x="192" y="452">.............................................</text> connectivity to them.</t>
<text x="440" y="452">...............</text> <t>This leads to generalizations in the placement and enhancements of
<text x="16" y="468">.</text> the logical elements as shown in <xref target="uc1figure"/>.</t>
<text x="68" y="468">Public-Key</text> <figure anchor="uc1figure">
<text x="172" y="468">Infrastructure</text>
<text x="496" y="468">.</text> <name>Architecture Overview Using Backend PKI Components</name>
<text x="16" y="484">.</text> <artset>
<text x="496" y="484">.</text> <artwork type="svg" align="left"><svg xmlns="http://www.w3.org/2000/
<text x="16" y="500">.</text> svg" version="1.1" height="576" width="544" viewBox="0 0 544 576" class="diagram
<text x="236" y="500">Registration</text> " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="
<text x="328" y="500">Authority</text> round">
<text x="380" y="500">RA</text> <path d="M 8,208 L 8,336" fill="none" stroke="black"/>
<text x="496" y="500">.</text> <path d="M 32,48 L 32,200" fill="none" stroke="black"/>
<text x="16" y="516">.</text> <path d="M 32,480 L 32,528" fill="none" stroke="black"/>
<text x="76" y="516">CA</text> <path d="M 80,208 L 80,336" fill="none" stroke="black"/>
<text x="216" y="516">(unless</text> <path d="M 112,480 L 112,528" fill="none" stroke="black"/>
<text x="268" y="516">part</text> <path d="M 152,240 L 152,304" fill="none" stroke="black"/>
<text x="300" y="516">of</text> <path d="M 160,480 L 160,528" fill="none" stroke="black"/>
<text x="340" y="516">Domain</text> <path d="M 216,240 L 216,304" fill="none" stroke="black"/>
<text x="412" y="516">Registrar)</text> <path d="M 304,240 L 304,304" fill="none" stroke="black"/>
<text x="496" y="516">.</text> <path d="M 336,32 L 336,144" fill="none" stroke="black"/>
<text x="16" y="532">.</text> <path d="M 376,312 L 376,472" fill="none" stroke="black"/>
<text x="496" y="532">.</text> <path d="M 424,240 L 424,304" fill="none" stroke="black"/>
<text x="256" y="548">.......................................................... <path d="M 456,72 L 456,144" fill="none" stroke="black"/>
...</text> <path d="M 472,152 L 472,256" fill="none" stroke="black"/>
<text x="104" y="564">backend</text> <path d="M 480,480 L 480,528" fill="none" stroke="black"/>
<text x="172" y="564">(central</text> <path d="M 536,32 L 536,144" fill="none" stroke="black"/>
<text x="220" y="564">or</text> <path d="M 336,32 L 536,32" fill="none" stroke="black"/>
<text x="272" y="564">off-site)</text> <path d="M 32,48 L 144,48" fill="none" stroke="black"/>
<text x="340" y="564">domain</text> <path d="M 224,48 L 328,48" fill="none" stroke="black"/>
<text x="412" y="564">components</text> <path d="M 336,64 L 536,64" fill="none" stroke="black"/>
</g> <path d="M 336,144 L 536,144" fill="none" stroke="black"/>
</svg> <path d="M 8,208 L 80,208" fill="none" stroke="black"/>
</artwork><artwork type="ascii-art" align="left"><![CDATA[ <path d="M 152,240 L 216,240" fill="none" stroke="black"/>
<path d="M 304,240 L 424,240" fill="none" stroke="black"/>
<path d="M 432,256 L 472,256" fill="none" stroke="black"/>
<path d="M 88,272 L 144,272" fill="none" stroke="black"/>
<path d="M 224,272 L 296,272" fill="none" stroke="black"/>
<path d="M 152,304 L 216,304" fill="none" stroke="black"/>
<path d="M 304,304 L 424,304" fill="none" stroke="black"/>
<path d="M 8,336 L 80,336" fill="none" stroke="black"/>
<path d="M 32,480 L 112,480" fill="none" stroke="black"/>
<path d="M 160,480 L 480,480" fill="none" stroke="black"/>
<path d="M 120,496 L 160,496" fill="none" stroke="black"/>
<path d="M 112,512 L 152,512" fill="none" stroke="black"/>
<path d="M 32,528 L 112,528" fill="none" stroke="black"/>
<path d="M 160,528 L 480,528" fill="none" stroke="black"/>
<polygon class="arrowhead" points="480,152 468,146.4 468,157.6"
fill="black" transform="rotate(270,472,152)"/>
<polygon class="arrowhead" points="440,256 428,250.4 428,261.6"
fill="black" transform="rotate(180,432,256)"/>
<polygon class="arrowhead" points="384,472 372,466.4 372,477.6"
fill="black" transform="rotate(90,376,472)"/>
<polygon class="arrowhead" points="384,312 372,306.4 372,317.6"
fill="black" transform="rotate(270,376,312)"/>
<polygon class="arrowhead" points="304,272 292,266.4 292,277.6"
fill="black" transform="rotate(0,296,272)"/>
<polygon class="arrowhead" points="232,272 220,266.4 220,277.6"
fill="black" transform="rotate(180,224,272)"/>
<polygon class="arrowhead" points="160,512 148,506.4 148,517.6"
fill="black" transform="rotate(0,152,512)"/>
<polygon class="arrowhead" points="152,272 140,266.4 140,277.6"
fill="black" transform="rotate(0,144,272)"/>
<polygon class="arrowhead" points="128,496 116,490.4 116,501.6"
fill="black" transform="rotate(180,120,496)"/>
<polygon class="arrowhead" points="96,272 84,266.4 84,277.6" fil
l="black" transform="rotate(180,88,272)"/>
<polygon class="arrowhead" points="40,200 28,194.4 28,205.6" fil
l="black" transform="rotate(90,32,200)"/>
<g class="text">
<text x="184" y="52">Drop-Ship</text>
<text x="372" y="52">Vendor</text>
<text x="432" y="52">Service</text>
<text x="352" y="84">M</text>
<text x="408" y="84">anufacturer</text>
<text x="352" y="100">A</text>
<text x="400" y="100">uthorized</text>
<text x="496" y="100">Ownership</text>
<text x="352" y="116">S</text>
<text x="388" y="116">igning</text>
<text x="488" y="116">Tracker</text>
<text x="352" y="132">A</text>
<text x="396" y="132">uthority</text>
<text x="508" y="196">BRSKI-</text>
<text x="288" y="212">........................................
.</text>
<text x="500" y="212">MASA</text>
<text x="128" y="228">.</text>
<text x="448" y="228">.</text>
<text x="128" y="244">.</text>
<text x="448" y="244">.</text>
<text x="44" y="260">Pledge</text>
<text x="128" y="260">.</text>
<text x="180" y="260">Join</text>
<text x="340" y="260">Domain</text>
<text x="184" y="276">Proxy</text>
<text x="352" y="276">Registrar</text>
<text x="448" y="276">.</text>
<text x="128" y="292">.</text>
<text x="324" y="292">w/</text>
<text x="352" y="292">LRA</text>
<text x="380" y="292">or</text>
<text x="404" y="292">RA</text>
<text x="448" y="292">.</text>
<text x="44" y="308">IDevID</text>
<text x="128" y="308">.</text>
<text x="448" y="308">.</text>
<text x="140" y="324">BRSKI-AE</text>
<text x="196" y="324">over</text>
<text x="232" y="324">TLS</text>
<text x="448" y="324">.</text>
<text x="132" y="340">using,</text>
<text x="184" y="340">e.g.,</text>
<text x="232" y="340">LCMPP</text>
<text x="448" y="340">.</text>
<text x="128" y="356">.</text>
<text x="448" y="356">.</text>
<text x="248" y="372">...............................</text>
<text x="416" y="372">.........</text>
<text x="128" y="388">on-site</text>
<text x="192" y="388">(local)</text>
<text x="252" y="388">domain</text>
<text x="324" y="388">components</text>
<text x="408" y="420">e.g.,</text>
<text x="456" y="420">LCMPP</text>
<text x="192" y="452">........................................
.....</text>
<text x="440" y="452">...............</text>
<text x="16" y="468">.</text>
<text x="68" y="468">Public-Key</text>
<text x="172" y="468">Infrastructure</text>
<text x="496" y="468">.</text>
<text x="16" y="484">.</text>
<text x="496" y="484">.</text>
<text x="16" y="500">.</text>
<text x="236" y="500">Registration</text>
<text x="328" y="500">Authority</text>
<text x="380" y="500">RA</text>
<text x="496" y="500">.</text>
<text x="16" y="516">.</text>
<text x="76" y="516">CA</text>
<text x="216" y="516">(unless</text>
<text x="268" y="516">part</text>
<text x="300" y="516">of</text>
<text x="340" y="516">Domain</text>
<text x="412" y="516">Registrar)</text>
<text x="496" y="516">.</text>
<text x="16" y="532">.</text>
<text x="496" y="532">.</text>
<text x="256" y="548">........................................
.....................</text>
<text x="104" y="564">backend</text>
<text x="172" y="564">(central</text>
<text x="220" y="564">or</text>
<text x="272" y="564">off-site)</text>
<text x="340" y="564">domain</text>
<text x="412" y="564">components</text>
</g>
</svg>
</artwork>
<artwork 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 731 skipping to change at line 755
| IDevID | . +-------+ +--------------+ . | IDevID | . +-------+ +--------------+ .
| | BRSKI-AE over TLS ^ . | | BRSKI-AE over TLS ^ .
+--------+ using, e.g., LCMPP | . +--------+ using, e.g., LCMPP | .
. | . . | .
...............................|......... ...............................|.........
on-site (local) domain components | on-site (local) domain components |
| |
| e.g., LCMPP | e.g., LCMPP
| |
.............................................|............... .............................................|...............
. Public-Key Infrastructure v . . Public-Key Infrastructure (PKI) 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>Join Proxy: same requirements as in BRSKI, see <xref section="4" sectionFor
mat="comma" target="RFC8995"/></t>
<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: <list style="numb
ers">
<t>The registrar <bcp14>MUST</bcp14> support at least one certificate enro
llment 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>
<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:
Note:
As far as (at least part of) the certificate enrollment traffic is routed
via the registrar, BRSKI-AE re-uses during the certificate enrollment phase
the channel that has been established in the BRSKI steps before between the
pledge and the registrar. Consequently, tunneling via this channel needs
to be supported by the certificate enrollment protocol.
By default, this channel is based on HTTP over TLS,
but it may also be based on, for instance, CoAP over DTLS
in the context of Constrained BRSKI {{I-D.ietf-anima-constrained-voucher}}.
<!--
In the latter scenario,
the EST-specific parts of that specification do not apply.
<t>Despite the above generalizations to the enrollment phase, the final
step of BRSKI, namely the enrollment status telemetry, is kept as it is.</t>
<t>The following list describes the components provided by <t>The architecture overview in <xref target="uc1figure"/> has the
the vendor or manufacturer outside the target domain.</t> same logical elements as BRSKI but with a more flexible placement of
the authentication and authorization checks on certification requests.
Depending on the application scenario, the registrar
<bcp14>MAY</bcp14> still do all of these checks (as is the case in
BRSKI) or only do part of them.</t>
<t>The following list describes the on-site components in the target
domain of the pledge shown in <xref target="uc1figure"/>.</t>
<ul spacing="normal">
<li>
<t>Join Proxy: This has the same requirements as in <xref target="RF
C8995"/> (see
<xref section="4" sectionFormat="comma" target="RFC8995"/>).</t>
</li>
<t><list style="symbols"> <li>
<t>MASA: functionality as described in BRSKI <xref target="RFC8995"/>. <t>Domain Registrar (including LRA or RA functionality): In
The voucher exchange with the MASA via the domain registrar BRSKI-AE, the domain registrar has mostly the same functionality
is performed as described in BRSKI. <vspace blankLines='1'/> as in BRSKI, namely to act as the gatekeeper of the domain for
Note: From the definition of the interaction with the MASA in onboarding new devices and to facilitate the communication of
<xref section="5" sectionFormat="comma" target="RFC8995"/> follows that it may b pledges with their MASA and the domain PKI. Yet, there are some
e synchronous (using voucher generalizations and specific requirements:</t>
request with nonces) or asynchronous (using nonceless voucher requests).</t> <ol spacing="normal" type="1"><li>
<t>Ownership tracker: as defined in BRSKI.</t> <t>The registrar <bcp14>MUST</bcp14> support at least one
</list></t> 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>
<t>The following list describes backend target domain components, <t>Despite the above generalizations of the enrollment phase, the final
which may be located on-site or off-site in the target domain.</t> step of BRSKI, namely the enrollment status telemetry, is kept as it
is.</t>
<t><list style="symbols"> <t>The following list describes the components provided by the vendor
<t>RA: performs centralized certificate management functions or manufacturer outside the target domain.</t>
as a public-key infrastructure for the domain operator.
As far as not already done by the domain registrar, it performs the final
validation and authorization of certification requests. Otherwise,
the RA co-located with the domain registrar directly connects to the CA.</t>
<t>CA, also 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 <ul spacing="normal">
t="RFC8995"/> and the architectural <li>
changes, the original protocol flow is divided into several phases <t>MASA: This has the functionality as described in <xref target="RF
showing commonalities and differences to the original approach as follows.</t> C8995"/>. The voucher exchange with the MASA via the
domain registrar is performed as described in <xref target="RFC8995"
/>.</t>
</li>
</ul>
<t><list style="symbols"> <aside>
<t>Discovery phase: mostly as in BRSKI step (1). For details see <xref target= <t>Note: The definition of the interaction with the MASA in <xref
"discovery"/>.</t> section="5" sectionFormat="of" target="RFC8995"/> implies that it
<t>Identification phase: same as in BRSKI step (2).</t> may be synchronous (using voucher requests with nonces) or
<t>Voucher exchange phase: same as in BRSKI steps (3) and (4).</t> asynchronous (using nonceless voucher requests).</t>
<t>Voucher status telemetry: same as in BRSKI directly after step (4).</t> </aside>
<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> <ul spacing="normal">
<section anchor="message_ex"><name>Message Exchange</name> <li>
<t>Ownership Tracker: This is as defined in <xref target="RFC8995"/>
.</t>
</li>
</ul>
<t>The behavior of a pledge described in BRSKI <xref section="2.1" sectionFormat <t>The following list describes backend target domain components,
="comma" target="RFC8995"/> which may be located on-site or off-site in the target domain.</t>
is kept, with one major exception. <ul spacing="normal">
After finishing the Imprint step (4), the Enroll step (5) <bcp14>MUST</bcp14> be <li>
performed <t>RA: This performs centralized certificate management functions
with an enrollment protocol utilizing authenticated self-contained objects, as a PKI for the domain operator. In case
as explained in <xref target="req-sol"/>. these functions are not entirely performed by the domain
<!-- registrar, it performs the final validation and authorization of
the certification request MUST be performed using an certification requests. Otherwise, the RA co-located with the
authenticated self-contained object providing not only proof of possession domain registrar directly connects to the CA.</t>
but also proof of identity (source authentication). </li>
<xref target="exist_prot"/> discusses selected suitable enrollment protocols <li>
and options applicable.</t> <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 <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>
<t>An abstract overview of the BRSKI-AE protocol <ul spacing="normal">
can be found at <xref target="BRSKI-AE-overview"/>.</t> <li>
<t>Discover: This is mostly as in step (1) of <xref target="RFC8995"
/>. For details, see
<xref target="discovery"/>.</t>
</li>
<li>
<t>Identify: This is the same as in step (2) of <xref target="RFC899
5"/>.</t>
</li>
<li>
<t>Voucher exchange: This is the same as in steps (3) and (4) of <xr
ef 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>
<section anchor="discovery"><name>Pledge - Registrar Discovery</name> <t>It is <bcp14>REQUIRED</bcp14> to use the (D)TLS channel
established between the pledge and registrar to transport the
certificate enrollment request and response messages. To this
end, the enrollment protocol, the pledge, and the registrar need
to support the use of this existing channel for certificate
enrollment. Due to this architecture, the pledge does not need to
establish additional connections for certificate enrollment and
the registrar retains full control over the certificate enrollment
traffic.</t>
</li>
<li>
<t>Enrollment status telemetry: This is the final exchange of step (
5) of <xref target="RFC8995"/>.</t>
</li>
</ul>
</section>
<t>Discovery as specified in BRSKI <xref section="4" sectionFormat="comma" targe <section anchor="message_ex">
t="RFC8995"/> does not support <name>Message Exchange</name>
the discovery of registrars with enhanced feature sets. <t>The behavior of a pledge described in <xref section="2.1"
A pledge can not find out in this way whether discovered registrars sectionFormat="comma" target="RFC8995"/> is kept, with one major
support the certificate enrollment protocol it expects, such as CMP.</t> 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"/>.
<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 applicable options.</t>
For further discussion, see <xref target="I-D.ietf-anima-brski-discovery"/>.</t>
<t>In the absence of such a generally applicable solution, <t>An abstract overview of the BRSKI-AE protocol can be found in the
BRSKI-AE deployments may use their particular way of doing discovery. graphics on slide 4 of <xref target="BRSKI-AE-overview"/>.</t>
<xref target="brski-cmp-instance"/> defines a minimalist approach that <bcp14>MA
Y</bcp14> be used for CMP.</t>
</section> <section anchor="discovery">
<section anchor="pledge-registrar-masa-voucher-exchange"><name>Pledge - Registra <name>Pledge - Registrar Discovery</name>
r - MASA Voucher Exchange</name> <t>Discovery as specified in <xref section="4" sectionFormat="comma"
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>
<t>The voucher exchange is performed as specified in <xref target="RFC8995"/>.</ <t>As a more general solution, the BRSKI discovery mechanism can be
t> extended to provide up-front information on the capabilities of
registrars. For further discussion, see <xref
target="I-D.ietf-anima-brski-discovery"/>.</t>
</section> <t>In the absence of such a generally applicable solution, BRSKI-AE
<section anchor="pledge-registrar-masa-voucher-status-telemetry"><name>Pledge - deployments may use their particular way of doing discovery. <xref
Registrar - MASA Voucher Status Telemetry</name> target="brski-cmp-instance"/> defines a minimalist approach that
<bcp14>MAY</bcp14> be used for CMP.</t>
</section>
<t>The voucher status telemetry is performed <section anchor="pledge-registrar-masa-voucher-exchange">
as specified in <xref section="5.7" sectionFormat="comma" target="RFC8995"/>.</t <name>Pledge - Registrar - MASA Voucher Exchange</name>
> <t>The voucher exchange is performed as specified in <xref
target="RFC8995"/>.</t>
</section>
</section> <section anchor="pledge-registrar-masa-voucher-status-telemetry">
<section anchor="pledge-registrar-raca-certificate-enrollment"><name>Pledge - Re <name>Pledge - Registrar - MASA Voucher Status Telemetry</name>
gistrar - RA/CA Certificate Enrollment</name> <t>The voucher status telemetry is performed as specified in <xref
section="5.7" sectionFormat="comma" target="RFC8995"/>.</t>
</section>
<t>This replaces the EST integration for PKI bootstrapping described in <section anchor="pledge-registrar-raca-certificate-enrollment">
<xref section="5.9" sectionFormat="comma" target="RFC8995"/> <name>Pledge - Registrar - RA/CA Certificate Enrollment</name>
(while <xref section="5.9.4" sectionFormat="comma" target="RFC8995"/> remains as <t>The specification in this section replaces the EST integration
the final phase, see below).</t> 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 mess <t>The certificate enrollment phase may involve the transmission of
ages. several messages. Details can depend on the application scenario,
Details can depend on the application scenario, the employed enrollment protocol, and other factors.
the employed enrollment protocol, and other factors. </t>
<!-- <br> <t>The only message exchange <bcp14>REQUIRED</bcp14> is for the
In line with the generalizations described in {{architecture}}, actual certification request and response. Further message
It is RECOMMENDED to transfer these messages exchanges <bcp14>MAY</bcp14> be performed as needed.</t>
via the channel established between the pledge and the registrar.
<t>The only message exchange <bcp14>REQUIRED</bcp14> is for <aside>
the actual certification request and response. <t>Note: The message exchanges marked <bcp14>OPTIONAL</bcp14> in
Further message exchanges <bcp14>MAY</bcp14> be performed as needed.</t> <xref target="enrollfigure"/> below cover all those supported by
the use of EST in BRSKI. The last <bcp14>OPTIONAL</bcp14> one,
namely certificate confirmation, is not supported by EST but by
CMP and other enrollment protocols.</t>
</aside>
<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 1173
| |---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
Messages should be sent as soon as sufficient transfer capacity is available.</t PKI components of the operator (RA, CA, etc.) may be intermittent or
> offline. Messages should be sent as soon as sufficient transfer
capacity is available.</t>
<t>The label <spanx style="verb">[OPTIONAL forwarding]</spanx> in <xref target="
enrollfigure"/>
means that on receiving from a pledge a request message of the given type,
the registrar <bcp14>MAY</bcp14> answer the request directly.
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.
Otherwise, the registrar <bcp14>MUST</bcp14> forward the request to the RA
and forward any resulting response back to the pledge.</t>
<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,
the capabilities of the registrar and of the local RA possibly co-located
with the registrar, the enrollment protocol being used, and the specific
contents of the request.</t>
<t>Note that
there are several options for how the registrar could be able to directly answer
requests for CA certificates or for certification request attributes.
It could cache responses obtained from the domain PKI and
later use their contents for responding to requests asking for the same data.
The contents could also be explicitly provisioned at the registrar.</t>
<t>Further note that
certification requests typically need to be handled by the backend PKI,
but the registrar can answer them directly with an error response
in case it determines that such a request should be rejected,
for instance, because is not properly authenticated or not authorized.<!--br-->
Also, certificate confirmation messages
will usually be forwarded to the backend PKI,
but if the registrar knows that they are not needed or wanted there
it can acknowledge such messages directly.</t>
<t>The following list provides an abstract description of the flow
depicted in <xref target="enrollfigure"/>.</t>
<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
described above is independent of the mandatory enrollment status telemetry
done between the pledge and the registrar in the final phase of BRSKI-AE,
described next.</t>
</section>
<section anchor="pledge-registrar-enrollment-status-telemetry"><name>Pledge - Re
gistrar Enrollment Status Telemetry</name>
<t>The enrollment status telemetry is performed
as specified in <xref section="5.9.4" sectionFormat="comma" target="RFC8995"/>.<
/t>
<t>In BRSKI this is described as part of the certificate enrollment step, but
due to the generalization on the enrollment protocol described in this document
it is regarded as a separate phase here.</t>
</section>
</section>
<section anchor="addressing"><name>Enhancements to the Endpoint Addressing Schem
e of BRSKI</name>
<t>BRSKI-AE extends the addressing scheme outlined in <xref section="5" sectionF
ormat="comma" target="RFC8995"/>,
to support alternative enrollment protocols that utilize authenticated,
self-contained objects for certification requests -- see also <xref target="exis
t_prot"/>).
These extensions are designed to be compatible with existing Registration
Authorities (RAs) and Certification Authorities (CAs) that already support such
enrollment protocols, enabling their use without requiring any modifications.</t
>
<t>The addressing scheme in BRSKI for certification requests and
the related CA certificates and CSR attributes retrieval functions
uses the definition from EST <xref target="RFC7030"/>.
Here is the example of simple enrollment: <spanx style="verb">"/.well-known/est/
simpleenroll"</spanx>.
This approach is generalized to the following notation:
<spanx style="verb">"/.well-known/&lt;enrollment-protocol&gt;/&lt;request&gt;"</
spanx>
in which <spanx style="verb">&lt;enrollment-protocol&gt;</spanx> refers to a cer
tificate enrollment protocol.
Note that enrollment is considered here a message sequence
that contains at least a certification request and a certification response.
The following conventions are used to provide maximal compatibility with BRSKI:<
/t>
<t><list style="symbols">
<t><spanx style="verb">&lt;enrollment-protocol&gt;</spanx>: <bcp14>MUST</bcp14
> reference the protocol being used.
Existing values include '<spanx style="verb">est</spanx>' <xref target="RFC7030"
/> 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>Well-known URIs for various endpoints on the domain registrar are
already defined as part of the base BRSKI specification or indirectly by EST.
In addition, alternative enrollment endpoints <bcp14>MAY</bcp14> be supported by
the registrar.</t>
<t>A pledge <bcp14>SHOULD</bcp14> use the endpoints defined for the enrollment p
rotocol(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
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
a domain registrar supporting several options for EST as well as for
CMP to be used in BRSKI-AE. The listing contains the supported
endpoints to which the pledge may connect for bootstrapping. This
includes the voucher handling as well as the enrollment endpoints.
The CMP-related enrollment endpoints are defined as well-known URIs
in CMP Updates <xref target="RFC9480"/> and the Lightweight CMP Profile <xref ta
rget="RFC9483"/>.</t>
<figure><artwork align="left"><![CDATA[
/.well-known/brski/voucherrequest
/.well-known/brski/voucher_status
/.well-known/brski/enrollstatus
/.well-known/est/cacerts
/.well-known/est/csrattrs
/.well-known/est/fullcmc
/.well-known/cmp/getcacerts
/.well-known/cmp/getcertreqtemplate
/.well-known/cmp/initialization
/.well-known/cmp/pkcs10
]]></artwork></figure>
</section>
</section>
<section anchor="exist_prot"><name>Instantiation with Existing Enrollment Protoc
ols</name>
<t>This section maps the generic requirements to support proof of possession
and proof of identity to selected existing certificate enrollment protocols
and specifies further aspects of using such enrollment protocols in BRSKI-AE.</t
>
<section anchor="brski-cmp-instance"><name>BRSKI-CMP: BRSKI-AE instantiated with
CMP</name>
<t>In this document, references to CMP follow the Lightweight CMP Profile (LCMPP
)
<xref target="RFC9483"/> rather than <xref target="RFC4210"/> and <xref target="
RFC9480"/>, as the subset of CMP
defined in LCMPP sufficiently meets the required functionality.</t>
<t>Adherence to the LCMPP <xref target="RFC9483"></xref> is <bcp14>REQUIRED</bcp
14> when using CMP.
The following specific requirements apply (refer to <xref target="enrollfigure"/
>):</t>
<t><list style="symbols">
<t>The validation of server response messages performed by the CMP client
within the pledge <bcp14>MUST</bcp14> be based on the trust anchor established b
eforehand
via the BRSKI voucher, i.e., on the pinned-domain-cert. <vspace blankLines='1'/
>
Note that the integrity and authenticity checks on the RA/CA
by the CMP client can be stronger than for EST because
they do not need to be performed hop-by-hop, but are usually end-to-end.</t>
<t>CA Certs Request (1) and Response (2):<br />
Requesting CA certificates is <bcp14>OPTIONAL</bcp14>.<br />
If supported, it <bcp14>SHALL</bcp14> be implemented as specified in
<xref section="4.3.1" sectionFormat="comma" target="RFC9483"/>.</t>
<t>Attribute Request (3) and Response (4):<br />
Requesting certification request attributes is <bcp14>OPTIONAL</bcp14>.<br />
If supported, it <bcp14>SHALL</bcp14> be implemented as specified in
<xref section="4.3.3" sectionFormat="comma" target="RFC9483"/>. <vspace blankLi
nes='1'/>
Alternatively, the registrar <bcp14>MAY</bcp14> modify
the requested certificate contents
as specified in <xref section="5.2.3.2" sectionFormat="comma" target="RFC9483"/>
.</t>
<t>Certification Request (5) and Response (6):<br />
Certificates <bcp14>SHALL</bcp14> be requested and provided
as specified in LCMPP
<xref section="4.1.1" sectionFormat="comma" target="RFC9483"/> (based on CRMF) o
r
<xref section="4.1.4" sectionFormat="comma" target="RFC9483"/> (based on PKCS #1
0). <vspace blankLines='1'/>
Proof of possession <bcp14>SHALL</bcp14> be provided in a manner suitable for th
e key type.
Proof of identity <bcp14>SHALL</bcp14> be provided by signature-based
protection of the certification request message
as outlined in <xref section="3.2" sectionFormat="comma" target="RFC9483"/>, usi
ng the IDevID secret. <vspace blankLines='1'/>
When the registrar forwards a certification request from the pledge to
a backend RA/CA, it is <bcp14>RECOMMENDED</bcp14> that the registrar wraps the o
riginal
certification request in a nested message signed with its own credentials,
as described in <xref section="5.2.2.1" sectionFormat="comma" target="RFC9483"/>
.
This approach explicitly conveys the registrar's consent to the RA
while retaining the original certification request
with the proof of origin provided by the pledge's signature. <vspace blankLines
='1'/>
If additional trust anchors, beyond the pinned-domain-cert,
need to be conveyed to the pledge,
this <bcp14>SHOULD</bcp14> be done in the <spanx style="verb">caPubs</spanx> fie
ld of the certification response
rather than through a CA Certs Response.</t>
<t>Certificate Confirm (7) and PKI/Registrar Confirm (8):<br />
Explicit confirmation of new certificates to the RA/CA
<bcp14>MAY</bcp14> be used as specified in <xref section="4.1.1" sectionFormat="
comma" target="RFC9483"/>. <vspace blankLines='1'/>
Note that independent of the certificate confirmation within CMP,
enrollment status telemetry with the registrar at the BRSKI level
will be performed as described in <xref section="5.9.4" sectionFormat="comma" ta
rget="RFC8995"/>.</t>
<t>If delayed delivery of CMP messages is needed
(e.g., to support enrollment over an asynchronous channel),
it <bcp14>SHALL</bcp14> be performed as specified in
Section <xref target="RFC9483" section="4.4" sectionFormat="bare"/> and Section
<xref target="RFC9483" section="5.1.2" sectionFormat="bare"/> of <xref target="R
FC9483"/>.</t>
</list></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 <xref target="sec-consider"/> and <xref target="priv-consider"/>.
Further guidance can be found in <xref section="6" sectionFormat="comma" target=
"RFC9483"/>.</t>
<!--
CMP Updates {{RFC9480}} and
the LCMPP {{RFC9483}}
provide requirements for interoperability.
<t>BRSKI-AE with CMP can also be combined with <t>The label '<tt>[OPTIONAL forwarding]</tt>' in <xref
Constrained BRSKI <xref target="I-D.ietf-anima-constrained-voucher"/>, target="enrollfigure"/> means that on receiving a request message of
using CoAP for enrollment message transport as described by the given type from a pledge, the registrar <bcp14>MAY</bcp14>
CoAP Transport for CMP <xref target="RFC9482"/>. answer the request directly. In this case, it <bcp14>MUST</bcp14>
In such scenarios, the EST-specific parts authenticate its responses with the same credentials as used for
of <xref target="I-D.ietf-anima-constrained-voucher"/> do not apply.</t> authenticating itself at the TLS level for the voucher exchange.
Otherwise, the registrar <bcp14>MUST</bcp14> forward the request to
the RA and forward any resulting response back to the pledge.</t>
<t>For BRSKI-AE scenarios where a general solution for discovering registrars <t>The decision of whether to forward a request or to answer it
with CMP support is not available (cf. <xref target="discovery"/>), directly can depend on various static and dynamic factors. They
the following minimalist approach <bcp14>MAY</bcp14> be used: include the application scenario, the capabilities of the registrar,
perform discovery as defined in BRSKI <xref section="B" sectionFormat="comma" ta the capabilities of the local RA possibly co-located with the
rget="RFC8995"/>, but use registrar, the enrollment protocol being used, and the specific
the service name <spanx style="verb">"brski-reg-cmp"</spanx> (as defined in <xre contents of the request.</t>
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>Note that there are several options for how the registrar could be a
<section anchor="support-of-other-enrollment-protocols"><name>Support of Other E ble to
nrollment Protocols</name> directly answer requests for CA certificates or for certification reque
st
attributes. It could cache responses obtained from the domain PKI and
later
use their contents for responding to requests asking for the same data.
The
contents could also be explicitly provisioned at the registrar.</t>
<t>Further instantiations of BRSKI-AE can be done. They are left for future wor <t>Further note that certification requests typically need to be
k.</t> handled by the backend PKI, but the registrar can answer them
directly with an error response in case it determines that such a
request should be rejected, for instance, because it is not properly
authenticated or authorized. Also, certificate confirmation
messages will usually be forwarded to the backend PKI, but if the
registrar knows that they are not needed or wanted there, it can
acknowledge such messages directly.</t>
<t>In particular, CMC <xref target="RFC5272"/> (using its in-band source authent <t>The following list provides an abstract description of the flow
ication options) depicted in <xref target="enrollfigure"/>.</t>
and SCEP <xref target="RFC8894"/> (using its 'renewal' option) could be used.</t <ul spacing="normal">
>
<t>The fullCMC variant of EST sketched in <xref section="2.5" sectionFormat="com <li>
ma" target="RFC7030"/> <t>CA Certs Request (1): The pledge optionally requests the latest
might also be used here. For EST-fullCMC further specification is necessary. relevant
<!-- CA certificates. This ensures that the pledge has the
Yet most likely it will not be followed up complete set of current CA certificates beyond the
because, by now, no implementations of this EST variant are known, pinned-domain-cert (which is contained in the voucher
and no reasons are known why it could be preferable over using BRSKI-CMP. 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>
<!-- <li>
## BRSKI-EST-fullCMC: Application to EST <t>Attribute Response (4): This <bcp14>MUST</bcp14> contain the
attributes requested in (3) to be included in the subsequent
Certification Request (5).</t>
When using EST {{RFC7030}}, the following aspects and constraints <t>For example, <xref section="6.11.7.2" sectionFormat="comma"
need to be considered and the given extra requirements need to be fulfilled, target="RFC8994"/> specifies how the attribute request is used
which adapt BRSKI {{RFC8995, Section 5.9.3}}: to signal to the pledge the 'acp-node-name' field required for
enrollment into an Autonomic Control Plane (ACP) domain.</t>
</li>
* Proof of possession is provided typically by using the specified PKCS #10 <li>
structure in the request. <t>Certification Request (5): This <bcp14>MUST</bcp14> contain
Together with Full PKI requests, also CRMF can be used. 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>
* Proof of identity needs to be achieved by signing the certification request <aside>
object using the Full PKI Request option (including the /fullcmc endpoint). <t>Note that the optional certificate confirmation by the pledge
This provides sufficient information for the RA to authenticate the pledge to the PKI described above is independent of the mandatory
as the origin of the request and to make an authorization decision on the enrollment status telemetry done between the pledge and the
received certification request. registrar in the final phase of BRSKI-AE, which is described
Note: next.</t>
EST references CMC {{RFC5272}} for the definition of the Full PKI Request. </aside>
For proof of identity, the signature of the SignedData of the Full PKI Request
is performed using the IDevID secret of the pledge. The data signed
must include include a sufficiently strong identifier of the pledge,
e.g, the subject of its IDevID certificate.
Note: </section>
In this case the binding to the underlying TLS channel is not necessary.
* When the RA is temporarily not available, as per {{RFC7030, Section 4.2.3}}, <section anchor="pledge-registrar-enrollment-status-telemetry">
an HTTP status code 202 should be returned by the registrar, <name>Pledge - Registrar Enrollment Status Telemetry</name>
and the pledge will repeat the initial Full PKI Request later. <t>The enrollment status telemetry is performed as specified in
<xref section="5.9.4" sectionFormat="comma" target="RFC8995"/>.</t>
<t>In <xref target="RFC8995"/>, this is described as part of the certi
ficate enrollment
step, but due to the generalization of the enrollment protocol
described in this document, it is regarded as a separate phase
here.</t>
</section>
</section>
<!-- <section anchor="addressing">
Note that the work in the ACE WG described in <name>Enhancements to the Endpoint Addressing Scheme of BRSKI</name>
{{draft-selander-ace-coap-est-oscore}} may be considered here as well, <t>BRSKI-AE extends the addressing scheme outlined in <xref
as it also addresses the encapsulation of EST in a way that section="5" sectionFormat="comma" target="RFC8995"/> to support
makes it independent of the underlying TLS channel using OSCORE, alternative enrollment protocols that utilize authenticated,
which also entails that authenticated self-contained objects are used. self-contained objects for certification requests (also see <xref
target="exist_prot"/>). These extensions are designed to be
compatible with existing Registration Authorities (RAs) and
Certification Authorities (CAs) that already support such enrollment
protocols, enabling their use without requiring any modifications.</t>
<t>The addressing scheme in <xref target="RFC8995"/> for certification r
equests,
related CA certificates, and CSR attributes retrieval functions uses the
definition from EST <xref target="RFC7030"/>. An example of
simple enrollment is: <tt>"/.well-known/est/simpleenroll"</tt>. This
approach is generalized to the following notation:
<tt>"/.well-known/&lt;enrollment-protocol&gt;/&lt;request&gt;"</tt> in
which "<tt>&lt;enrollment-protocol&gt;</tt>" refers to a certificate
enrollment protocol. Note that here, enrollment is considered a
message sequence that contains at least a certification request and a
certification response. The following conventions are used to provide
maximal compatibility with BRSKI:</t>
<ul spacing="normal">
<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 <xref target="RFC8995"
/> 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>
</section> <t>Well-known URIs for various endpoints on the domain registrar are
</section> already defined as part of the base BRSKI specification or indirectly
<section anchor="iana-consider"><name>IANA Considerations</name> by EST. In addition, alternative enrollment endpoints
<bcp14>MAY</bcp14> be supported by the registrar.</t>
<t>This document requires one IANA action: register in the <t>A pledge <bcp14>SHOULD</bcp14> use the endpoints defined for the
<eref target="https://www.iana.org/assignments/service-names-port-numbers/servic enrollment protocol(s) that it can use. It will recognize whether the
e-names-port-numbers.xhtml">Service Name and Transport Protocol Port Number Regi protocol it uses and the specific request it wants to perform are
stry</eref> understood and supported by the domain registrar. This is done by
the following service name.</t> 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><strong>Service Name:</strong> brski-reg-cmp<br /> <t>The following list of endpoints provides an illustrative example of
<strong>Transport Protocol(s):</strong> tcp<br /> a domain registrar supporting several options for EST as well as for
<strong>Assignee:</strong> IESG <eref target="mailto:iesg@ietf.org">iesg@ietf.or CMP to be used in BRSKI-AE. The listing contains the supported
g</eref><br /> endpoints to which the pledge may connect for bootstrapping. This
<strong>Contact:</strong> IETF <eref target="mailto:chair@ietf.org">chair@ietf.o includes the voucher handling as well as the enrollment endpoints.
rg</eref><br /> The CMP-related enrollment endpoints are defined as well-known URIs in
<strong>Description:</strong> Bootstrapping Remote Secure Key Infrastructure reg CMP Updates <xref target="RFC9480"/> and the Lightweight CMP Profile
istrar with <xref target="RFC9483"/>.</t>
CMP capabilities according to the Lightweight CMP Profile (LCMPP, <xref target="
RFC9483"/>)<br />
<strong>Reference:</strong> [THISRFC]</t>
<t>Note: <ul spacing="normal">
We chose here the suffix "cmp" rather than some other abbreviation like "lcmpp" <li>/.well-known/brski/voucherrequest</li>
mainly because this document defines the normative CMP instantiation of <li>/.well-known/brski/voucher_status</li>
BRSKI-AE, which implies adherence to LCMPP is necessary and sufficient.</t> <li>/.well-known/brski/enrollstatus</li>
<li>/.well-known/est/cacerts</li>
<li>/.well-known/est/csrattrs</li>
<li>/.well-known/est/fullcmc</li>
<li>/.well-known/cmp/getcacerts</li>
<li>/.well-known/cmp/getcertreqtemplate</li>
<li>/.well-known/cmp/initialization</li>
<li>/.well-known/cmp/pkcs10</li>
</ul>
</section> </section>
<section anchor="sec-consider"><name>Security Considerations</name> </section>
<section anchor="exist_prot">
<name>Instantiation with Existing Enrollment Protocols</name>
<t>This section maps the generic requirements to support proof of
possession and proof of identity to selected existing certificate
enrollment protocols and specifies further aspects of using such
enrollment protocols in BRSKI-AE.</t>
<t>The security considerations laid out in BRSKI <xref section="11" sectionForma <section anchor="brski-cmp-instance">
t="comma" target="RFC8995"/> apply to the <name>BRSKI-CMP: BRSKI-AE Instantiated with CMP</name>
discovery and voucher exchange as well as for the status exchange information.</
t>
<t>In particular, <t>In this document, references to CMP follow the Lightweight CMP
even if the registrar delegates part or all of its RA role Profile (LCMPP) from <xref target="RFC9483"/> rather than <xref
during certificate enrollment to a separate system, target="RFC4210"/> and <xref target="RFC9480"/>, as the subset of CMP
it still must be made sure that the registrar takes part in the decision defined in the LCMPP sufficiently meets the required functionality.</t>
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>Adherence to the LCMPP <xref target="RFC9483"/> is
<t>implicit consent</t> <bcp14>REQUIRED</bcp14> when using CMP. The following specific
<t>the registrar signals its consent to the RA out-of-band before or during requirements apply (refer to <xref target="enrollfigure"/>):</t>
the enrollment phase, for instance by entering the pledge identity in a database <ul spacing="normal">
.</t> <li>
<t>the registrar provides its consent using an extra message that is transferr <t>The validation of server response messages performed by the CMP
ed client within the pledge <bcp14>MUST</bcp14> be based on the trust
on the same channel as the enrollment messages, possibly in a TLS tunnel.</t> anchor established beforehand via the BRSKI voucher, i.e., on the
<t>the registrar explicitly states its consent by signing, in addition to the pinned-domain-cert.</t>
pledge, <t>Note that the integrity and authenticity checks on the RA/CA by
the authenticated self-contained certificate enrollment request message.</t> the CMP client can be stronger than for EST because they do not
</list></t> need to be performed hop-by-hop but are usually end-to-end.</t>
</li>
<li>
<t>CA Certs Request (1) and Response (2): Requesting CA
certificates is <bcp14>OPTIONAL</bcp14>. If supported, it
<bcp14>SHALL</bcp14> be implemented as specified in <xref
section="4.3.1" sectionFormat="comma" target="RFC9483"/>.</t>
</li>
<li>
<t>Attribute Request (3) and Response (4): Requesting
certification request attributes is <bcp14>OPTIONAL</bcp14>. If
supported, it <bcp14>SHALL</bcp14> be implemented as specified in
<xref section="4.3.3" sectionFormat="comma" target="RFC9483"/>.</t>
<t>Alternatively, the registrar <bcp14>MAY</bcp14> modify the
requested certificate contents as specified in <xref
section="5.2.3.2" sectionFormat="comma" target="RFC9483"/>.</t>
</li>
<li>
<t>Certification Request (5) and Response (6): Certificates
<bcp14>SHALL</bcp14> be requested and provided as specified in the
LCMPP from <xref section="4.1.1" sectionFormat="comma"
target="RFC9483"/> (based on CRMF) or <xref section="4.1.4"
sectionFormat="comma" target="RFC9483"/> (based on PKCS #10).
</t>
<t>
Proof of possession <bcp14>SHALL</bcp14> be provided in a manner
suitable for the key type. Proof of identity
<bcp14>SHALL</bcp14> be provided by signature-based protection
of the certification request message as outlined in <xref
section="3.2" sectionFormat="comma" target="RFC9483"/> using
the IDevID secret.</t>
<t>
When the registrar forwards a certification request from the
pledge to a backend RA/CA, it is <bcp14>RECOMMENDED</bcp14> that
the registrar wraps the original certification request in a
nested message signed with its own credentials, as described in
<xref section="5.2.2.1" sectionFormat="comma"
target="RFC9483"/>. This approach explicitly conveys the
registrar's consent to the RA while retaining the original
certification request with the proof of origin provided by the
pledge's signature. </t>
<t>
If additional trust anchors beyond the pinned-domain-cert need
to be conveyed to the pledge, this <bcp14>SHOULD</bcp14> be done
in the '<tt>caPubs</tt>' field of the certification response
rather than through a CA Certs Response.</t>
</li>
<li>
<t>Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit
confirmation of new certificates to the RA/CA <bcp14>MAY</bcp14>
be used as specified in <xref section="4.1.1"
sectionFormat="comma" target="RFC9483"/>.</t>
</li>
</ul>
<t>Note: If EST was used, the registrar could give implicit consent on a <aside>
certification request by forwarding the request to a PKI entity using a <t>Note that independent of the certificate confirmation within CMP,
connection authenticated with a certificate containing an id-kp-cmcRA extension. enrollment status telemetry with the registrar at the BRSKI level
</t> will be performed as described in <xref section="5.9.4"
sectionFormat="comma" target="RFC8995"/>.</t>
</aside>
<t>When CMP is used, the security considerations laid out in the <ul spacing="normal">
LCMPP <xref target="RFC9483"/> apply.</t> <li>
<t>If delayed delivery of CMP messages is needed (e.g., to support
enrollment over an asynchronous channel), it <bcp14>SHALL</bcp14>
be performed as specified in Sections <xref target="RFC9483"
section="4.4" sectionFormat="bare"/> and <xref
target="RFC9483" section="5.1.2" sectionFormat="bare"/> of <xref
target="RFC9483"/>.</t>
</li>
</ul>
<t>The mechanisms for exchanging messages between the registrar and
backend PKI components (i.e., RA and/or CA) are outside the scope of
this document. CMP's independence from the message transfer mechanism
allows for flexibility in choosing the appropriate exchange method
based on the application scenario. For the applicable security and
privacy considerations, refer to Sections <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>
</section> <t>BRSKI-AE with CMP can also be combined with Constrained BRSKI <xref
<section anchor="priv-consider"><name>Privacy Considerations</name> target="I-D.ietf-anima-constrained-voucher"/>, using CoAP for
enrollment message transport as described by CoAP Transfer for CMP <xref
target="RFC9482"/>. In such scenarios, the EST-specific parts
of <xref target="I-D.ietf-anima-constrained-voucher"/> do not
apply.</t>
<t>The privacy considerations laid out in BRSKI <xref section="10" sectionFormat <t>For BRSKI-AE scenarios where a general solution for discovering
="comma" target="RFC8995"/> apply as well.</t> 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 <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>Note that CMP messages themselves are not encrypted. <section anchor="support-of-other-enrollment-protocols">
This may give eavesdroppers insight into which devices are bootstrapped into the <name>Support of Other Enrollment Protocols</name>
domain. <t>Further instantiations of BRSKI-AE can be done. They are left for
This in turn might also be used to selectively block the enrollment future work.</t>
of certain devices.</t>
<t>To prevent such issues, the underlying message transport channel can be encry <t>In particular, CMC <xref target="RFC5272"/> (using its in-band
pted. source authentication options) and SCEP <xref target="RFC8894"/>
This is already provided by TLS between the pledge and the registrar, and (using its 'renewal' option) could be used.</t>
for the onward exchange with backend systems, encryption may need to be added.</
t>
</section> <t>The fullCMC variant of EST sketched in <xref section="2.5"
<section anchor="acknowledgments"><name>Acknowledgments</name> sectionFormat="comma" target="RFC7030"/> might also be used here. For
EST-fullCMC, further specification is necessary.
</t>
</section>
<t>We thank Eliot Lear </section>
for his contributions as a co-author at an earlier draft stage.</t> <section anchor="iana-consider">
<name>IANA Considerations</name>
<t>IANA has registered the following service name in the <eref
target="https://www.iana.org/assignments/service-names-port-numbers/servic
e-names-port-numbers.xhtml" brackets="angle">"Service
Name and Transport Protocol Port Number Registry"</eref>.</t>
<dl spacing="compact" newline="false">
<dt>Service Name:</dt><dd>brski-reg-cmp</dd>
<dt>Transport Protocol(s):</dt><dd>tcp</dd>
<dt>Description:</dt><dd>Bootstrapping Remote Secure Key
Infrastructure registrar with CMP capabilities according to the
Lightweight CMP Profile (LCMPP) <xref target="RFC9483"/></dd>
<dt>Assignee:</dt><dd>IESG <eref target="mailto:iesg@ietf.org">iesg@ietf
.org</eref></dd>
<dt>Contact:</dt><dd>IETF <eref target="mailto:chair@ietf.org">chair@iet
f.org</eref></dd>
<dt>Reference:</dt><dd>RFC 9733</dd>
</dl>
<aside>
<t>Note: We chose the suffix "cmp" here rather than some other
abbreviation like "lcmpp" mainly because this document defines the
normative CMP instantiation of BRSKI-AE, which implies adherence to
the LCMPP is necessary and sufficient.</t>
</aside>
</section>
<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 <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>
<aside>
<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>
</aside>
<t>When CMP is used, the security considerations laid out in the LCMPP fro
m <xref target="RFC9483"/> apply.</t>
</section>
</section> <section anchor="priv-consider">
<name>Privacy Considerations</name>
<t>The privacy considerations laid out in <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>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher
-25"/>
</reference>
<reference anchor="BRSKI-AE-overview" >
<front>
<title>BRSKI-AE Protocol Overview</title>
<author initials="" surname="S.&nbsp;Fries" fullname="S.&nbsp;Fries">
<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">
<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">
<front>
<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">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate Request Message
Format (CRMF)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="September" year="2005"/>
<abstract>
<t>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">
<front>
<title>Certificate Management over CMS (CMC)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<author fullname="M. Myers" initials="M." surname="Myers"/>
<date month="June" year="2008"/>
<abstract>
<t>This document defines the base syntax for CMC, a Certificate Management
protocol using the Cryptographic Message Syntax (CMS). This protocol addresses
two immediate needs within the Internet Public Key Infrastructure (PKI) communit
y:</t>
<t>1. The need for an interface to public key certification products and s
ervices based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t>
<t>2. The need for a PKI enrollment protocol for encryption only keys due
to algorithm or hardware design.</t>
<t>CMC also requires the use of the transport document and the requirement
s usage document along with this document for a full definition. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5272"/>
<seriesInfo name="DOI" value="10.17487/RFC5272"/>
</reference>
<reference anchor="RFC5652"> <references>
<front> <name>References</name>
<title>Cryptographic Message Syntax (CMS)</title> <references anchor="sec-normative-references">
<author fullname="R. Housley" initials="R." surname="Housley"/> <name>Normative References</name>
<date month="September" year="2009"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<abstract> 280.xml"/>
<t>This document describes the Cryptographic Message Syntax (CMS). This sy <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messa 995.xml"/>
ge content. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</abstract> 483.xml"/>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<reference anchor="RFC5929"> <!-- [IEEE_802.1AR-2018] -->
<front> <reference anchor="IEEE_802.1AR-2018" target="https://ieeexplore.ieee.or
<title>Channel Bindings for TLS</title> g/document/8423794">
<author fullname="J. Altman" initials="J." surname="Altman"/> <front>
<author fullname="N. Williams" initials="N." surname="Williams"/> <title>IEEE Standard for Local and Metropolitan Area Networks - Secu
<author fullname="L. Zhu" initials="L." surname="Zhu"/> re Device Identity</title>
<date month="July" year="2010"/> <author>
<abstract> <organization>IEEE</organization>
<t>This document defines three channel binding types for Transport Layer S </author>
ecurity (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in a <date year="2018" month="August"/>
ccordance with RFC 5056 (On Channel Binding).</t> </front>
<t>Note that based on implementation experience, this document changes the <seriesInfo name="IEEE" value="802.1AR-2018"/>
original definition of 'tls-unique' channel binding type in the channel binding <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/>
type IANA registry. [STANDARDS-TRACK]</t> </reference>
</abstract>
</front>
<seriesInfo name="RFC" value="5929"/>
<seriesInfo name="DOI" value="10.17487/RFC5929"/>
</reference>
<reference anchor="RFC6955"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Diffie-Hellman Proof-of-Possession Algorithms</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="J. Schaad" initials="J." surname="Schaad"/> 174.xml"/>
<author fullname="H. Prafullchandra" initials="H." surname="Prafullchandra"/
>
<date month="May" year="2013"/>
<abstract>
<t>This document describes two methods for producing an integrity check va
lue from a Diffie-Hellman key pair and one method for producing an integrity che
ck value from an Elliptic Curve key pair. This behavior is needed for such opera
tions as creating the signature of a Public-Key Cryptography Standards (PKCS) #1
0 Certification Request. These algorithms are designed to provide a Proof-of-Pos
session of the private key and not to be a general purpose signing algorithm.</t
>
<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"> </references>
<front>
<title>Enrollment over Secure Transport</title>
<author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin
"/>
<author fullname="P. Yee" initials="P." role="editor" surname="Yee"/>
<author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/
>
<date month="October" year="2013"/>
<abstract>
<t>This document profiles certificate enrollment for clients using Certifi
cate Management over CMS (CMC) messages over a secure transport. This profile, c
alled Enrollment over Secure Transport (EST), describes a simple, yet functional
, certificate management protocol targeting Public Key Infrastructure (PKI) clie
nts that need to acquire client certificates and associated Certification Author
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"> <references anchor="sec-informative-references">
<front> <name>Informative References</name>
<title>A Voucher Artifact for Bootstrapping Protocols</title>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/>
<author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
<author fullname="T. Eckert" initials="T." surname="Eckert"/>
<date month="May" year="2018"/>
<abstract>
<t>This document defines a strategy to securely assign a pledge to an owne
r using an artifact signed, directly or indirectly, by the pledge's manufacturer
. This artifact is known as a "voucher".</t>
<t>This document defines an artifact format as a YANG-defined JSON 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"> <!-- [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>Simple Certificate Enrolment Protocol</title> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<author fullname="P. Gutmann" initials="P." surname="Gutmann"/> .ietf-anima-constrained-voucher.xml"/>
<date month="September" year="2020"/>
<abstract>
<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="BRSKI-AE-overview" target="https://datatracker.ietf.o
<front> rg/meeting/116/materials/slides-116-anima-update-on-brski-ae-alternative-enrollm
<title>An Autonomic Control Plane (ACP)</title> ent-protocols-in-brski-00">
<author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/> <front>
<author fullname="M. Behringer" initials="M." role="editor" surname="Behring <title>Update on BRSKI-AE: Alternative Enrollment Protocols in BRSKI
er"/> </title>
<author fullname="S. Bjarnason" initials="S." surname="Bjarnason"/> <author initials="D." surname="von Oheimb" fullname="David von Oheim
<date month="May" year="2021"/> b" role="editor">
<abstract> <organization/>
<t>Autonomic functions need a control plane to communicate, which depends </author>
on some addressing and routing. This Autonomic Control Plane should ideally be s <author initials="S." surname="Fries" fullname="Steffen Fries">
elf-managing and be as independent as possible of configuration. This document d <organization/>
efines such a plane and calls it the "Autonomic Control Plane", with the primary </author>
use as a control plane for autonomic functions. It also serves as a "virtual ou <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhau
t-of-band channel" for Operations, Administration, and Management (OAM) communic s">
ations over a network that provides automatically configured, hop-by-hop authent <organization/>
icated and encrypted communications via automatically configured IPv6 even when </author>
the network is not configured or is misconfigured.</t> <date year="2023" month="March"/>
</abstract> </front>
</front> <refcontent>IETF 116 - ANIMA Working Group Presentation</refcontent>
<seriesInfo name="RFC" value="8994"/> </reference>
<seriesInfo name="DOI" value="10.17487/RFC8994"/>
</reference>
<reference anchor="RFC9148"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 986.xml"/>
<title>EST-coaps: Enrollment over Secure Transport with the Secure Constrain <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
ed Application Protocol</title> 210.xml"/>
<author fullname="P. van der Stok" initials="P." surname="van der Stok"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/> 211.xml"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="S. Raza" initials="S." surname="Raza"/> 272.xml"/>
<date month="April" year="2022"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<abstract> 652.xml"/>
<t>Enrollment over Secure Transport (EST) is used as a certificate provisi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
oning protocol over HTTPS. Low-resource devices often use the lightweight Constr 929.xml"/>
ained Application Protocol (CoAP) for message exchanges. This document defines h <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
ow to transport EST payloads over secure CoAP (EST-coaps), which allows constrai 955.xml"/>
ned devices to use existing EST functionality for provisioning certificates.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</abstract> 030.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="RFC" value="9148"/> 366.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC9148"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 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="RFC9480"> <reference anchor="IEC-62351-9" target="https://webstore.iec.ch/en/publi
<front> cation/66864">
<title>Certificate Management Protocol (CMP) Updates</title> <front>
<author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/> <title>Power systems management and associated information exchange
<author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/> - Data and communications security - Part 9: Cyber security key management for p
<author fullname="J. Gray" initials="J." surname="Gray"/> ower system equipment</title>
<date month="November" year="2023"/> <author>
<abstract> <organization>International Electrotechnical Commission</organizat
<t>This document contains a set of updates to the syntax of Certificate Ma ion>
nagement Protocol (CMP) version 2 and its HTTP transfer mechanism. This document </author>
updates RFCs 4210, 5912, and 6712.</t> <date year="2023" month="June"/>
<t>The aspects of CMP updated in this document are using EnvelopedData ins </front>
tead of EncryptedValue, clarifying the handling of p10cr messages, improving the <seriesInfo name="IEC" value="62351-9:2023"/>
crypto agility, as well as adding new general message types, extended key usage </reference>
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="NERC-CIP-005-5" target="">
<front> <front>
<title>Constrained Application Protocol (CoAP) Transfer for the Certificate <title>Cyber Security - Electronic Security Perimeter</title>
Management Protocol</title> <author>
<author fullname="M. Sahni" initials="M." role="editor" surname="Sahni"/> <organization>North American Electric Reliability Council</organiz
<author fullname="S. Tripathi" initials="S." role="editor" surname="Tripathi ation>
"/> </author>
<date month="November" year="2023"/> <date year="2013" month="December"/>
<abstract> </front>
<t>This document specifies the use of the Constrained Application Protocol <seriesInfo name="CIP" value="005-5"/>
(CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). C </reference>
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" > <reference anchor="ISO-IEC-15118-2" target="https://www.iso.org/standard
<front> /55366.html">
<title>IEC 62351 - Power systems management and associated information excha <front>
nge - Data and communications security - Part 9: Cyber security key management f <title>Road vehicles - Vehicle-to-Grid Communication Interface - Par
or power system equipment</title> t 2: Network and application protocol requirements</title>
<author > <author>
<organization>International Electrotechnical Commission</organization> <organization>International Organization for Standardization</orga
</author> nization>
<date year="2017" month="May"/> </author>
</front> <date year="2014" month="April"/>
<seriesInfo name="IEC" value="62351-9 "/> </front>
</reference> <seriesInfo name="ISO" value="15118-2:2014"/>
<reference anchor="NERC-CIP-005-5" > </reference>
<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> system/files/2023-01/sos3_index083_-_subset-137_v100.pdf">
<title>Discovery for BRSKI variations</title> <front>
<author fullname="Toerless Eckert" initials="T. T." surname="Eckert"> <title>ERTMS/ETCS On-line Key Management FFFIS</title>
<organization>Futurewei USA</organization> <author>
</author> <organization>UNISIG</organization>
<author fullname="Esko Dijk" initials="E." surname="Dijk"> </author>
<organization>IoTconsultancy.nl</organization> <date year="2015" month="December"/>
</author> </front>
<date day="25" month="July" year="2024"/> <refcontent>Subset-137, Version 1.0.0</refcontent>
<abstract> </reference>
<t> This document specifies how BRSKI entities, such as registrars,
proxies, pledges or others that are acting as responders, can be
discovered and selected by BRSKI entities acting 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?> <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 <section anchor="rolling-stock">
ts <name>Rolling Stock</name>
PKI services to issue certificates for Intelligent Electronic Devices operated <t>Rolling stock or railroad cars contain a variety of sensors,
in a substation. Communication between the substation and control center actuators, and controllers. These communicate within the railroad car
is performed through a proxy/gateway/DMZ, which terminates protocol flows. but also exchange information with other railroad cars of the same train
Note that <xref target="NERC-CIP-005-5"/> requires inspection of protocols and
at the boundary of a security perimeter (the substation in this case). with track-side equipment and/or possibly with backend systems.
In addition, security management in substation automation assumes These devices are typically unaware of backend system connectivity.
central support of several enrollment protocols to support Enrolling certificates may be done during maintenance cycles of the
the various capabilities of IEDs from different vendors. railroad car but can already be prepared during operation. Such
The IEC standard IEC62351-9 <xref target="IEC-62351-9"/> asynchronous enrollment will include generating certification
specifies for the infrastructure side mandatory support of requests, which are collected and later forwarded for processing
two enrollment protocols: SCEP <xref target="RFC8894"/> and EST <xref target="RF whenever the railroad car gets connectivity with the backend PKI of
C7030"/>, the operator. The authorization of the certification request is then
while an Intelligent Electronic Device may support only one of them.</t> 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>
</section> <section anchor="building-automation">
<section anchor="electric-vehicle-charging-infrastructure"><name>Electric Vehicl <name>Building Automation</name>
e Charging Infrastructure</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>
<t>For electric vehicle charging infrastructure, protocols have been <section anchor="substation-automation">
defined for the interaction between the electric vehicle and the <name>Substation Automation</name>
charging point (e.g., ISO 15118-2 <xref target="ISO-IEC-15118-2"/>) <t>In electrical substation automation scenarios, a control center
as well as between the charging point and the charging point operator typically hosts PKI services to issue certificates for Intelligent
(e.g. OCPP <xref target="OCPP"/>). Depending on the authentication Electronic Devices (IEDs) operated in a substation. Communication
model, unilateral or mutual authentication is required. In both cases, between the substation and control center is performed through a
the charging point uses an X.509 certificate to authenticate itself proxy/gateway/DMZ, which terminates protocol flows. Note that
in TLS channels between the electric vehicle and <xref target="NERC-CIP-005-5"/> requires inspection of protocols at
the charging point. The management of this certificate depends, the boundary of a security perimeter (in this case, the substation).
among others, on the selected backend connectivity protocol. In addition, security management in substation automation assumes
In the case of OCPP, this protocol is meant to be the only communication central support of several enrollment protocols to support the various
protocol between the charging point and the backend, carrying all capabilities of IEDs from different vendors. The IEC standard
information to control the charging operations and maintain the IEC62351-9 <xref target="IEC-62351-9"/> specifies mandatory support of
charging point itself. This means that the certificate management two enrollment protocols for the infrastructure side, SCEP <xref
needs to be handled in-band of OCPP. This requires the ability to target="RFC8894"/> and EST <xref target="RFC7030"/>, while an
encapsulate the certificate management messages in a transport-independent way. IED may support only one of them.</t>
Authenticated self-containment will support this by </section>
allowing the transport without a separate enrollment protocol,
binding the messages to the identity of the communicating endpoints.</t>
</section> <section anchor="electric-vehicle-charging-infrastructure">
<section anchor="infrastructure-isolation"><name>Infrastructure Isolation Policy <name>Electric Vehicle Charging Infrastructure</name>
</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>
<t>This refers to any case in which network infrastructure is normally <section anchor="infrastructure-isolation">
isolated from the Internet as a matter of policy, most likely for <name>Infrastructure Isolation Policy</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 approach described in this section refers to any case in which
<section anchor="sites-with-insufficient-level-of-operational-security"><name>Si network infrastructure is normally isolated from the Internet as a
tes with Insufficient Level of Operational Security</name> matter of policy, most likely for security reasons. In such a case,
limited access to external PKI services will be allowed in carefully
controlled short periods of time (for example, when a batch of new
devices is deployed) and forbidden or prevented at other times.</t>
</section>
<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>
<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">
<t>Toerless Eckert (document shepherd)</t>
<t>Barry Leiba (SECdir)</t>
<t>Mahesh Jethanandani (IETF area director)</t>
<t>Meral Shirazipour (Gen-ART reviewer)</t>
<t>Deb Cooley, Gunter Van de Velde, John Scudder, Murray Kucherawy, Roman Dany
liw,
and Éric Vyncke (IESG reviewers)</t>
<t>Michael Richardson (ANIMA design team)</t>
<t>Rajeev Ranjan, Rufus Buschart, Szofia Fazekas-Zisch, etc. (Siemens)</t>
<t>Reshad Rahman (YANGDOCTORS reviewer). Note that
<eref target="https://datatracker.ietf.org/doc/review-ietf-anima-brski-async-enr
oll-03-yangdoctors-early-rahman-2021-08-15/">YANGDOCTORS Early review of 2021-08
-15</eref>
referred to the PRM aspect of <eref target="https://datatracker.ietf.org/doc/dra
ft-ietf-anima-brski-async-enroll/03/">draft-ietf-anima-brski-async-enroll-03</er
ef>.
This has been carved out of the draft to a different one and thus is no more
applicable here.</t>
</list></t>
<t>IETF draft ae-12 -&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>
<t><list style="symbols">
<t>Extend section on discovery according to discussion in the design team</t>
<t>Make explicit that MASA voucher status telemetry is as in BRSKI</t>
<t>Add note that on delegation, RA may need info on pledge authorization</t>
</list></t>
<t>IETF draft ae-04 -&gt; ae-05:</t>
<t><list style="symbols">
<t>Remove entries from the terminology section that should be clear from BRSKI
</t>
<t>Tweak use of the terms IDevID and LDevID and replace PKI RA/CA by RA/CA</t>
<t>Add the abbreviation 'LCMPP' for Lightweight CMP Profile to the terminology
section</t>
<t>State clearly in <xref target="brski-cmp-instance"/> that LCMPP is 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>
<t><list style="symbols">
<t>In response to SECDIR Early Review of ae-03 by Barry Leiba,
<list style="symbols">
<t>replace 'end-to-end security' by the more clear 'end-to-end 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>
<t><list style="symbols">
<t>In response to review by Toerless Eckert,
<list style="symbols">
<t>many editorial improvements and clarifications as suggested, such as
the comparison to plain BRSKI, the description of offline vs. synchronous
message transfer and enrollment, and better differentiation of RA flavors.</t>
<t>clarify that for transporting certificate enrollment messages between
pledge and registrar, the TLS channel established between these two
(via the join proxy) is used and the enrollment protocol <bcp14>MUST</bcp14> 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>
<t><list style="symbols">
<t>Architecture: clarify registrar role including RA/LRA/enrollment proxy</t>
<t>CMP: add reference to CoAP Transport for CMPV2 and Constrained BRSKI</t>
<t>Include venue information</t>
</list></t>
<t>From IETF draft 05 -&gt; IETF draft ae-01:</t>
<t><list style="symbols">
<t>Renamed the repo and files from 'anima-brski-async-enroll' to 'anima-brski-
ae'</t>
<t>Added graphics for abstract protocol overview as suggested by Toerless 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>
<t><list style="symbols">
<t>David von Oheimb became the editor.</t>
<t>Streamline wording, consolidate terminology, improve grammar, etc.</t>
<t>Shift the emphasis towards supporting alternative enrollment protocols.</t>
<t>Update the title accordingly - preliminary change to be approved.</t>
<t>Move comments on EST and detailed application examples to informative annex
.</t>
<t>Move the remaining text of section 3 as two new sub-sections of section 1.<
/t>
</list></t>
<t>From IETF draft 03 -&gt; IETF draft 04:</t>
<t><list style="symbols">
<t>Moved UC2-related parts defining the pledge in responder mode to a
separate document. This required changes and adaptations in several
sections. Main changes concerned the removal of the subsection for UC2
as well as the removal of the YANG model related text as it is not
applicable in UC1.</t>
<t>Updated references to the Lightweight CMP Profile (LCMPP).</t>
<t>Added David von Oheimb as co-author.</t>
</list></t>
<t>From IETF draft 02 -&gt; IETF draft 03:</t>
<t><list style="symbols">
<t>Housekeeping, deleted open issue regarding YANG voucher-request
in UC2 as voucher-request was enhanced with additional leaf.</t>
<t>Included open issues in YANG model in UC2 regarding assertion
value agent-proximity and CSR encapsulation using SZTP sub module).</t>
</list></t>
<t>From IETF draft 01 -&gt; IETF draft 02:</t>
<t><list style="symbols">
<t>Defined call flow and objects for interactions in UC2. Object format
based on draft for JOSE signed voucher artifacts and aligned the
remaining objects with this approach in UC2 .</t>
<t>Terminology change: issue #2 pledge-agent -&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>
<t><list style="symbols"> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f
<t>Update of scope in <xref target="sup-env"/> to include in alse">
which the pledge acts as a server. This is one main motivation <name>Contributors</name>
for use case 2.</t> <contact initials="E." surname="Lear" fullname="Eliot Lear">
<t>Rework of use case 2 to consider the <organization>Cisco Systems</organization>
transport between the pledge and the pledge-agent. Addressed is <address>
the TLS channel establishment between the pledge-agent and the <postal>
pledge as well as the endpoint definition on the pledge.</t> <street>Richtistrasse 7</street>
<t>First description of exchanged object types (needs more work)</t> <city>Wallisellen</city>
<t>Clarification in discovery options for enrollment endpoints at <code>8304</code>
the domain registrar based on well-known endpoints in <xref target="addressing"/ <country>Switzerland</country>
> </postal>
do not result in additional /.well-known URIs. <phone>+41 44 878 9200</phone>
Update of the illustrative example. <email>lear@cisco.com</email>
Note that the change to /brski for the voucher-related endpoints </address>
has been taken over in the BRSKI main document.</t> </contact>
<t>Updated references.</t> </section>
<t>Included Thomas Werner as additional author for the document.</t> </back>
</list></t>
<t>From individual version 03 -&gt; IETF draft 00:</t>
<t><list style="symbols">
<t>Inclusion of discovery options of enrollment endpoints at
the domain registrar based on well-known endpoints in
<xref target="addressing"/> as replacement of section 5.1.3
in the individual draft. This is intended to support both use
cases in the document. An illustrative example is provided.</t>
<t>Missing details provided for the description and call flow in
pledge-agent use case UC2, e.g. to
accommodate distribution of CA certificates.</t>
<t>Updated CMP example in <xref target="exist_prot"/> to use
Lightweight CMP instead of CMP, as the draft already provides
the necessary /.well-known endpoints.</t>
<t>Requirements discussion moved to separate section in
<xref target="req-sol"/>. Shortened description of proof-of-identity binding
and mapping to existing protocols.</t>
<t>Removal of copied call flows for voucher exchange and registrar
discovery flow from <xref target="RFC8995"/> in <xref target="uc1"/> to avoid 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>
<t><list style="symbols">
<t>Update of terminology from self-contained to authenticated
self-contained object to be consistent in the wording and to
underline the protection of the object with an existing
credential. Note that the naming of this object may be discussed.
An alternative name may be attestation object.</t>
<t>Simplification of the architecture approach for the initial use
case having an off-site PKI.</t>
<t>Introduction of a new use case utilizing authenticated
self-contain objects to onboard a pledge using a commissioning
tool containing a pledge-agent. This requires additional changes
in the BRSKI call flow sequence and led to changes in the
introduction, the application example,and also in the
related BRSKI-AE call flow.</t>
<t>Update of provided examples of the addressing approach used in
BRSKI to allow for support of multiple enrollment protocols in
<xref target="addressing"/>.</t>
</list></t>
<t>From individual version 01 -&gt; 02:</t>
<t><list style="symbols"> <!-- [rfced] Formatting and XML:
<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> c.) We note the following different uses regarding this document's use of <tt>
styling and quotation marks. In the HTML and PDF outputs, the text enclosed in
<tt> is output in fixed-width font. In the txt output, there are no changes to
the font. Please review carefully and let us know if any updates should be made
for consistency:
<t><list style="symbols"> the <tt>caPubs</tt> field
<t>Update of examples, specifically for building automation as the acp-node-name field (no quotes or <tt> styling)
well as two new application use cases in <xref target="app-examples"/>.</t>
<t>Deletion of asynchronous interaction with MASA to not
complicate the use case. Note that the voucher exchange can
already be handled in an asynchronous manner and is therefore
not considered further. This resulted in removal of the
alternative path the MASA in Figure 1 and the associated
description in <xref target="architecture"/>.</t>
<t>Enhancement of description of architecture elements and
changes to BRSKI in <xref target="architecture"/>.</t>
<t>Consideration of existing enrollment protocols in the context
of mapping the requirements to existing solutions in <xref target="req-sol"/>.</
t>
<t>New section starting <xref target="exist_prot"/> with the
mapping to existing enrollment protocols by collecting
boundary conditions.</t>
</list></t>
<!--
Local IspellDict: american
LocalWords: bcp uc prot vexchange enrollfigure req eo selander coap br iana tcp
LocalWords: oscore fullcmc simpleenroll tls env brski UC seriesinfo IDevID Resp
LocalWords: Attrib lt docname ipr toc anima async wg symrefs ann ae pkcs cert
LocalWords: sortrefs iprnotified Instantiation caPubs raVerified repo reqs Conf
LocalWords: IDentity IDentifier coaps aasvg acp cms json pkixcmp kp DOI abbrev
LocalWords: PoP PoI anufacturer uthorized igning uthority SECDIR nbsp passphrase
LocalWords: ietf cmp lcmpp submissionType kw std org uri cmpv app sol est Certs
LocalWords: github eckert lternative nrollment sec certs reg priv pledge's CMP's
LocalWords: Mahesh Jethanandani Gen ART Meral Shirazipour Deb Cooley's
LocalWords: Gunter Van de Velde's Scudder's Kucherawy's Danyliw's Eacute Vyncke'
s
--> -->
</section> <!-- [rfced] Abbreviations:
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse">
<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> 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?
<!-- ##markdown-source: Public-Key Infrastructure
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=
--> -->
</rfc> </rfc>
 End of changes. 156 change blocks. 
3210 lines changed or deleted 1780 lines changed or added

This html diff was produced by rfcdiff 1.48.