<?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"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-rfc7030est-clarify-10" number="8951" updates="7030" obsoletes="" submissionType="IETF" category="std" updates="7030"> consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title abbrev="rfc7030est">Clarification abbrev="Clarification of EST">Clarification of Enrollment over
    Secure Transport (EST): transfer encodings Transfer Encodings and ASN.1</title>
    <seriesInfo name="RFC" value="8951"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="T." surname="Werner" fullname="Thomas Werner">
      <organization>Siemens</organization>
      <address>
        <email>thomas-werner@siemens.com</email>
      </address>
    </author>
    <author initials="W." surname="Pan" fullname="Wei Pan">
      <organization>Huawei Technologies</organization>
      <address>
        <email>william.panwei@huawei.com</email>
      </address>
    </author>
    <date year="2020" month="August" day="11"/> month="November" year="2020"/>
    <area>Internet</area>
    <workgroup>LAMPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document updates RFC7030: RFC 7030: Enrollment over Secure Transport (EST)
      to resolve some errata that were reported, reported and which that have proven to
      cause interoperability issues when RFC7030 RFC 7030 was extended.</t>
      <t>This document deprecates the specification of “Content-Transfer-Encoding”
      "Content-Transfer-Encoding" headers for EST Enrollment over Secure Transport
      (EST) endpoints. This document
      fixes some syntactical errors in ASN.1 that were present.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Enrollment over Secure Transport (EST) is defined in <xref target="RFC7030"/>.
      target="RFC7030" format="default"/>. The EST specification defines a
      number of HTTP end points endpoints for certificate enrollment and management. The
      details of the transaction were defined in terms of MIME headers headers, as
      defined in <xref target="RFC2045"/>, target="RFC2045" format="default"/>, rather than in
      terms of the HTTP protocol protocol, as defined in <xref target="RFC7230"/> target="RFC7230"
      format="default"/> and <xref target="RFC7231"/>.</t> target="RFC7231" format="default"/>.</t>
      <t><xref target="RFC2616"/> target="RFC2616" format="default"/> and later <xref target="RFC7231"/> Appendix A.5 has
      target="RFC7231" sectionFormat="of" section="A.5"/> have text
      specifically deprecating Content-Transfer-Encoding. However, <xref target="RFC7030"/>
      target="RFC7030" format="default"/> incorrectly uses this header.</t>

      <t>Any updates to <xref target="RFC7030"/> target="RFC7030" format="default"/> to bring it inline
      in line with HTTP processing risk changing the on-wire protocol in a way
      that is not backwards compatible. However, reports from implementers
      suggest that many implementations do not send the
      Content-Transfer-Encoding, and many of them ignore it. The consequence
      is that simply deprecating the header would remain compatible with
      current implementations.</t>
      <t><xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> target="I-D.ietf-anima-bootstrapping-keyinfra"
      format="default"/> extends <xref target="RFC7030"/>, target="RFC7030" format="default"/>,
      adding new
functionality, and interop functionality. Interop testing of the protocol has
      revealed that unusual processing called out in <xref target="RFC7030"/> target="RFC7030"
      format="default"/> causes confusion.</t>
      <t>EST is currently specified as part of <xref target="IEC62351"/>, target="IEC62351"
      format="default"/> and is widely used in Government,
Utilities government, utilities, and Financial
      financial markets today.</t>
      <t>This document therefore document, therefore, revises <xref target="RFC7030"/> target="RFC7030"
      format="default"/> to reflect the field reality, deprecating the
      extraneous field.</t>
      <t>This document deals with errata numbers <xref target="errata4384"/>, target="errata4384"
      format="default"/>, <xref target="errata5107"/>, target="errata5107" format="default"/>, <xref target="errata5108"/>,
      target="errata5108" format="default"/>, and <xref target="errata5904"/>.</t> target="errata5904"
      format="default"/>.</t>
      <t>This document deals with <xref target="errata5107"></xref> target="errata5107" format="default"/>
      and <xref target="errata5904"></xref> target="errata5904" format="default"/> in
