rfc8951xml2.original.xml   rfc8951.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-rfc2629 version 1.3.8 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->
<?rfc sortrefs="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-lamps-rfc7030est-clarify-10" category ="std" updates="7030"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-lamps-rfc7030est-clarify-10" number="8951" updates="7030" obsoletes="" sub missionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="tru e" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.47.0 -->
<front> <front>
<title abbrev="rfc7030est">Clarification of Enrollment over Secure Transport <title abbrev="Clarification of EST">Clarification of Enrollment over
(EST): transfer encodings and ASN.1</title> Secure Transport (EST): Transfer Encodings and ASN.1</title>
<seriesInfo name="RFC" value="8951"/>
<author initials="M." surname="Richardson" fullname="Michael Richardson"> <author initials="M." surname="Richardson" fullname="Michael Richardson">
<organization>Sandelman Software Works</organization> <organization>Sandelman Software Works</organization>
<address> <address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
</address> </address>
</author> </author>
<author initials="T." surname="Werner" fullname="Thomas Werner"> <author initials="T." surname="Werner" fullname="Thomas Werner">
<organization>Siemens</organization> <organization>Siemens</organization>
<address> <address>
<email>thomas-werner@siemens.com</email> <email>thomas-werner@siemens.com</email>
</address> </address>
</author> </author>
<author initials="W." surname="Pan" fullname="Wei Pan"> <author initials="W." surname="Pan" fullname="Wei Pan">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<email>william.panwei@huawei.com</email> <email>william.panwei@huawei.com</email>
</address> </address>
</author> </author>
<date month="November" year="2020"/>
<date year="2020" month="August" day="11"/>
<area>Internet</area> <area>Internet</area>
<workgroup>LAMPS Working Group</workgroup> <workgroup>LAMPS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document updates RFC 7030: Enrollment over Secure Transport
<t>This document updates RFC7030: Enrollment over Secure Transport (EST) to reso to resolve some errata that were reported and that have proven to
lve cause interoperability issues when RFC 7030 was extended.</t>
some errata that were reported, and which have proven to cause interoperability <t>This document deprecates the specification of
issues when RFC7030 was extended.</t> "Content-Transfer-Encoding" headers for Enrollment over Secure Transport
(EST) endpoints. This document
<t>This document deprecates the specification of “Content-Transfer-Encoding” fixes some syntactical errors in ASN.1 that were present.</t>
headers for EST endpoints.
This document fixes some syntactical errors in ASN.1 that were present.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>Enrollment over Secure Transport (EST) is defined in <xref
target="RFC7030" format="default"/>. The EST specification defines a
number of HTTP endpoints for certificate enrollment and management. The
details of the transaction were defined in terms of MIME headers, as
defined in <xref target="RFC2045" format="default"/>, rather than in
terms of the HTTP protocol, as defined in <xref target="RFC7230"
format="default"/> and <xref target="RFC7231" format="default"/>.</t>
<t><xref target="RFC2616" format="default"/> and later <xref
target="RFC7231" sectionFormat="of" section="A.5"/> have text
specifically deprecating Content-Transfer-Encoding. However, <xref
target="RFC7030" format="default"/> incorrectly uses this header.</t>
<section anchor="introduction" title="Introduction"> <t>Any updates to <xref target="RFC7030" format="default"/> to bring it
in line with HTTP processing risk changing the on-wire protocol in a way
<t>Enrollment over Secure Transport (EST) is defined in <xref target="RFC7030"/> that is not backwards compatible. However, reports from implementers
. suggest that many implementations do not send the
The EST specification defines a number of HTTP end points for certificate enroll Content-Transfer-Encoding, and many of them ignore it. The consequence
ment and management. is that simply deprecating the header would remain compatible with
The details of the transaction were defined in terms of MIME headers as defined current implementations.</t>
in <xref target="RFC2045"/>, <t><xref target="I-D.ietf-anima-bootstrapping-keyinfra"
rather than in terms of the HTTP protocol as defined in <xref target="RFC7230"/> format="default"/> extends <xref target="RFC7030" format="default"/>,
and <xref target="RFC7231"/>.</t> adding new functionality. Interop testing of the protocol has
revealed that unusual processing called out in <xref target="RFC7030"
<t><xref target="RFC2616"/> and later <xref target="RFC7231"/> Appendix A.5 has format="default"/> causes confusion.</t>
text specifically <t>EST is currently specified as part of <xref target="IEC62351"
deprecating Content-Transfer-Encoding. format="default"/> and is widely used in government, utilities, and
However, <xref target="RFC7030"/> incorrectly uses this header.</t> financial markets today.</t>
<t>This document, therefore, revises <xref target="RFC7030"
<t>Any updates to <xref target="RFC7030"/> to bring it inline with HTTP processi format="default"/> to reflect the field reality, deprecating the
ng risk extraneous field.</t>
changing the on-wire protocol in a way that is not backwards compatible. <t>This document deals with errata numbers <xref target="errata4384"
However, reports from implementers suggest that many implementations do not send format="default"/>, <xref target="errata5107" format="default"/>, <xref
the target="errata5108" format="default"/>, and <xref target="errata5904"
Content-Transfer-Encoding, and many of them ignore it. format="default"/>.</t>
The consequence is that simply deprecating the header would remain compatible wi <t>This document deals with <xref target="errata5107" format="default"/>
th current implementations.</t> and <xref target="errata5904" format="default"/> in <xref
target="estendpoint" format="default"/>. <xref target="errata5108"
<t><xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> extends <xref target=" format="default"/> is dealt with in <xref target="error"
RFC7030"/>, adding new format="default"/>. <xref target="errata4384" format="default"/> is
functionality, and interop testing of the protocol has revealed that unusual pro closed by correcting the ASN.1 Module in <xref target="csrasn1"
cessing format="default"/>.</t>
called out in <xref target="RFC7030"/> causes confusion.</t> </section>
<section anchor="terminology" numbered="true" toc="default">
<t>EST is currently specified as part of <xref target="IEC62351"/>, and is widel <name>Terminology</name>
y used in Government, <t>
Utilities and Financial markets today.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t>This document therefore revises <xref target="RFC7030"/> to reflect the field NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
reality, deprecating "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
the extraneous field.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
<t>This document deals with errata numbers <xref target="errata4384"/>, <xref ta described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
rget="errata5107"/>, <xref target="errata5108"/>, when, and only when, they appear in all capitals, as shown here.
and <xref target="errata5904"/>.</t> </t>
</section>
<t>This document deals with <xref target="errata5107"></xref> and <xref target=" <section anchor="estendpoint" numbered="true" toc="default">
errata5904"></xref> in <name>Changes to EST Endpoint Processing</name>
Section 3. <xref target="errata5108"></xref> is dealt with in Section 5. <xref <t>Sections <xref target="RFC7030" sectionFormat="bare"
target="errata4384"></xref> is section="4.1.3"/> (CA Certificates Response, /cacerts), <xref
closed by correcting the ASN.1 Module in Section 4.</t> target="RFC7030" sectionFormat="bare" section="4.3.1"/> and <xref
target="RFC7030" sectionFormat="bare" section="4.3.2"/> (Full CMC,
</section> /fullcmc), <xref target="RFC7030" sectionFormat="bare" section="4.4.2"/>
<section anchor="terminology" title="Terminology"> (Server-Side Key Generation, /serverkeygen), and <xref target="RFC7030"
sectionFormat="bare" section="4.5.2"/> (CSR Attributes, /csrattrs) of
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL <xref target="RFC7030" format="default"/>
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, specify the use of base64 encoding with a Content-Transfer-Encoding for
“MAY”, and “OPTIONAL” in this document are to be interpreted as requests and responses.</t>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and <t>This document updates <xref target="RFC7030" format="default"/> to
only when, they require the POST request and payload response of all endpoints using
appear in all capitals, as shown here.</t> base64 encoding, as specified in <xref target="RFC4648"
sectionFormat="of" section="4"/>. In both cases, the Distinguished
</section> Encoding Rules (DER) <xref target="X.690" format="default"/> are used to
<section anchor="estendpoint" title="Changes to EST endpoint processing"> produce the input for the base64 encoding routine. This format is to
be used regardless of any Content-Transfer-Encoding header, and any
<t>The <xref target="RFC7030"/> sections 4.1.3 (CA Certificates Response, /cacer value in such a header <bcp14>MUST</bcp14> be ignored.</t>
ts), <section anchor="whitespace-processing" numbered="true" toc="default">
4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, /serverkeyg <name>White Space Processing</name>
en), <t>Note that "base64" as used in the HTTP <xref target="RFC2616"
and 4.5.2 (CSR Attributes, /csrattrs) specify the use of base64 encoding with a format="default"/> does not permit CRLF, while the "base64" used in
Content-Transfer-Encoding for requests and response.</t> MIME <xref target="RFC2045" format="default"/> does. This
specification clarifies that despite what <xref target="RFC2616"
<t>This document updates <xref target="RFC7030"/> to require the POST request an format="default"/> says, white space including CR, LF, spaces (ASCII
d payload response of all endpoints use Base64 encoding as specified in Section 32), and tabs (ASCII 9) <bcp14>SHOULD</bcp14> be tolerated by
4 of <xref target="RFC4648"/>. receivers. Senders are not required to insert any kind of white space.</t
In both cases, the Distinguished Encoding Rules (DER) <xref target="X.690"/> are >
used to produce the input for the Base64 encoding routine. </section>
This format is to be used regardless of any Content-Transfer-Encoding header, an <section anchor="changes-sections-4-of-rfc7030" numbered="true" toc="defau
d any value in such a header MUST be ignored.</t> lt">
<name>Changes to Section 4 of RFC 7030</name>
<section anchor="whitespace-processing" title="Whitespace processing"> <section anchor="sect-413" numbered="true" toc="default">
<name>Section 4.1.3</name>
<t>Note that “base64” as used in the HTTP <xref target="RFC2616"/> does not perm <t>Replace:</t>
it CRLF, while the “base64” used in MIME <xref target="RFC2045"/> does.
This specification clarifies that despite <xref target="RFC2616"/>, that white s
pace including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) SHOULD be tolerated
by receivers.
Senders are not required to insert any kind of white space.</t>
</section>
<section anchor="changes-sections-4-of-rfc7030" title="Changes sections 4 of RFC
7030">
<section anchor="section-413" title="Section 4.1.3">
<t>Replace:</t>
<figure><artwork><![CDATA[ <blockquote>
A successful response MUST be a certs-only CMC Simple PKI Response, A successful response <bcp14>MUST</bcp14> be a certs-only CMC Simple PKI Respons
as defined in [RFC5272], containing the certificates described in the e,
as defined in <xref target="RFC5272" format="default"/>, containing the certific
ates described in the
following paragraph. The HTTP content-type of following paragraph. The HTTP content-type of
"application/pkcs7-mime" is used. The Simple PKI Response is sent "application/pkcs7-mime" is used. The Simple PKI Response is sent
with a Content-Transfer-Encoding of "base64" [RFC2045]. with a Content-Transfer-Encoding of "base64" <xref target="RFC2045"
]]></artwork></figure> format="default"/>.
</blockquote>
<t>with: (RFCEDITOR: maybe artwork is the wrong choice here)</t> <t>with:</t>
<blockquote>
<figure><artwork><![CDATA[ A successful response <bcp14>MUST</bcp14> be a certs-only CMC Simple PKI Respons
A successful response MUST be a certs-only CMC Simple PKI Response, e,
as defined in [RFC5272], containing the certificates described in the as defined in <xref target="RFC5272" format="default"/>, containing the certific
ates described in the
following paragraph. The HTTP content-type of following paragraph. The HTTP content-type of
"application/pkcs7-mime" is used. The CMC Simple PKI Response is "application/pkcs7-mime" is used. The CMC Simple PKI Response is
encoded in base64 [RFC4648]. encoded in base64 <xref target="RFC4648" format="default"/>.
]]></artwork></figure> </blockquote>
</section>
</section> <section anchor="sect-431" numbered="true" toc="default">
<section anchor="section-431" title="Section 4.3.1"> <name>Section 4.3.1</name>
<t>Replace:</t>
<t>Replace:</t>
<figure><artwork><![CDATA[ <blockquote>
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
server MUST reject the message. The HTTP content-type used is server <bcp14>MUST</bcp14> reject the message. The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request", "application/pkcs7-mime" with an smime-type parameter "CMC-request",
as specified in [RFC5273]. The body of the message is the binary as specified in <xref target="RFC5273" format="default"/>. The body of the mess age is the binary
value of the encoding of the PKI Request with a value of the encoding of the PKI Request with a
Content-Transfer-Encoding of "base64" [RFC2045]. Content-Transfer-Encoding of "base64" <xref target="RFC2045" format="default"/>.
]]></artwork></figure> </blockquote>
<t>with:</t>
<t>with:</t> <blockquote>
<figure><artwork><![CDATA[
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
server MUST reject the message. The HTTP content-type used is server <bcp14>MUST</bcp14> reject the message. The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request", "application/pkcs7-mime" with an smime-type parameter "CMC-request",
as specified in [RFC5273]. The body of the message is encoded as specified in <xref target="RFC5273" format="default"/>. The body of the mess
in base64 [RFC4648]. age is encoded
]]></artwork></figure> in base64 <xref target="RFC4648" format="default"/>.
</blockquote>
</section> </section>
<section anchor="section-432" title="Section 4.3.2"> <section anchor="sect-432" numbered="true" toc="default">
<name>Section 4.3.2</name>
<t>Replace:</t> <t>Replace:</t>
<blockquote>
<figure><artwork><![CDATA[
The body of the message is the binary value of the encoding of the The body of the message is the binary value of the encoding of the
PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045]. PKI Response with a Content-Transfer-Encoding of "base64" <xref
]]></artwork></figure> target="RFC2045" format="default"/>.
</blockquote>
<t>with:</t> <t>with:</t>
<blockquote>
<figure><artwork><![CDATA[ The body of the message is the base64 <xref target="RFC4648" format="default"/>
The body of the message is the base64 [RFC4648] encoding of the encoding of the
PKI Response. PKI Response.
]]></artwork></figure> </blockquote>
</section>
</section> <section anchor="sect-442" numbered="true" toc="default">
<section anchor="section-442" title="Section 4.4.2"> <name>Section 4.4.2</name>
<t>Replace:</t>
<t>Replace:</t> <blockquote>
<figure><artwork><![CDATA[
An "application/pkcs8" An "application/pkcs8"
part consists of the base64-encoded DER-encoded [X.690] part consists of the base64-encoded DER-encoded <xref target="X.690" format="def ault"/>
PrivateKeyInfo with a Content-Transfer-Encoding of "base64" PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
[RFC4648]. <xref target="RFC2045" format="default"/>.
]]></artwork></figure> </blockquote>
<t>with:</t>
<t>with:</t> <blockquote>
An "application/pkcs8" part consists of the base64-encoded,
<figure><artwork><![CDATA[ DER-encoded <xref target="X.690" format="default"/> PrivateKeyInfo.
An "application/pkcs8" part consists of the base64-encoded </blockquote>
DER-encoded [X.690] PrivateKeyInfo. <t>Replace:</t>
]]></artwork></figure> <blockquote>
<t>Replace:</t>
<figure><artwork><![CDATA[
In all three additional encryption cases, the EnvelopedData is In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part with an returned in the response as an "application/pkcs7-mime" part with an
smime-type parameter of "server-generated-key" and a Content- smime-type parameter of "server-generated-key" and a Content-
Transfer-Encoding of "base64". Transfer-Encoding of "base64".
]]></artwork></figure> </blockquote>
<t>with:</t>
<t>with:</t> <blockquote>
<figure><artwork><![CDATA[
In all three additional encryption cases, the EnvelopedData is In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part returned in the response as an "application/pkcs7-mime" part
with an smime-type parameter of "server-generated-key". It is with an smime-type parameter of "server-generated-key". It is
base64 encoded [RFC4648]. base64 encoded <xref target="RFC4648" format="default"/>.
]]></artwork></figure> </blockquote>
</section>
</section> <section anchor="sect-452" numbered="true" toc="default">
<section anchor="section-452" title="Section 4.5.2"> <name>Section 4.5.2</name>
<t>This section is updated in its entirety in <xref target="csrasn1" f
<t>This section is updated in its entirety in <xref target="csrasn1"/>.</t> ormat="default"/>.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="csrasn1" numbered="true" toc="default">
<section anchor="csrasn1" title="Clarification of ASN.1 for Certificate Attribut <name>Clarification of ASN.1 for Certificate Attribute Set</name>
e set."> <t><xref target="RFC7030" sectionFormat="of" section="4.5.2"/> is to be
replaced with the following text:</t>
<t>Section 4.5.2 of <xref target="RFC7030"/> is to be replaced with the followin <blockquote>
g text:</t> <t>4.5.2 CSR Attributes Response</t>
<t>If locally configured policy for an authenticated EST client indicates
<t>4.5.2 CSR Attributes Response</t> a CSR Attributes Response is to be provided, the server response <bcp14>MUST</bc
p14>
<t>If locally configured policy for an authenticated EST client indicates
a CSR Attributes Response is to be provided, the server response MUST
include an HTTP 200 response code. An HTTP response code of 204 or 404 include an HTTP 200 response code. An HTTP response code of 204 or 404
indicates that a CSR Attributes Response is not available. Regardless indicates that a CSR Attributes Response is not available. Regardless
of the response code, the EST server and CA MAY reject any subsequent of the response code, the EST server and CA <bcp14>MAY</bcp14> reject any subseq uent
enrollment requests for any reason, e.g., incomplete CSR attributes in enrollment requests for any reason, e.g., incomplete CSR attributes in
the request.</t> the request.</t>
<t>Responses to attribute request messages <bcp14>MUST</bcp14> be encoded
<t>Responses to attribute request messages MUST be encoded as the as the
content-type of “application/csrattrs”, and are to be “base64” <xref target="RFC content-type of "application/csrattrs" and are to be "base64" <xref target="RFC4
4648"/> 648" format="default"/>
encoded. The syntax for application/csrattrs body is as follows:</t> encoded. The syntax for application/csrattrs body is as follows:</t>
<figure><artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE { AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} } attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { ... } AttrSet ATTRIBUTE ::= { ... }
]]></artwork></figure> ]]></sourcecode>
<t>An EST server includes zero or more OIDs or attributes <xref
<t>An EST server includes zero or more OIDs or attributes <xref target="RFC2986" target="RFC2986" format="default"/> that it requests the client to use
/> that in the certification request. The client <bcp14>MUST</bcp14> ignore any
it requests the client to use in the certification request. The client OID or attribute it does not recognize. When the server encodes CSR
MUST ignore any OID or attribute it does not recognize. When the attributes as an empty SEQUENCE, it means that the server has no
server encodes CSR Attributes as an empty SEQUENCE, it means that the specific additional information it desires in a client certification
server has no specific additional information it desires in a client request (this is functionally equivalent to an HTTP response code of 204
certification request (this is functionally equivalent to an HTTP or 404).</t>
response code of 204 or 404).</t> <t>If the CA requires a particular cryptographic algorithm or use of a par
ticular
<t>If the CA requires a particular cryptographic algorithm or use of a particula
r
signature scheme (e.g., certification of a public key based on a signature scheme (e.g., certification of a public key based on a
certain elliptic curve, or signing using a certain hash algorithm) it certain elliptic curve or signing using a certain hash algorithm), it
MUST provide that information in the CSR Attribute Response. If an <bcp14>MUST</bcp14> provide that information in the CSR Attribute Response. If
an
EST server requires the linking of identity and POP information (see EST server requires the linking of identity and POP information (see
Section 3.5), it MUST include the challengePassword OID in the CSR Section 3.5), it <bcp14>MUST</bcp14> include the challengePassword OID in the CS R
Attributes Response.</t> Attributes Response.</t>
<t>The structure of the CSR Attributes Response <bcp14>SHOULD</bcp14>, to
<t>The structure of the CSR Attributes Response SHOULD, to the greatest the greatest
extent possible, reflect the structure of the CSR it is requesting. extent possible, reflect the structure of the CSR it is requesting.
Requests to use a particular signature scheme (e.g. using a Requests to use a particular signature scheme (e.g., using a
particular hash function) are represented as an OID to be reflected particular hash function) are represented as an OID to be reflected
in the SignatureAlgorithm of the CSR. Requests to use a particular in the SignatureAlgorithm of the CSR. Requests to use a particular
cryptographic algorithm (e.g., certification of a public key based on a certain cryptographic algorithm (e.g., certification of a public key based on a certain
elliptic curve) are represented as an attribute, to be reflected as elliptic curve) are represented as an attribute, to be reflected as
the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
indicating the algorithm and the values indicating the particular indicating the algorithm and the values indicating the particular
parameters specific to the algorithm. Requests for descriptive parameters specific to the algorithm. Requests for descriptive
information from the client are made by an attribute, to be information from the client are made by an attribute, to be
represented as Attributes of the CSR, with a type indicating the represented as Attributes of the CSR, with a type indicating the
<xref target="RFC2985"/> extensionRequest and the values indicating the particul <xref target="RFC2985" format="default"/> extensionRequest and the values indica
ar ting the particular
attributes desired to be included in the resulting certificate’s attributes desired to be included in the resulting certificate's
extensions.</t> extensions.</t>
<t>The sequence is Distinguished Encoding Rules (DER) encoded <xref
target="X.690" format="default"/> and then base64 encoded (<xref
target="RFC4648" sectionFormat="of" section="4"/>). The resulting text
forms the application/csrattr body, without headers.</t>
<t>The sequence is Distinguished Encoding Rules (DER) encoded <xref target="X.69 <t>For example, if a CA requests that a client a) submit a certification
0"/> request containing the challengePassword (indicating that linking of
and then base64 encoded (Section 4 of <xref target="RFC4648"/>). The resulting identity and POP information is requested; see Section <xref target="RFC7030"
text section="3.5" sectionFormat="bare"/>), b) submit an
forms the application/csrattr body, without headers.</t> extensionRequest with the Media Access Control (MAC) address
<xref target="RFC2307" format="default"/> of the client, and c) use the secp3
<t>For example, if a CA requests a client to submit a certification 84r1 elliptic curve
request containing the challengePassword (indicating that linking of to sign using the SHA384 hash function, then it takes the
identity and POP information is requested; see Section 3.5), an following: </t>
extensionRequest with the Media Access Control (MAC) address
(<xref target="RFC2307"/>) of the client, and to use the secp384r1 elliptic curv
e
and to sign with the SHA384 hash function. Then, it takes the
following:</t>
<figure><artwork><![CDATA[ <artwork>
OID: challengePassword (1.2.840.113549.1.9.7) OID: challengePassword (1.2.840.113549.1.9.7)
Attribute: type = extensionRequest (1.2.840.113549.1.9.14) Attribute: type = extensionRequest (1.2.840.113549.1.9.14)
value = macAddress (1.3.6.1.1.1.1.22) value = macAddress (1.3.6.1.1.1.1.22)
Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) Attribute: type = id-ecPublicKey (1.2.840.10045.2.1)
value = secp384r1 (1.3.132.0.34) value = secp384r1 (1.3.132.0.34)
OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)
]]></artwork></figure> </artwork>
<t>and encodes them into an ASN.1 SEQUENCE to produce:</t>
<figure><artwork><![CDATA[
30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
03
]]></artwork></figure>
<t>and then base64 encodes the resulting ASN.1 SEQUENCE to produce:</t>
<figure><artwork><![CDATA[
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
BgcrBgEBAQEWBggqhkjOPQQDAw==
]]></artwork></figure>
</section>
<section anchor="error" title="Clarification of error messages for certificate e
nrollment operations">
<t><xref target="errata5108"/> clarifies what format the error messages are to b
e in.
Previously a client might be confused into believing that an error returned
with type text/plain was not intended to be an error.</t>
<section anchor="updating-section-423-simple-enroll-and-re-enroll-response" titl
e="Updating section 4.2.3: Simple Enroll and Re-enroll Response">
<t>Replace:</t>
<figure><artwork><![CDATA[ <t>and encodes them into an ASN.1 SEQUENCE to produce:</t>
If the content-type is not set, the response data MUST be a <artwork>
30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
03
</artwork>
<t>and then base64 encodes the resulting ASN.1 SEQUENCE to produce:</t>
<artwork>
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
BgcrBgEBAQEWBggqhkjOPQQDAw==
</artwork>
</blockquote>
</section>
<section anchor="error" numbered="true" toc="default">
<name>Clarification of Error Messages for Certificate Enrollment Operation
s</name>
<t><xref target="errata5108" format="default"/> clarifies what format
the error messages are to be in. Previously, a client might be confused
into believing that an error returned with type text/plain was not
intended to be an error.</t>
<section
anchor="updating-section-423-simple-enroll-and-re-enroll-response"
numbered="true" toc="default">
<name>Updating Section 4.2.3: Simple Enroll and Re-enroll Response</name
>
<t>Replace:</t>
<blockquote>
If the content-type is not set, the response data <bcp14>MUST</bcp14> be a
plaintext human-readable error message containing explanatory plaintext human-readable error message containing explanatory
information describing why the request was rejected (for information describing why the request was rejected (for
example, indicating that CSR attributes are incomplete). example, indicating that CSR attributes are incomplete).
]]></artwork></figure> </blockquote>
<t>with:</t>
<t>with:</t> <blockquote>
If the content-type is not set, the response data <bcp14>MUST</bcp14> be a
<figure><artwork><![CDATA[
If the content-type is not set, the response data MUST be a
plaintext human-readable error message containing explanatory plaintext human-readable error message containing explanatory
information describing why the request was rejected (for information describing why the request was rejected (for
example, indicating that CSR attributes are incomplete). example, indicating that CSR attributes are incomplete).
Servers MAY use the "text/plain” content-type [RFC2046] Servers <bcp14>MAY</bcp14> use the "text/plain" content-type <xref target="R FC2046"/>
for human-readable errors. for human-readable errors.
]]></artwork></figure> </blockquote>
</section>
</section> <section anchor="updating-section-442-server-side-key-generation-response"
<section anchor="updating-section-442-server-side-key-generation-response" title numbered="true" toc="default">
="Updating section 4.4.2: Server-Side Key Generation Response"> <name>Updating Section 4.4.2: Server-Side Key Generation Response</name>
<t>Replace:</t>
<t>Replace:</t> <blockquote>
If the content-type is not set, the response data <bcp14>MUST</bcp14> be a
<figure><artwork><![CDATA[
If the content-type is not set, the response data MUST be a
plaintext human-readable error message. plaintext human-readable error message.
]]></artwork></figure> </blockquote>
<t>with:</t>
<t>with:</t> <blockquote>
If the content-type is not set, the response data <bcp14>MUST</bcp14> be a
<figure><artwork><![CDATA[
If the content-type is not set, the response data MUST be a
plaintext human-readable error message. plaintext human-readable error message.
Servers MAY use the "text/plain” content-type [RFC2046] Servers <bcp14>MAY</bcp14> use the "text/plain" content-type <xref
target="RFC2046" format="default"/>
for human-readable errors. for human-readable errors.
]]></artwork></figure> </blockquote>
</section>
</section> </section>
</section> <section anchor="privacy-considerations" numbered="true" toc="default">
<section anchor="privacy-considerations" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>This document does not disclose any additional identities that either
<t>This document does not disclose any additional identities to either active or an active or passive observer would see with <xref target="RFC7030"
passive observer would see with <xref target="RFC7030"/>.</t> format="default"/>.</t>
</section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security Considerations"> <name>Security Considerations</name>
<t>This document clarifies an existing security mechanism.
<t>This document clarifies an existing security mechanism. It does not create any new protocol mechanisms.</t>
It does not create any new protocol mechanism.</t> <t>All security considerations from <xref target="RFC7030" format="default
"/> also apply to the clarifications described in this document.</t>
<t>All security considerations from <xref target="RFC7030"/> also apply for the </section>
clarifications described in this document.</t> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>The ASN.1 module in Appendix A of this document makes use of object
identifiers (OIDs). This document requests that IANA register an
OID in the SMI Security for PKIX Arc in the Module identifiers
subarc (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the
Asymmetric Decryption Key Identifier (1.2.840.113549.1.9.16.2.54)
was previously defined in <xref target="RFC7030"/>.</t>
<t>IANA is requested to update the “Reference” column for the Asymmetric
Decryption Key Identifier
attribute to also include a reference to this document.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This work was supported by Huawei Technologies.</t>
<t>The ASN.1 Module was assembled by Russ Housley and formatted by Sean Turner.
Russ Housley provided editorial review.</t>
</section>
<t>The ASN.1 module in <xref target="asn1-module" format="default"/> of
this document makes use of object identifiers (OIDs).</t>
<t>IANA has registered an OID for id-mod-est-2019 (1.3.6.1.5.5.7.0.98)
in the "SMI Security for PKIX Module Identifier" registry for the ASN.1 mo
dule.</t>
<t>The OID for the Asymmetric Decryption Key Identifier (1.2.840.113549.1.
9.16.2.54)
was previously defined in <xref target="RFC7030" format="default"/>.
IANA has updated the Reference column for the Asymmetric
Decryption Key Identifier attribute to also include a reference to this do
cument.</t>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="I-D.ietf-anima-bootstrapping-keyinfra" to="BRSKI"/>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, 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="RFC2045" target='https://www.rfc-editor.org/info/rfc2045'>
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></auth
or>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'><organizatio
n /></author>
<date year='1996' month='November' />
<abstract><t>This initial document specifies the various headers used to describ
e the structure of MIME messages. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2045'/>
<seriesInfo name='DOI' value='10.17487/RFC2045'/>
</reference>
<reference anchor="RFC2986" target='https://www.rfc-editor.org/info/rfc2986'>
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'><organization /></
author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></
author>
<date year='2000' month='November' />
<abstract><t>This memo represents a republication of PKCS #10 v1.7 from RSA Labo
ratories' Public-Key Cryptography Standards (PKCS) series, and change control is
retained within the PKCS process. The body of this document, except for the se
curity considerations section, is taken directly from the PKCS #9 v2.0 or the PK
CS #10 v1.7 document. This memo provides information for the Internet community
.</t></abstract>
</front>
<seriesInfo name='RFC' value='2986'/>
<seriesInfo name='DOI' value='10.17487/RFC2986'/>
</reference>
<reference anchor="RFC4648" target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization
/></author>
<date year='2006' month='October' />
<abstract><t>This document describes the commonly used base 64, base 32, and bas
e 16 encoding schemes. It also discusses the use of line-feeds in encoded data,
use of padding in encoded data, use of non-alphabet characters in encoded data,
use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK
]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>
<reference anchor="RFC6268" target='https://www.rfc-editor.org/info/rfc6268'>
<front>
<title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) a
nd the Public Key Infrastructure Using X.509 (PKIX)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au
thor>
<author initials='S.' surname='Turner' fullname='S. Turner'><organization /></au
thor>
<date year='2011' month='July' />
<abstract><t>The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1. The current ASN.1 modules conform to the 19
88 version of ASN.1. This document updates some auxiliary ASN.1 modules to conf
orm to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative ve
rsion. There are no bits- on-the-wire changes to any of the formats; this is si
mply a change to the syntax. This document is not an Internet Standards Track
specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6268'/>
<seriesInfo name='DOI' value='10.17487/RFC6268'/>
</reference>
<reference anchor="RFC7030" target='https://www.rfc-editor.org/info/rfc7030'>
<front>
<title>Enrollment over Secure Transport</title>
<author initials='M.' surname='Pritikin' fullname='M. Pritikin' role='editor'><o
rganization /></author>
<author initials='P.' surname='Yee' fullname='P. Yee' role='editor'><organizatio
n /></author>
<author initials='D.' surname='Harkins' fullname='D. Harkins' role='editor'><org
anization /></author>
<date year='2013' month='October' />
<abstract><t>This document profiles certificate enrollment for clients using Cer
tificate Management over CMS (CMC) messages over a secure transport. This profi
le, called Enrollment over Secure Transport (EST), describes a simple, yet funct
ional, certificate management protocol targeting Public Key Infrastructure (PKI)
clients that need to acquire client certificates and associated Certification A
uthority (CA) certificates. It also supports client-generated public/private ke
y pairs as well as key pairs generated by the CA.</t></abstract>
</front>
<seriesInfo name='RFC' value='7030'/>
<seriesInfo name='DOI' value='10.17487/RFC7030'/>
</reference>
<reference anchor="X.680" >
<front>
<title>Information technology - Abstract Syntax Notation One.</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="8824-1:2002"/>
</reference>
<reference anchor="X.681" >
<front>
<title>Information technology - Abstract Syntax Notation One: Information Ob
ject Specification.</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="8824-2:2002"/>
</reference>
<reference anchor="X.682" >
<front>
<title>Information technology - Abstract Syntax Notation One: Constraint Spe
cification.</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="8824-2:2002"/>
</reference>
<reference anchor="X.683" >
<front>
<title>Information technology - Abstract Syntax Notation One: Parameterizati
on of ASN.1 Specifications.</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="8824-2:2002"/>
</reference>
<reference anchor="X.690" >
<front>
<title>Information technology - ASN.1 encoding Rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
Rules (DER).</title>
<author >
<organization>ITU-T</organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="8825-1:2002"/>
</reference>
<reference anchor="IEC62351" >
<front>
<title>Power systems management and associated information exchange - Data a
nd communications security - Part 9: Cyber security key management for power sys
tem equipment</title>
<author >
<organization>International Electrotechnical Commission</organization>
</author>
<date year="2017"/>
</front>
<seriesInfo name="ISO/IEC" value="62351-9:2017"/>
</reference>
<reference anchor="errata4384" target="https://www.rfc-editor.org/errata/eid4384
">
<front>
<title>EST errata 4384: ASN.1 encoding error</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="errata5107" target="https://www.rfc-editor.org/errata/eid5107
">
<front>
<title>EST errata 5107: use Content-Transfer-Encoding</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="errata5108" target="https://www.rfc-editor.org/errata/eid5108
">
<front>
<title>EST errata 5108: use of Content-Type for error message</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="errata5904" target="https://www.rfc-editor.org/errata/eid5904
">
<front>
<title>EST errata 5904: use Content-Transfer-Encoding</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="RFC5272" target='https://www.rfc-editor.org/info/rfc5272'>
<front>
<title>Certificate Management over CMS (CMC)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au
thor>
<author initials='M.' surname='Myers' fullname='M. Myers'><organization /></auth
or>
<date year='2008' month='June' />
<abstract><t>This document defines the base syntax for CMC, a Certificate Manage
ment protocol using the Cryptographic Message Syntax (CMS). This protocol addres
ses two immediate needs within the Internet Public Key Infrastructure (PKI) comm
unity:</t><t>1. The need for an interface to public key certification products
and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</
t><t>2. 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 d
ocument and the requirements usage document along with this document for a full
definition. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5272'/>
<seriesInfo name='DOI' value='10.17487/RFC5272'/>
</reference>
<reference anchor="RFC5273" target='https://www.rfc-editor.org/info/rfc5273'>
<front>
<title>Certificate Management over CMS (CMC): Transport Protocols</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au
thor>
<author initials='M.' surname='Myers' fullname='M. Myers'><organization /></auth
or>
<date year='2008' month='June' />
<abstract><t>This document defines a number of transport mechanisms that are use
d to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) m
essages. The transport mechanisms described in this document are HTTP, file, ma
il, and TCP. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5273'/>
<seriesInfo name='DOI' value='10.17487/RFC5273'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC5912" target='https://www.rfc-editor.org/info/rfc5912'>
<front>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</t
itle>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></
author>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au
thor>
<date year='2010' month='June' />
<abstract><t>The Public Key Infrastructure using X.509 (PKIX) certificate format
, and many associated formats, are expressed using ASN.1. The current ASN.1 mod
ules conform to the 1988 version of ASN.1. This document updates those ASN.1 mo
dules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire cha
nges to any of the formats; this is simply a change to the syntax. This documen
t is not an Internet Standards Track specification; it is published for informa
tional purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5912'/>
<seriesInfo name='DOI' value='10.17487/RFC5912'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="I-D.ietf-anima-bootstrapping-keyinfra">
<front>
<title>Bootstrapping Remote Secure Key Infrastructures (BRSKI)</title>
<author initials='M' surname='Pritikin' fullname='Max Pritikin'>
<organization />
</author>
<author initials='M' surname='Richardson' fullname='Michael Richardson'> <references>
<organization /> <name>References</name>
</author> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2045.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2986.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4648.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6268.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7030.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2046.xml"/>
<author initials='T' surname='Eckert' fullname='Toerless Eckert'> <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680-20
<organization /> 1508-I/en">
</author> <front>
<title>Information technology -- Abstract Syntax Notation One
(ASN.1): Specification of basic notation</title>
<seriesInfo name="ITU-T Recommendation X.680," value="ISO/IEC 8824-1
:2015"/>
<author>
<organization>ITU-T</organization>
</author>
<date month="August" year="2015"/>
</front>
</reference>
<author initials='M' surname='Behringer' fullname='Michael Behringer'> <reference anchor="X.681" target="https://www.itu.int/rec/T-REC-X.681">
<organization /> <front>
</author> <title>Information Technology - Abstract Syntax Notation One (ASN.1)
: Information object specification</title>
<seriesInfo name="ITU-T Recommendation X.681," value="ISO/IEC 8824-2
:2015"/>
<author>
<organization>ITU-T</organization>
</author>
<date month="August" year="2015"/>
</front>
</reference>
<author initials='K' surname='Watsen' fullname='Kent Watsen'> <reference anchor="X.682" target="https://www.itu.int/rec/T-REC-X.682">
<organization /> <front>
</author> <title>Information Technology - Abstract Syntax Notation One (ASN.1)
: Constraint specification</title>
<seriesInfo name="ITU-T Recommendation X.682," value="ISO/IEC 8824-3
:2015"/>
<author>
<organization>ITU-T</organization>
</author>
<date month ="August" year="2015"/>
</front>
</reference>
<date month='August' day='7' year='2020' /> <reference anchor="X.683" target="https://www.itu.int/rec/T-REC-X.683">
<front>
<title>Information Technology - Abstract Syntax Notation One (ASN.1)
: Parameterization of ASN.1 specifications</title>
<seriesInfo name="ITU-T Recommendation X.683," value="ISO/IEC 8824-4
:2015"/>
<author>
<organization>ITU-T</organization>
</author>
<date month="August" year="2015"/>
</front>
</reference>
<abstract><t>This document specifies automated bootstrapping of an Autonomic Con <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
trol Plane. To do this a Secure Key Infrastructure is bootstrapped. This is do <front>
ne using manufacturer-installed X.509 certificates, in combination with a manufa <title>Information Technology - ASN.1 encoding rules: Specification
cturer's authorizing service, both online and offline. We call this process the of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping Encoding Rules (DER)</title>
a new device can occur using a routable address and a cloud service, or using on <seriesInfo name="ITU-T Recommendation X.690," value="ISO/IEC 8825-1
ly link-local connectivity, or on limited/ disconnected networks. Support for d :2015"/>
eployment models with less stringent security requirements is included. Bootstr <author>
apping is complete when the cryptographic identity of the new key infrastructure <organization>ITU-T</organization>
is successfully deployed to the device. The established secure connection can </author>
be used to deploy a locally issued certificate to the device as well.</t></abstr <date month="August" year="2015"/>
act> </front>
</reference>
</front> <reference anchor="IEC62351">
<front>
<title>Power systems management and associated information exchange
- Data and communications security - Part 9: Cyber security key management for p
ower system equipment</title>
<seriesInfo name="ISO/IEC" value="62351-9:2017"/>
<author>
<organization>International Electrotechnical Commission</organizat
ion>
</author>
<date month="May" year="2017"/>
</front>
</reference>
<seriesInfo name='Internet-Draft' value='draft-ietf-anima-bootstrapping-keyinfra <reference anchor="errata4384" quote-title="false"
-43' /> target="https://www.rfc-editor.org/errata/eid4384">
<format type='TXT' <front>
target='http://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrappi <title>Erratum ID 4384</title>
ng-keyinfra-43.txt' /> <author>
</reference> <organization>RFC Errata</organization>
</author>
</front>
<refcontent>RFC 7030</refcontent>
</reference>
<reference anchor="RFC2616" target='https://www.rfc-editor.org/info/rfc2616'> <reference anchor="errata5107" quote-title="false"
<front> target="https://www.rfc-editor.org/errata/eid5107">
<title>Hypertext Transfer Protocol -- HTTP/1.1</title> <front>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /> <title>Erratum ID 5107</title>
</author> <author>
<author initials='J.' surname='Gettys' fullname='J. Gettys'><organization /></au <organization>RFC Errata</organization>
thor> </author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></auth </front>
or> <refcontent>RFC 7030</refcontent>
<author initials='H.' surname='Frystyk' fullname='H. Frystyk'><organization /></ </reference>
author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization />
</author>
<author initials='P.' surname='Leach' fullname='P. Leach'><organization /></auth
or>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organizat
ion /></author>
<date year='1999' month='June' />
<abstract><t>HTTP has been in use by the World-Wide Web global information initi
ative since 1990. This specification defines the protocol referred to as &quot;H
TTP/1.1&quot;, and is an update to RFC 2068. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2616'/>
<seriesInfo name='DOI' value='10.17487/RFC2616'/>
</reference>
<reference anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'> <reference anchor="errata5108" quote-title="false"
<front> target="https://www.rfc-editor.org/errata/eid5108">
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title <front>
> <title>Erratum ID 5108</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><o <author>
rganization /></author> <organization>RFC Errata</organization>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><org </author>
anization /></author> </front>
<date year='2014' month='June' /> <refcontent>RFC 7030</refcontent>
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-l </reference>
evel protocol for distributed, collaborative, hypertext information systems. Th
is document provides an overview of HTTP architecture and its associated termino
logy, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identi
fier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements
, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>
<reference anchor="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'> <reference anchor="errata5904" quote-title="false"
<front> target="https://www.rfc-editor.org/errata/eid5904">
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title> <front>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><o <title>Erratum ID 5904</title>
rganization /></author> <author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><org <organization>RFC Errata</organization>
anization /></author> </author>
<date year='2014' month='June' /> </front>
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application <refcontent>RFC 7030</refcontent>
- level protocol for distributed, collaborative, hypertext information systems. </reference>
This document defines the semantics of HTTP/1.1 messages, as expressed by reque <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
st methods, request header fields, response status codes, and response header fi ence.RFC.5272.xml"/>
elds, along with the payload of messages (metadata and body content) and mechani <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
sms for content negotiation.</t></abstract> ence.RFC.5273.xml"/>
</front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<seriesInfo name='RFC' value='7231'/> ence.RFC.8174.xml"/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</reference> ence.RFC.5912.xml"/>
</references>
<reference anchor="RFC2985" target='https://www.rfc-editor.org/info/rfc2985'> <references>
<front> <name>Informative References</name>
<title>PKCS #9: Selected Object Classes and Attribute Types Version 2.0</title>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'><organization /></
author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></
author>
<date year='2000' month='November' />
<abstract><t>This memo represents a republication of PKCS #9 v2.0 from RSA Labor
atories' Public-Key Cryptography Standards (PKCS) series, and change control is
retained within the PKCS process. The body of this document, except for the sec
urity considerations section, is taken directly from that specification. This m
emo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2985'/>
<seriesInfo name='DOI' value='10.17487/RFC2985'/>
</reference>
<reference anchor="RFC2307" target='https://www.rfc-editor.org/info/rfc2307'> <!-- [I-D.ietf-anima-bootstrapping-keyinfra-44] in EDIT state as of 11/17/20-->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<title>An Approach for Using LDAP as a Network Information Service</title> .ietf-anima-bootstrapping-keyinfra.xml"/>
<author initials='L.' surname='Howard' fullname='L. Howard'><organization /></au
thor>
<date year='1998' month='March' />
<abstract><t>This document describes an experimental mechanism for mapping entit
ies related to TCP/IP and the UNIX system into X.500 entries so that they may be
resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo d
efines an Experimental Protocol for the Internet community. It does not specify
an Internet standard of any kind. Discussion and suggestions for improvement ar
e requested.</t></abstract>
</front>
<seriesInfo name='RFC' value='2307'/>
<seriesInfo name='DOI' value='10.17487/RFC2307'/>
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2616.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7230.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7231.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2985.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2307.xml"/>
</references>
</references> </references>
<section anchor="asn1-module" numbered="true" toc="default">
<name>ASN.1 Module</name>
<t>This annex provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
<xref target="X.680" format="default"/>, <xref target="X.681"
format="default"/>, <xref target="X.682" format="default"/>, and <xref
target="X.683" format="default"/>.</t>
<t>The ASN.1 modules makes imports from the ASN.1 modules in <xref
target="RFC5912" format="default"/> and <xref target="RFC6268"
format="default"/>.</t>
<t>There is no ASN.1 Module in <xref target="RFC7030"
format="default"/>. This module has been created by combining the lines
that are contained in the document body.</t>
<section anchor="asn1-module" title="ASN.1 Module"> <sourcecode type="asn.1"><![CDATA[
<t>This annex provides the normative ASN.1 definitions for the structures
described in this specification using ASN.1 as defined in <xref target="X.680"/>
,
<xref target="X.681"/>, <xref target="X.682"/> and <xref target="X.683"/>.</t>
<t>The ASN.1 modules makes imports from the ASN.1 modules in
<xref target="RFC5912"/> and <xref target="RFC6268"/>.</t>
<t>There is no ASN.1 Module in RFC 7030. This module has been created
by combining the lines that are contained in the document body.</t>
<figure><artwork><![CDATA[
PKIXEST-2019 PKIXEST-2019
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7)
id-mod-est-2019(TBD) } id-mod(0) id-mod-est-2019(98) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
Attribute Attribute
FROM CryptographicMessageSyntax-2010 -- [RFC6268] FROM CryptographicMessageSyntax-2010 -- [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) } id-mod-cms-2009(58) }
ATTRIBUTE ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- [RFC5912] FROM PKIX-CommonTypes-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) { iso(1) identified-organization(3) dod(6) internet(1)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- CSR Attributes -- CSR Attributes
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE { AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} } attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { ... } AttrSet ATTRIBUTE ::= { ... }
-- Asymmetric Decrypt Key Identifier Attribute -- Asymmetric Decrypt Key Identifier Attribute
aa-asymmDecryptKeyID ATTRIBUTE ::= aa-asymmDecryptKeyID ATTRIBUTE ::=
{ TYPE AsymmetricDecryptKeyIdentifier { TYPE AsymmetricDecryptKeyIdentifier
IDENTIFIED BY id-aa-asymmDecryptKeyID } IDENTIFIED BY id-aa-asymmDecryptKeyID }
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 54 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) aa(2) 54 }
AsymmetricDecryptKeyIdentifier ::= OCTET STRING AsymmetricDecryptKeyIdentifier ::= OCTET STRING
END END
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Huawei Technologies supported the efforts of <contact fullname="Wei Pan
"/> and <contact fullname="Michael Richardson"/>.</t>
<t>The ASN.1 Module was assembled by <contact fullname="Russ Housley"/>
and formatted by <contact fullname="Sean Turner"/>. <contact
fullname="Russ Housley"/> provided editorial review.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAJraMl8AA+1b+W4bR5r/v56iRv5jSazY5qWLg2BDUbTNxJRkkYaTNYxF
sbtEdtTsZrqaohnDi32RBfZZ9lH2SfY7qvqgKEUZeGYWmFWCpMmu4zt/31HF
RqMhsjCLdE8eDCKVhrehr7IwiWVyK4dxmkTRUseZTO51KifaX6daTlMVm1WS
ZrI2nEzrPZnhF7cwQMd+EoTx3EgVB7I/ufRaB0LNZqm+78n01j9pdpraZCJI
/FgtYc8gVbdZI9TZbSNSy5VpFIMaPpGzbbSaQpgMFvw3FSWxxu3WWohwldKj
ydrN5lmzLVSqVU+O4kynsc7EZt6Tb/vj64n8kKR3QJR8nSbrlbjbFIMaF7i/
AI570mSBWK8ClWnTk0iDEKuwJ+HvhfRVLNdGS5Wmaitr4a1UUSS32tRlksqF
Mgu50KkWUmaJ38MX8GhAQqm+NT1aItC3ah1lBka499slv8aPQq2zRZL2hGjI
MIYvx568Cf2FSgOTxDCa5TXGr3RUfZWkwOoEBKSjJRA6SW6zDQiD+MaN9FKF
UU8u/fSfUdLfGzfU81W+39STH1Amab7XdJEslSm+5W1CDfZQWjWjUY0Njfre
8GvPT5b5yh88ea0KFj7o0H6mBd+s1Qa+mWp/ESdRMg91afFNGEWhWnorFcOg
7xc0lhePk3QJhnqvezD85tWg3Wqducdm98g9np0e28fucffUPh63j90jKhof
f/KOT+kBVGjdYRTf8h7gDJkjbysbsj8zYPF+JifbOFOf5WWS8airWHsHtAaa
UU+CYbbpo1OupD/iezR935jSF0anwHQIu7kBo8nVy9FwADScnra7jVYPFzqw
VLa+AZXoAcW0q9kvGsettJ+7/1+Dj3aFj/Y34WOQxPg6jP/m9He+Cf3XKgWv
ADQKf8thl3Czyo75q/Nz9mzrJ+oc0subdYSAWaEWmThXJvQhgpSHydr58KZ+
KAcqTmIYGz14P4D3FDsuQpPB9+vQLHTwYNgFDPu2EgGBHFlHg1fw1XG7c7Tj
atcJoBzAtsn00kjATzXXFByRYGVM4odATCDDkuj0ZwDqeK5BcBcqUzQU8Gu5
jp1mgSqIqmGGsgVryOQZWPV2hju5F3d6W94OVperEi1S/7oOV/iqKpLWyaMi
ofhH+6MSInD/NCEtk1YGQGBoTEjR5UmxkZQaZz27mYb4mKlu57RblRykCfad
pJe7RgTvkpSJz1Q61xCOF1m2Mr2XLzebjQdJQUMHYZakHpD/kld6qcMAFxP5
vket5smj+9JLCuIAGRnIqjG1WUvDWddfQACuWiHg9CkCTpkA8I6chu1Kkz5J
AnKpjQEt/2WEnJYIOWs+rgF6+e0lAatySD1qn7R7+SPApMgdgqP1qHHhUcqn
4nCpGrMkyRAiVyvYuQG2DsNT5QL4ccsF8JM2h2p+bGGq1GhIZeFViOkiNBIy
yzU5iU3l8hj/zGQW07NUmyS618IkS+2Eli1UJsHlNLzF0To4JF/eLCATgwzw
XstVCuvGuICvULohOlmy0qmahRG4sQCXWgNFmwWMsmTJDWRY+jNoIdCBt8tD
oFep9omNbKGl2cXYgycUuNAq0Kkh4yLlx8EqAZKMt7PJbfgZ1ideDUYoPyMM
IIM0wIT11UIAQJOBiR7LfxkGQQTp+AsElTQJ1j5SJ8QzxY2U6NswJtiUX75Y
uXz9imRqorzKNo+GAkPG6yWiJMjhzXR6jQxK5pB49nWa8SzQYUEL6qyAUt4k
0BlkmwZXQjFTNaOIDWa4RCBodEkDx6PxUDoZq4dMYA769euhAOOBygClF1fm
40ZENlgN1AxJtG8RtPivX4lm97mFkhG8BbiGfRsBl2l5jOyvViCQ8LPse0dY
oMDOn7NClFG0Fc66EIAfNSRPvIFIAwo8LCsHKPSTFGZn0RaRBO0TNMnyAPr6
8TZ3QPCH8kz4OEtxyzCDVSLgF7L8bJELwwcIxNdpaO4ExU78hOJK4sYmJPuz
EgMxKXCgLdsm7B8nmZwp/26DpRGG2RVwN4t0iQn2XjCRNFnKcLmKyA5QiWY9
n0PZyYuBiWyL1zZQBwntYNDSgCDxqNAOnZltraphqzkULIAJ1uR8WA+iNgRA
jYTTngb328qyWpBtFqrcJOsoAPKhMIpLrLHwwLVStO4dislSnoW2oBhGIVNW
FvARUHyO9UbcrmOfEwbAMubQIhzYFiVrzq5zBaHdQemvVaQD5nEdr80a0KVQ
tEBjhNfJOttBAIZR1GN8u8ZkBNhBPAB5WX5BWtaiNSZgcoXpExABTNsEjnhA
SgF2Qyh6yVrJwV4jKsUoq0PxPkOADjW3LV6FsYohlYtAg+mdppI9UNsH6IyO
rW8TCgn3IVK6Y+fwFjMrkgmQSOqz0ispWeBrED4YkU7WhkfuCQUqMqxsG5EY
/nDTIutCdt1nTE12Pp8iIjGaFHkCAcqjm30sFvtE0vlYzPwEchSA64SUHa80
9vQTA7uKMl4GBO4GHnnSjUSScaTwowTVMttKCyvO+Dn2jCGsRLq8SNfDiDMF
NA25MBHkVpgobxJ0/oPx+8n04JD/Ly+v6Plm+O796GZ4gc+TN/23b/MHYUdM
3ly9f3tRPBUzB1fj8fDygifDt7LylTgY938+YFs7uLqejq4u+28PCPErksW2
DCKgzQ7ACDIyXQBj46fhjG3zfHD93//V6oKa/mQ7G2BQ/OG0dQIaoxyCd0ti
MGr+CALbCnBsrVLCxigCF1qFGSjzEN3DLJJNTI0qkB6Ib0CVCSF0OUMoo/CX
F+Da7sVXFnLZyg3rw4BCWl4H6re+HBSBF7IvDcEeoO5QvvQVhmRTPxRdr+O1
XuJ/27L2ag1kDsYDGHELj/7ShwKx63Xx3USn4KSNCXiu/BFU+1rHkE3hhjDa
0EvQ+FzHdTbrrneE0waTG9nPMhDnGmjArQ3MylJTt3CxJduyqfhMGX3cLWoR
slf1OLhTdpEieJuMASO1TD7wIxcCH+AC1GtoCEDE9RVI3q5Gi63UNkpUsSiS
iJrM8zei+3yHaNRujoRlP2E4tO0vdPVRLGcJhgxYwZDNPKPWhiWoRYDpRqoZ
Q4GRFeV7zEgYr9ZcmuInSx/85SSmgPAQ7W36yQUBxT5yB1oy1XOI3LArpUgY
Ph/XAodF9gEcea+iNUGEWUNCrlzYJPdHd6P4i7j64oX8sAhBLSswyHIgEpdQ
AnOYOmCjOEC5uoCRZ2zl5CtINKcdK4SiTA5u3r46xKIgYqnkC7lVKG8sZYi0
gpVJNdHl9neobXYAAAGurMu7H9qkHLmRzA7kZdGa5DO4OZRIC30PauxPBqOR
7LSpvQIzoW5yX57VpUW7GaJThD7GaAxQrKFoS4HCCZYomOuC/pFha8RkByHY
aZqRGu5CxKTbMlEscwc2BWLgMOsXOOJFCdwBS4S40asIpkOd9+/wJ/qoWdQV
wEThHU6/ihJ+0yA4BDiRE8qF5PWPowKERDXH/miL1U+HmGNADRC7sOOXMawC
zZj33UIxkWxwLCQcag651AJi2tTZh29tNsPaPrkVBwDJkdXqy9Wdb04ay3Cp
D9D40Szs3D0E4wgstQRj0hPegMWgM7WP1rg+eSw4mt2TNfh6eDGaXt30ILHZ
oszSDILlHSegkEmmCazkL5LQ1xQl6v8gkn+EaExMCL14fxsnPloszaVbtVyI
bA8sd1Qq9wjvwWVcsHNli0IACyH5xHDIVFBMIIQWHOtY5Kn+xSWVtl30qAgY
dMzjcmC7AszEjzxn5RrS8gDk0rCh6YA0WAkxVoedT3b7WRK4cscR5ixrBhl1
uhUM0XaILpkuBcKC598Pwb9v7v8veiOt8Yo/YLztB8b7LNXKp1QrKk71DaDs
mZTtsPwkWfvl0d0jj34sH+j09EBQ6YlVfYhZoaWISWg4EIFMKn/+SPnUJ3Gd
hveAdZDd4oHLH5KOeKDNsnT20ymfQafYQ6es0uk23AU6LjqyRao1tQ7sAQMs
lm5XnNUUaecwvtdRstIBHYyAr0AxtE7jItvKQ43CPPshO86ViCfrT2KvP6HU
2JEbc64hdIC9jwNOH3N5iycFvhdg/n4siych5FGWPTnCvFuU6x5U9K4x7TrD
EToD56n2O4yiVOEQ+WGGiJNBTphtuZODZZeJuWMJCeDu7RKu7bFiKJWMReEG
22QeFKBuFSEqtOSFjetIukoiZZsM2CKo95JnDdgEBc3xAtUyMYcCgUEjSqhH
Sr2ncL7GPHeVgCa2RC/IHA/VkFuf2Mfy2Y9CasHFAWcvQj22Q0ErHhlAcRuw
ddhQU8mwBGf0GvekKNNuNosRqDqIAX37rvI9CgiwEy+odJtdkdPFRcOTxFFU
vFdhpLB5KuGdq8uERYzKTta2sVXPHKBTDfpy3P/ZhUwsDcx6xj3PTJQa8nkl
zYLFmkMZLPC1N/cOqdGMmRnYAxKsCoLDWDAlNN9DMGKaSLj5wLy4tuHB5Imr
s3xF8ULsJI9V33MdBNviKdo4eaji9gxX2S5ttOHZ8ME/MbhnTQ5iIR0jsKka
RhcxMGmfRvR638nJ8N374eVgKCejfx3KWtPzxv2f6vLqFWnxKr0aXQiRP9KU
wZurEUz4gndtIMGxf1fnPwwHUzm6GF5OR69Gw5tDeF/Iq+SBX77g80Rn4F9f
eXH4IPvT6c3o/P10SJt8kZ7nwWsCDbDEkh1Y2zXyN50maIhL7JYCdQY/lHRp
G11np1hTo32KsGQZVBewd4HQ+Whtp1hAWHCWwELnCYKUbZvvaF0omvLeeAyR
F/FQ7ibzOPwNbf4DntKVEkBWqdl1G8ZpvVwB6DkNHeKiSw2RhH2ttAp2xOMk
r/TLEaN8ayCkeh+g1PAhh2VmL7+yRi1G7KnkHXpALizPISuzQrPoIZ5AiLon
XLoMvmvLezxnw1gT+muAb0kxLaG6C4mP5kkKILvEFWw3rTxcGBC8yvDYz/gL
vdSyxk5d5YNnrWfgGNTARY/CviZUADgQzzt0FIUQTH1s/N8D3sB+uDZC+pr6
lFyE4lC6jJdTVgdRsg1YqLVnRWVZsy1V9FrkhVKOsBMlSladiwanRWF8Z9ME
WB0CAtgBIsT11XVll5rRutQrP6qTkbB1WoQni17gaUg819fKGOxkk8EWJIo9
iO1xW9Zk6donYVuMfgzguddziGaBw+YAuHiAI+gAKIM4ZwyeLB1Wzi/2rh5S
A8/aIR0W3uQ+y45asZ795uA0KEojSYnOnOsEt6m2586M2GDQKBkX8olQLnUy
6qXYnfqFieZkU0B7nEzxmJH/QeN1FimqxvsYNzkiHe4yhccDdBbiKBmRoUEx
mDquJmu6wndNdNgc/dAVExjQXPh3bZaCK8WHmVzBGbkzriSWPLUsGpXOhPLV
yqLFcMcNnBVe/BBlb6DT1xKso0iWCnxgtt0nC7EjrpJVF2qt8LvDh/jy5V84
wBy5k048ULwp9d2fJYNSyGJ8DvLTHPLhch6/jmiFUkPrn4zItzbOa0unwM/o
w7ucJe/HC0t7LHfy+drOEUCRndRthCxoxLRYoHYY0/YkKZSjsITxoNZefAAe
XuHdpc8KUzRANHQGGzz4dKQUtyH9ww65qjqQcFFstw/4AAhrFbUAiBfQK56E
3gKidPBnELiWVRwGdH9gEXntMNZBqGSf2p9UJkLiKmvj/qCOsTvFlLhmjauD
5611Z5HMOKeLFmU4x/dXndNu2tqJacKOQ4wsdp+86cPgKhyy9mKKH5m64zhU
dEZt6mhTvdFFz6V9eyTa8treabfptVqdo+6Z1/LOvJO6sHNzJ4MVyKW+e+g4
+1ZodetCPvjjBtF34OV+n+WGkzveMczhf9rtp7YOg4b2c3wrbdxsdqGY81pP
bVoInfZsddpe0+t08/3KYtJ+YNQHUICV/c5O2CTr1DnZRZW5tJAvecScatkL
vC5hL07KSsrpNGW3JZvHsnkm20qeHsvuKf739kQ2A9ls4ffNExzWatOwk2IY
wEUnoFWabRzaaeFrHHQk2zN5Ch+7EurEdpvmHz+xDa8CW2la5cxtNaOHVvGv
XeV0hwraqcOrdAqxPEQks4OLz5HReDh8PZj8+noymnUu3g1/OP+tPzmf+78u
7n65un43Oh+/81+fT9bn5/1+OD7/uTL24pfhD7QITEjP58Pz/rvhh/P53E5+
d9HffPcdE7ynN1G5jvnkhTK64McnWl9e0LSveOumfOeidJS3QeCyZ5/UKq3u
U74e4IlrvFeSrA1k8zmQLsP5IsMBfCuGIg7NgNf3OTRiSUIru/4S94rIlxDs
X64izJU3iusevIuAFxDt3m42H9y9xxYPrmzy9kvb6/TciQnf8yOYu9ENFkyp
l1LpEJI+bI1RKbdtz8FobroX7YUA+2T5SRPNJ9LpNttivVRxA9LXAPsUVVmW
44n+DHMgH0zSLa1QDg72iIkO/hdbWeookHS4fYHhFKbQ5CLY7YSjnfYEqrJo
XtQ9sdM6/IeWBU7myx2GukQuOh4Uxvk///GfVbnYs4DjTzQbPXIfz8YKer/h
gun25OO3Sv4P2O3f007+JnrhkwSfrnYYUIEFzwdX0FxPJggN3Q6j7k25XcIp
X8jtPh3SNVu8tXsPJSpWK1DF4uPMVu18fxKzP4LCyk1j8YKvJ2MG+TRZBZIj
SH7mhL34ocZS443V0Cw9MSrx4FOJTRzEelPcjywNF32AzXwdv0IEl0vlZreK
TEJp+ja/ceOXQ9iDo/MSD8TuqH/Z38Oqu3C3zC/cFfeIObEtC2NJ2adt/CRU
gdpMHGtTSPCw08fVRnlaqa8HUEGUpHoOoqTOsSg1PCbjUaEYZPT6x9FPsp/6
boC7GFhsKqDMUDAgTy6P4J8Tr1nPBVXm0FZCuKV9Lfpmu4QyN4XE/ELnZziI
E6Wye2/eewzfHUFSiVi5KkL3Y9fbBXFeLk6oTqADFXa6G32rUywOD8AgovUy
LnjIiRSPElkUq9QARIvJzxKwucBLcwm/ax59/y5ONpEO+Jq8cwO6LYLsmfWK
fwSBBfueX3B6ZWOySsJ54JR6OYt43s0aioA3KCTNhRtHIrvqRIOHTTF5gTyk
MtQdmkj+HQpe1EVp6439RQLeACcmSrtbBlQc689uAc5I89+R2vGkrtD6nRV3
3vzauaeZPby1xc0sXmr3Rj/9xhSv4PJji2/n0m8h81v+9MtCeyW3aqvG+huk
XcUN9l2DpmMRLvaPzlrFsn+yv3p1K6c2fjy4YAvj6MfPzmstEmDfeqYhp2co
CwRd1V3OioI9ol9lcPaZ5ilH0RHJ3R87CR6HNnTn4WTaaDdbZ1yKfQGyklqr
Xrh00EjSOYAk/zyy1qnDSkHtOC/3QvtTbpzk8LN2VC+w1eCn1V34uXaCyzaA
o1qzmE5fNPD35khFbXp+Ucezjovhq9HlCO/xTuRofP12NBhN5bT/eoJnHuJ8
+Hp0idYmhz9dX91MJ7L/9q1sNMCpx/RZFI1a8ermaiwH5abimOMt/yAU921K
mEyRFJX0yRKXC2Op8ap3AyVXa9fBxmqAPXWZGhWYsMYYVNS/eE6Ms/D/jbPa
WZ0PiGut47qzkpIAchH4S9PAX9LXjk5JAvkpDzOAumrgDwOTGH+0xmMd1Whr
TPXzFfiY5ixhv6M/RzW+YKoazXbtCIZ8lX8WpJpq/1t8y9O03z1O+wbnacTD
w2i0G4oKOxNKNRSOtyOxD3xRXdyqaPrz9bC0dGl8ET2YuZyrC3n+M8p87x5A
7GOvHkjH8rjXsmnT/db9pFUrhW5x1CWhPskW7X41mA6ncgJyuXwtxPDyQtgL
D/8L67/3+g1DAAA=
</rfc> </rfc>
 End of changes. 71 change blocks. 
948 lines changed or deleted 501 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/