Section 3. <xref target="errata5108"></xref>
      target="estendpoint" format="default"/>. <xref target="errata5108"
      format="default"/> is dealt with in Section 5. <xref target="errata4384"></xref> target="error"
      format="default"/>.  <xref target="errata4384" format="default"/> is
      closed by correcting the ASN.1 Module in Section 4.</t> <xref target="csrasn1"
      format="default"/>.</t>
    </section>
    <section anchor="terminology" title="Terminology">

<t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="estendpoint" title="Changes numbered="true" toc="default">
      <name>Changes to EST endpoint processing">

<t>The <xref target="RFC7030"/> sections 4.1.3 Endpoint Processing</name>
      <t>Sections <xref target="RFC7030" sectionFormat="bare"
      section="4.1.3"/> (CA Certificates Response, /cacerts),
4.3.1/4.3.2 <xref
      target="RFC7030" sectionFormat="bare" section="4.3.1"/> and <xref
      target="RFC7030" sectionFormat="bare" section="4.3.2"/> (Full CMC,
      /fullcmc), 4.4.2 <xref target="RFC7030" sectionFormat="bare" section="4.4.2"/>
      (Server-Side Key Generation, /serverkeygen), and 4.5.2 <xref target="RFC7030"
      sectionFormat="bare" section="4.5.2"/> (CSR Attributes, /csrattrs) of
      <xref target="RFC7030" format="default"/>
      specify the use of base64 encoding with a Content-Transfer-Encoding for
      requests and response.</t> responses.</t>
      <t>This document updates <xref target="RFC7030"/> target="RFC7030" format="default"/> to
      require the POST request and payload response of all endpoints use Base64 encoding using
      base64 encoding, as specified in Section 4 of  <xref target="RFC4648"/>. target="RFC4648"
      sectionFormat="of" section="4"/>. In both cases, the Distinguished
      Encoding Rules (DER) <xref target="X.690"/> target="X.690" format="default"/> are used to
      produce the input for the Base64 base64 encoding routine. This format is to
      be used regardless of any Content-Transfer-Encoding header, and any
      value in such a header MUST <bcp14>MUST</bcp14> be ignored.</t>
      <section anchor="whitespace-processing" title="Whitespace processing"> numbered="true" toc="default">
        <name>White Space Processing</name>
        <t>Note that “base64” "base64" as used in the HTTP <xref target="RFC2616"/> target="RFC2616"
	format="default"/> does not permit CRLF, while the “base64” "base64" used in
	MIME <xref target="RFC2045"/> target="RFC2045" format="default"/> does. This
	specification clarifies that despite what <xref target="RFC2616"/>, that target="RFC2616"
	format="default"/> says, white space including CR, LF, spaces (ASCII 32) and,
	32), and tabs (ASCII 9) SHOULD <bcp14>SHOULD</bcp14> 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 numbered="true" toc="default">
        <name>Changes to Section 4 of RFC7030"> RFC 7030</name>
        <section anchor="section-413" title="Section 4.1.3"> anchor="sect-413" numbered="true" toc="default">
          <name>Section 4.1.3</name>
          <t>Replace:</t>

<figure><artwork><![CDATA[

<blockquote>
A successful response MUST <bcp14>MUST</bcp14> be a certs-only CMC Simple PKI Response,
as defined in [RFC5272], <xref target="RFC5272" format="default"/>, containing the certificates described in the
following paragraph.  The HTTP content-type of
"application/pkcs7-mime" is used.  The Simple PKI Response is sent
with a Content-Transfer-Encoding of "base64" [RFC2045].
]]></artwork></figure>

<t>with: (RFCEDITOR: maybe artwork is the wrong choice here)</t>

<figure><artwork><![CDATA[ <xref target="RFC2045"
format="default"/>.
</blockquote>
          <t>with:</t>
<blockquote>
A successful response MUST <bcp14>MUST</bcp14> be a certs-only CMC Simple PKI Response,
as defined in [RFC5272], <xref target="RFC5272" format="default"/>, containing the certificates described in the
following paragraph.  The HTTP content-type of
"application/pkcs7-mime" is used.  The CMC Simple PKI Response is
encoded in base64 [RFC4648].
]]></artwork></figure> <xref target="RFC4648" format="default"/>.
</blockquote>
        </section>
        <section anchor="section-431" title="Section 4.3.1"> anchor="sect-431" numbered="true" toc="default">
          <name>Section 4.3.1</name>
          <t>Replace:</t>

<figure><artwork><![CDATA[

<blockquote>
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
server MUST <bcp14>MUST</bcp14> reject the message.  The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request",
as specified in [RFC5273]. <xref target="RFC5273" format="default"/>.  The body of the message is the binary
value of the encoding of the PKI Request with a
Content-Transfer-Encoding of "base64" [RFC2045].
]]></artwork></figure> <xref target="RFC2045" format="default"/>.
</blockquote>
          <t>with:</t>

<figure><artwork><![CDATA[
<blockquote>
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
server MUST <bcp14>MUST</bcp14> reject the message.  The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request",
as specified in [RFC5273]. <xref target="RFC5273" format="default"/>.  The body of the message is encoded
in base64 [RFC4648].
]]></artwork></figure> <xref target="RFC4648" format="default"/>.
</blockquote>
        </section>
        <section anchor="section-432" title="Section 4.3.2"> anchor="sect-432" numbered="true" toc="default">
          <name>Section 4.3.2</name>
          <t>Replace:</t>

<figure><artwork><![CDATA[
<blockquote>
The body of the message is the binary value of the encoding of the
PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].
]]></artwork></figure> <xref
target="RFC2045" format="default"/>.
</blockquote>
          <t>with:</t>

<figure><artwork><![CDATA[
<blockquote>
The body of the message is the base64 [RFC4648] <xref target="RFC4648" format="default"/> encoding of the
PKI Response.
]]></artwork></figure>
</blockquote>
        </section>
        <section anchor="section-442" title="Section 4.4.2"> anchor="sect-442" numbered="true" toc="default">
          <name>Section 4.4.2</name>
          <t>Replace:</t>

<figure><artwork><![CDATA[
<blockquote>
An "application/pkcs8"
part consists of the base64-encoded DER-encoded [X.690] <xref target="X.690" format="default"/>
PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
[RFC4648].
]]></artwork></figure>
<xref target="RFC2045" format="default"/>.
</blockquote>
          <t>with:</t>

<figure><artwork><![CDATA[
<blockquote>
An "application/pkcs8" part consists of the base64-encoded base64-encoded,
DER-encoded [X.690] <xref target="X.690" format="default"/> PrivateKeyInfo.
]]></artwork></figure>
</blockquote>
          <t>Replace:</t>

<figure><artwork><![CDATA[
<blockquote>
In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part with an
smime-type parameter of "server-generated-key" and a Content-
Transfer-Encoding of "base64".
]]></artwork></figure>
</blockquote>
          <t>with:</t>

<figure><artwork><![CDATA[
<blockquote>
In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part
with an smime-type parameter of "server-generated-key". It is
base64 encoded [RFC4648].
]]></artwork></figure> <xref target="RFC4648" format="default"/>.
</blockquote>
        </section>
        <section anchor="section-452" title="Section 4.5.2"> anchor="sect-452" numbered="true" toc="default">
          <name>Section 4.5.2</name>
          <t>This section is updated in its entirety in <xref target="csrasn1"/>.</t> target="csrasn1" format="default"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="csrasn1" title="Clarification numbered="true" toc="default">
      <name>Clarification of ASN.1 for Certificate Attribute set.">

<t>Section 4.5.2 of <xref target="RFC7030"/> Set</name>
      <t><xref target="RFC7030" sectionFormat="of" section="4.5.2"/> is to be
      replaced with the following text:</t>
<blockquote>
      <t>4.5.2 CSR Attributes Response</t>
      <t>If locally configured policy for an authenticated EST client indicates
a CSR Attributes Response is to be provided, the server response MUST <bcp14>MUST</bcp14>
include an HTTP 200 response code.  An HTTP response code of 204 or 404
indicates that a CSR Attributes Response is not available.  Regardless
of the response code, the EST server and CA MAY <bcp14>MAY</bcp14> reject any subsequent
enrollment requests for any reason, e.g., incomplete CSR attributes in
the request.</t>
      <t>Responses to attribute request messages MUST <bcp14>MUST</bcp14> be encoded as the
content-type of “application/csrattrs”, "application/csrattrs" and are to be “base64” "base64" <xref target="RFC4648"/> target="RFC4648" format="default"/>
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

AttrOrOID ::= CHOICE {
  oid        OBJECT IDENTIFIER,
  attribute  Attribute {{AttrSet}} }

AttrSet ATTRIBUTE ::= { ... }
]]></artwork></figure>
]]></sourcecode>
      <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
      in the certification request.  The client
MUST <bcp14>MUST</bcp14> ignore any
      OID or attribute it does not recognize.  When the server encodes CSR Attributes
      attributes as an empty SEQUENCE, it means that the server has no
      specific additional information it desires in a client certification
      request (this is functionally equivalent to an HTTP response code of 204
      or 404).</t>
      <t>If the CA requires a particular cryptographic algorithm or use of a particular
signature scheme (e.g., certification of a public key based on a
certain elliptic curve, curve or signing using a certain hash algorithm) algorithm), it
MUST
<bcp14>MUST</bcp14> provide that information in the CSR Attribute Response.  If an
EST server requires the linking of identity and POP information (see
Section 3.5), it MUST <bcp14>MUST</bcp14> include the challengePassword OID in the CSR
Attributes Response.</t>
      <t>The structure of the CSR Attributes Response SHOULD, <bcp14>SHOULD</bcp14>, to the greatest
extent possible, reflect the structure of the CSR it is requesting.
Requests to use a particular signature scheme (e.g. (e.g., using a
particular hash function) are represented as an OID to be reflected
in the SignatureAlgorithm of the CSR.  Requests to use a particular
cryptographic algorithm (e.g., certification of a public key based on a certain
elliptic curve) are represented as an attribute, to be reflected as
the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
indicating the algorithm and the values indicating the particular
parameters specific to the algorithm.  Requests for descriptive
information from the client are made by an attribute, to be
represented as Attributes of the CSR, with a type indicating the
<xref target="RFC2985"/> target="RFC2985" format="default"/> extensionRequest and the values indicating the particular
attributes desired to be included in the resulting certificate’s certificate's
extensions.</t>
      <t>The sequence is Distinguished Encoding Rules (DER) encoded <xref target="X.690"/>
      target="X.690" format="default"/> and then base64 encoded (Section 4 of <xref target="RFC4648"/>). (<xref
      target="RFC4648" sectionFormat="of" section="4"/>).  The resulting text
      forms the application/csrattr body, without headers.</t>

   <t>For example, if a CA requests that a client to a) submit a certification
   request containing the challengePassword (indicating that linking of
   identity and POP information is requested; see Section 3.5), <xref target="RFC7030"
   section="3.5" sectionFormat="bare"/>), b) submit an
   extensionRequest with the Media Access Control (MAC) address
(<xref target="RFC2307"/>)
   <xref target="RFC2307" format="default"/> of the client, and to c) use the secp384r1 elliptic curve
and
   to sign with using the SHA384 hash function.  Then, function, then it takes the
following:</t>

<figure><artwork><![CDATA[
   following: </t>

      <artwork>
      OID:        challengePassword (1.2.840.113549.1.9.7)

      Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
                  value = macAddress (1.3.6.1.1.1.1.22)

      Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
                  value = secp384r1 (1.3.132.0.34)

      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[
      <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></figure>
      </artwork>
      <t>and then base64 encodes the resulting ASN.1 SEQUENCE to produce:</t>

<figure><artwork><![CDATA[
      <artwork>
 MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
 BgcrBgEBAQEWBggqhkjOPQQDAw==
]]></artwork></figure>
      </artwork>
    </blockquote>
    </section>
    <section anchor="error" title="Clarification numbered="true" toc="default">
      <name>Clarification of error messages Error Messages for certificate enrollment operations"> Certificate Enrollment Operations</name>
      <t><xref target="errata5108"/> target="errata5108" format="default"/> clarifies what format
      the error messages are to be in.
Previously 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" title="Updating section
	  numbered="true" toc="default">
        <name>Updating Section 4.2.3: Simple Enroll and Re-enroll Response"> Response</name>
        <t>Replace:</t>

<figure><artwork><![CDATA[
<blockquote>
    If the content-type is not set, the response data MUST <bcp14>MUST</bcp14> be a
    plaintext human-readable error message containing explanatory
    information describing why the request was rejected (for
    example, indicating that CSR attributes are incomplete).
]]></artwork></figure>
</blockquote>
        <t>with:</t>

<figure><artwork><![CDATA[
<blockquote>
    If the content-type is not set, the response data MUST <bcp14>MUST</bcp14> be a
    plaintext human-readable error message containing explanatory
    information describing why the request was rejected (for
    example, indicating that CSR attributes are incomplete).
    Servers MAY <bcp14>MAY</bcp14> use the "text/plain” "text/plain" content-type [RFC2046] <xref target="RFC2046"/>
    for human-readable errors.
]]></artwork></figure>
</blockquote>
      </section>
      <section anchor="updating-section-442-server-side-key-generation-response" title="Updating section numbered="true" toc="default">
        <name>Updating Section 4.4.2: Server-Side Key Generation Response"> Response</name>
        <t>Replace:</t>

<figure><artwork><![CDATA[
<blockquote>
    If the content-type is not set, the response data MUST <bcp14>MUST</bcp14> be a
    plaintext human-readable error message.
]]></artwork></figure>
</blockquote>
        <t>with:</t>

<figure><artwork><![CDATA[
<blockquote>
    If the content-type is not set, the response data MUST <bcp14>MUST</bcp14> be a
    plaintext human-readable error message.
    Servers MAY <bcp14>MAY</bcp14> use the "text/plain” "text/plain" content-type [RFC2046] <xref
    target="RFC2046" format="default"/>
    for human-readable errors.
]]></artwork></figure>
</blockquote>
      </section>
    </section>
    <section anchor="privacy-considerations" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>This document does not disclose any additional identities to that either
      an active or passive observer would see with <xref target="RFC7030"/>.</t> target="RFC7030"
      format="default"/>.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document clarifies an existing security mechanism.
It does not create any new protocol mechanism.</t> mechanisms.</t>
      <t>All security considerations from <xref target="RFC7030"/> target="RFC7030" format="default"/> also apply for to the clarifications described in this document.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>The ASN.1 module in Appendix A <xref target="asn1-module" format="default"/> of
      this document makes use of object identifiers (OIDs).  This document requests that IANA register (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 "SMI Security for PKIX Arc in the Module identifiers
subarc (1.3.6.1.5.5.7.0) Identifier" registry for the ASN.1 module.  The module.</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"/>.</t>

<t>IANA is requested to update target="RFC7030" format="default"/>.
      IANA has updated the “Reference” 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>
  </middle>
  <back>

    <references title='Normative References'>

<displayreference target="I-D.ietf-anima-bootstrapping-keyinfra" to="BRSKI"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>

        <reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680-201508-I/en">
          <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
            <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 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 Community, and requests discussion and suggestions for improvements.</t></abstract> month="August" year="2015"/>
          </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'> anchor="X.681" target="https://www.itu.int/rec/T-REC-X.681">
          <front>
<title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='N.' surname='Borenstein' fullname='N. Borenstein'><organization /></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 year='1996' month='November' />
<abstract><t>This initial document specifies the various headers used to describe the structure of MIME messages.  [STANDARDS-TRACK]</t></abstract> month="August" year="2015"/>
          </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'> anchor="X.682" target="https://www.itu.int/rec/T-REC-X.682">
          <front>
<title>PKCS #10: Certification Request
            <title>Information Technology - Abstract 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> 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 year='2000' month='November' />
<abstract><t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2986'/>
<seriesInfo name='DOI' value='10.17487/RFC2986'/>
</reference>

<reference  anchor="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 base 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) and the Public Key Infrastructure Using X.509 (PKIX)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner'><organization /></author>
<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 1988 version of ASN.1.  This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version.  There are no bits- on-the-wire changes to any of the formats; this is simply 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'><organization /></author>
<author initials='P.' surname='Yee' fullname='P. Yee' role='editor'><organization /></author>
<author initials='D.' surname='Harkins' fullname='D. Harkins' role='editor'><organization /></author>
<date year='2013' month='October' />
<abstract><t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport.  This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates.  It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t></abstract>
</front>
<seriesInfo name='RFC' value='7030'/>
<seriesInfo name='DOI' value='10.17487/RFC7030'/>
</reference>

<reference anchor="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 Object 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 Specification.</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: Parameterization 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 and communications security - Part 9: Cyber security key management for power system 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 /></author>
<author initials='M.' surname='Myers' fullname='M. Myers'><organization /></author>
<date year='2008' month='June' />
<abstract><t>This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</t><t>1.  The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t><t>2.  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 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 /></author>
<author initials='M.' surname='Myers' fullname='M. Myers'><organization /></author>
<date year='2008' month='June' />
<abstract><t>This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages.  The transport mechanisms described in this document are HTTP, file, mail, 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 /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<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)</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></author>
<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 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply 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='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'>
    <organization />
</author>

<author initials='T' surname='Eckert' fullname='Toerless Eckert'>
    <organization />
</author>

<author initials='M' surname='Behringer' fullname='Michael Behringer'>
    <organization />
</author>

<author initials='K' surname='Watsen' fullname='Kent Watsen'>
    <organization />
</author>

<date month='August' day='7' year='2020' />

<abstract><t>This document specifies automated bootstrapping of an Autonomic Control Plane.  To do this a Secure Key Infrastructure is bootstrapped.  This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline.  We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks.  Support for deployment models with less stringent security requirements is included.  Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device.  The established secure connection can be used to deploy a locally issued certificate to the device as well.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-anima-bootstrapping-keyinfra-43' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-43.txt' />
</reference>

<reference  anchor="RFC2616" target='https://www.rfc-editor.org/info/rfc2616'>
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='J.' surname='Gettys' fullname='J. Gettys'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<author initials='H.' surname='Frystyk' fullname='H. Frystyk'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<author initials='P.' surname='Leach' fullname='P. Leach'><organization /></author>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<date year='1999' month='June' />
<abstract><t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as &quot;HTTP/1.1&quot;, and is an update to RFC 2068.  [STANDARDS-TRACK]</t></abstract> month ="August" year="2015"/>
          </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'> anchor="X.683" target="https://www.itu.int/rec/T-REC-X.683">
          <front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message
            <title>Information Technology - Abstract Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview Notation One (ASN.1): Parameterization of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (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'/> ASN.1 specifications</title>
            <seriesInfo name='DOI' value='10.17487/RFC7230'/> 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>

        <reference  anchor="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'> anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload
            <title>Information Technology - ASN.1 encoding rules: Specification of messages (metadata and body content) Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/> Distinguished Encoding Rules (DER)</title>
            <seriesInfo name='DOI' value='10.17487/RFC7231'/> name="ITU-T Recommendation X.690," value="ISO/IEC 8825-1:2015"/>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
        </reference>

        <reference  anchor="RFC2985" target='https://www.rfc-editor.org/info/rfc2985'> anchor="IEC62351">
          <front>
<title>PKCS #9: Selected Object Classes
            <title>Power systems management 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 Laboratories' Public-Key Cryptography Standards (PKCS) series, associated information exchange - Data and change control is retained within the PKCS process.  The body of this document, except for the communications security considerations section, is taken directly from that specification.  This memo provides information - Part 9: Cyber security key management for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2985'/> power system equipment</title>
            <seriesInfo name='DOI' value='10.17487/RFC2985'/> name="ISO/IEC" value="62351-9:2017"/>
            <author>
              <organization>International Electrotechnical Commission</organization>
            </author>
            <date month="May" year="2017"/>
          </front>
        </reference>

        <reference  anchor="RFC2307" target='https://www.rfc-editor.org/info/rfc2307'> anchor="errata4384" quote-title="false"
		   target="https://www.rfc-editor.org/errata/eid4384">
          <front>
<title>An Approach for Using LDAP as a Network Information Service</title>
<author initials='L.' surname='Howard' fullname='L. Howard'><organization /></author>
<date year='1998' month='March' />
<abstract><t>This document describes an experimental mechanism for mapping entities 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 defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.</t></abstract>
            <title>Erratum ID 4384</title>
            <author>
              <organization>RFC Errata</organization>
            </author>
          </front>
<seriesInfo name='RFC' value='2307'/>
<seriesInfo name='DOI' value='10.17487/RFC2307'/>
	  <refcontent>RFC 7030</refcontent>
        </reference>

        <reference anchor="errata5107" quote-title="false"
		   target="https://www.rfc-editor.org/errata/eid5107">
          <front>
            <title>Erratum ID 5107</title>
            <author>
              <organization>RFC Errata</organization>
            </author>
          </front>
	  <refcontent>RFC 7030</refcontent>
        </reference>

        <reference anchor="errata5108" quote-title="false"
		   target="https://www.rfc-editor.org/errata/eid5108">
          <front>
            <title>Erratum ID 5108</title>
            <author>
              <organization>RFC Errata</organization>
            </author>
          </front>
	  <refcontent>RFC 7030</refcontent>
        </reference>

        <reference anchor="errata5904" quote-title="false"
		   target="https://www.rfc-editor.org/errata/eid5904">
          <front>
            <title>Erratum ID 5904</title>
            <author>
              <organization>RFC Errata</organization>
            </author>
          </front>
	  <refcontent>RFC 7030</refcontent>
        </reference>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5273.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
      </references>

      <references>
        <name>Informative References</name>

<!-- [I-D.ietf-anima-bootstrapping-keyinfra-44] in EDIT state as of 11/17/20-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-anima-bootstrapping-keyinfra.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2616.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2985.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2307.xml"/>
      </references>
    </references>
    <section anchor="asn1-module" title="ASN.1 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"/>, target="X.680" format="default"/>, <xref target="X.681"/>, target="X.681"
      format="default"/>, <xref target="X.682"/> target="X.682" format="default"/>, and <xref target="X.683"/>.</t>
      target="X.683" format="default"/>.</t>
      <t>The ASN.1 modules makes imports from the ASN.1 modules in <xref target="RFC5912"/>
      target="RFC5912" format="default"/> and <xref target="RFC6268"/>.</t> target="RFC6268"
      format="default"/>.</t>
      <t>There is no ASN.1 Module in RFC 7030. <xref target="RFC7030"
      format="default"/>.  This module has been created by combining the lines
      that are contained in the document body.</t>

<figure><artwork><![CDATA[

<sourcecode type="asn.1"><![CDATA[
PKIXEST-2019
     { iso(1) identified-organization(3) dod(6)
       internet(1) security(5) mechanisms(5) pkix(7)
       id-mod(0)
       id-mod-est-2019(TBD) id-mod-est-2019(98) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORTS ALL --

IMPORTS

Attribute
FROM CryptographicMessageSyntax-2010  -- [RFC6268]
      { iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs-9(9) smime(16) modules(0)
         id-mod-cms-2009(58) }

ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- [RFC5912]
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkixCommon-02(57) } ;

-- CSR Attributes

CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

AttrOrOID ::= CHOICE {
   oid        OBJECT IDENTIFIER,
   attribute  Attribute {{AttrSet}} }

AttrSet ATTRIBUTE ::= { ... }

-- Asymmetric Decrypt Key Identifier Attribute

aa-asymmDecryptKeyID ATTRIBUTE ::=
    { TYPE AsymmetricDecryptKeyIdentifier
      IDENTIFIED BY id-aa-asymmDecryptKeyID }

id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
    smime(16) aa(2) 54 }

AsymmetricDecryptKeyIdentifier ::= OCTET STRING

END
]]></artwork></figure>
]]></sourcecode>
    </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>

<!-- ##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>