<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.3.8) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-rfc7030-csrattrs-23" number="9908" category="std" consensus="true" submissionType="IETF" updates="70309148" updates="7030, 9148" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" version="3"> version="3" xml:lang="en">

<!-- xml2rfc v2v3 conversion 3.25.0 [rfced] We have updated the document title and short title that
spans the header of the PDF file as follows. Please let us know
any objections.

Original (Title):
   Clarification and enhancement of RFC7030 CSR Attributes
   definition

Current:
   Clarification and Enhancement of the CSR Attributes
   Definition in RFC 7030

...
Original (Short Title):
   CSRAttr

Current:
   CSR Attributes
-->

  <front>
    <title abbrev="CSRAttrs">Clarification abbrev="CSR Attributes">Clarification and enhancement Enhancement of RFC7030 the CSR Attributes definition</title> Definition in RFC 7030</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc7030-csrattrs-23"/> name="RFC" value="9908"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson" role="editor">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="O." surname="Friel" fullname="Owen Friel">
      <organization>Cisco</organization>
      <address>
        <email>ofriel@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="von Oheimb" fullname="Dr. David von Oheimb">
      <organization>Siemens</organization>
      <address>
        <email>dev@ddvo.net</email>
      </address>
    </author>
    <author initials="D." surname="Harkins" fullname="Dan Harkins">
      <organization>The Industrial Lounge</organization>
      <address>
        <email>dharkins@lounge.org</email>
      </address>
    </author>
    <date year="2025" month="June" day="28"/>
    <area>Internet</area>
    <workgroup>LAMPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="December"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<!-- [rfced] This document updates RFC 7030, which has multiple errata
reports. Some of the errata reports seem relevant to the content of this
document. Please review to ensure that these reports have been addressed
if necessary. Specifically, Section 3.2 is about extending Section 4.5.2
of RFC 7030, which is the subject of this errata report:
https://www.rfc-editor.org/errata/eid4384. Additionally, we note that the
previous ASN.1 syntax from RFC 7030 appears in this document rather than
the updated syntax. Are any updates needed here?

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

AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
     type   ATTRIBUTE.&id({IOSet}),
     values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

Perhaps:
AttrOrOID ::= CHOICE {
      oid OBJECT IDENTIFIER,
      attribute Attribute{YouNeedToDefineOrReferenceAnObjectSet}
}
-->

    <abstract>
      <?line 94?>
<t>This document updates RFC7030, Enrollment RFC 7030, "Enrollment over Secure Transport Transport" (EST), clarifying
how the Certificate Signiing Signing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute Object IDs (OID) Identifiers (OIDs) and also CSR attribute values,
in particular particularly X.509 extension values, that the server expects the client to include in a subsequent CSR request.
RFC9148
RFC 9148 is derived from RFC7030, RFC 7030 and it is also updated.</t>
      <t>RFC7030 (EST)
      <t>RFC 7030 is ambiguous in its specification of the CSR Attributes Response.

<!--[rfced] May we combine these sentences as shown below to avoid the
repetition of "This has resulted in" and "As a result"?

Original:
   This has resulted in implementation challenges and implementor
   confusion.  As a result, there was not universal
   understanding of what was specified.

Perhaps:
   This has resulted in implementation challenges and implementor
   confusion because there was no universal understanding of what
   was specified.
-->
      This has resulted in implementation challenges and implementor confusion. As a result,
there was no universal understanding of what was specified.
This document clarifies the encoding rules.</t>
      <t>This document therefore also provides a new straightforward approach: using
a template for CSR contents that may be partially filled in by the server.
This also allows an EST server to specify a subject Distinguished Name (DN).</t>
    </abstract>
  </front>
  <middle>
    <?line 112?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document updates RFC7030 Enrollment over Secure Transport (EST) RFC 7030 and clarifies
how the Certificate Signing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values.
In particular, the server needs to be able to specify X.509 extension values that it expects the client to include in the subsequent CSR.</t>
      <t>Enrollment
      <t>"Enrollment over Secure Transport Transport" <xref target="RFC7030"/> (EST) has been used in a wide variety of applications.
In particular, <xref target="RFC8994"/> and <xref target="RFC8995"/> describe a way to use it in order to build out an Autonomic Control Plane (ACP) <xref target="RFC8368"/>.</t>
<t>When bootstrapping the ACP, there is a requirement that each node be given a very specific subjectAltName.

<!--[rfced] We note that "CSR Attributes resource" is not present
in Section 2.6 or any other sections in RFC 7030. Was "CSR
Attributes Request" or "CSR Attributes Response" perhaps
intended?

Original:
   In [RFC8994], the ACP specification, the EST server is specified to
   make use of the CSR Attributes ("/csrattrs") resource (specified in
   [RFC7030], Section 2.6) to convey to the EST client that needs to
   go into its CSR and thus ultimately into its End Entity
   certificate.

Perhaps:
   In [RFC8994], the ACP specification, the EST server is specified to
   make use of the CSR Attributes ("/csrattrs") Request (specified in
   [RFC7030], Section 2.6) to convey the actual subjectAltName to the
   EST client that needs to go into its CSR and thus ultimately into
   its End Entity (EE) certificate.
-->

In <xref target="RFC8994"/>, the ACP specification, the EST server is specified to make use of the CSR Attributes ("/csrattrs") resource (specified in <xref section="2.6" sectionFormat="comma" target="RFC7030"/>) to convey the actual subjectAltName to the EST client the actual subjectAltName that needs to go into its CSR and thus ultimately into its End Entity (EE) certificate.</t>
      <t>As a result of some implementation challenges, it came to light that this particular way of using the CSR attributes was not universally agreed upon, and it was suggested that it went contrary to <xref section="2.6" sectionFormat="comma" target="RFC7030"/>.</t>
<!-- DNE -->
      <t><xref section="2.6" sectionFormat="comma" target="RFC7030"/> says that the CSR attributes "can provide additional
descriptive information that the EST server cannot access itself".
This is extended to describe how the EST server can provide values that it demands be used.</t>
<!-- DNE -->
      <t>After significant discussion, it has been determined that
<xref section="4.5" sectionFormat="of" target="RFC7030"/> specification is sufficiently difficult
to read and ambiguous to interpret that interpret, so clarification is needed.</t>
      <t>Also, <xref section="4.5.2" sectionFormat="comma" target="RFC7030"/> is extended to clarify the use of the existing ASN.1 syntax <xref target="X.680"/><xref target="X.680"/> <xref target="X.690"/>.</t>
      <t>This covers all uses and is fully backward compatible with existing use,
including addressesing addressing the needs of <xref target="RFC8994"/> and <xref target="RFC8995"/>.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The
        <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 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
<?line -6?>
        </t>
    </section>
    <section anchor="csr-attributes-handling">
      <name>CSR Attributes Handling</name>
      <section anchor="extensions-to-rfc-7030-section-26">
        <name>Extensions to RFC 7030 section 7030, Section 2.6</name>
        <t>Replace
<!-- [rfced] FYI - We have updated the sentence below. Please let us
know any objections.

Original:
   Replace the second paragraph with the following text:

Current:
   This document replaces the second paragraph in Section 2.6
   of RFC 7030 with the following text:
-->
        <t>This document replaces the second paragraph in <xref section="2.6" sectionFormat="of" target="RFC7030"/> with the following text:</t>
        <artwork><![CDATA[
   These
   <blockquote>These attributes can provide additional information that
   the EST server cannot access itself, such as the Media Access Control
   (MAC) address of an interface of the EST client. The EST server can
   also provide concrete values that it tells the client to include in
   the CSR, such as a specific X.509 Subject Alternative Name extension.
   Moreover, these attributes can indicate the type of the included
   public key or which crypto algorithms to use for the self-signature,
   such as a specific elliptic curve or a specific hash function that
   the client is expected to use when generating the CSR.
]]></artwork> CSR.</blockquote>
      </section>
      <section anchor="csrattrs">
        <name>Extensions to RFC 7030 section 7030, Section 4.5.2</name>
        <t>The ASN.1 syntax for CSR Attributes as defined in EST <xref (<xref section="4.5.2" sectionFormat="comma" target="RFC7030"/> target="RFC7030"/>) is as follows:</t>
        <artwork><![CDATA[
        <sourcecode type="asn.1"><![CDATA[
   CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
]]></artwork> }]]></sourcecode>
        <t>This remains unchanged, such that bits-on-the-wire compatibility is maintained.</t>
        <t>Key parts that were unclear were which OID to use in the '<tt>type</tt>' field and
that the '<tt>values</tt>' field can contain an entire sequence of X.509 extensions.</t>
        <t>The OID to use for such attributes in the '<tt>type</tt>' field MUST <bcp14>MUST</bcp14> be <tt>id-ExtensionReq</tt>,
which has the value 1.2.840.113549.1.9.14.
Note that this is the same as <tt>pkcs-9-at-extensionRequest</tt> defined in PKCS#9 <xref target="RFC2985"/>.
There MUST <bcp14>MUST</bcp14> be only one such attribute.</t>
        <t>The '<tt>values</tt>' field of this attribute MUST <bcp14>MUST</bcp14> contain a set with exactly one element,
and this element MUST <bcp14>MUST</bcp14> be of type <tt>Extensions</tt>, as per <xref section="4.1" sectionFormat="of" target="RFC5280"/>:</t>
        <artwork><![CDATA[
        <sourcecode type="asn.1"><![CDATA[
   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }
]]></artwork>
        }]]></sourcecode>
        <t>An Extension comprises the OID of the specific X.509 extension (extnID),
optionally the 'critical' bit, and the extension value (extnValue).</t>
        <t>An Extensions structure, which is a sequence of elements of type Extension,
MUST NOT
<bcp14>MUST NOT</bcp14> include more than one element with a particular extnID.</t>
        <t>When not using the template-based approach of <xref target="csrtemplate"/>,
specifying the requirement for a public key of a specific type
and optionally its size and other parameters MUST <bcp14>MUST</bcp14> be done as follows:
Include exactly one Attribute with the <tt>type</tt> field being the OID specifying
the type of the key, such as <tt>ecPublicKey</tt> or <tt>rsaEncryption</tt>.
The '<tt>values</tt>' field MAY <bcp14>MAY</bcp14> be empty to indicate no further requirements on the key.

<!-- [rfced] May we rephrase the following sentence to limit the
repetition of "such as"?

Also, is "EC curve" referring to "elliptic curve (EC)" (option A) or
"Elliptic Curve Cryptography (ECC)" (option B)?  (Note that if it's
the latter form, "ECC" will be expanded here rather than in Section
3.4.)

Original:
   Otherwise, it MUST contain suitable parameters for the
   given key type, such as a singleton set containing the OID of an EC
   curve such as secp384r1 or containing an integer value for the RSA
   key size such as 4096.

Perhaps A:
   Otherwise, it MUST contain suitable parameters for the given key
   type, such as a singleton set containing the OID of an elliptic
   curve (EC) (e.g., secp384r1) or containing an integer value for the
   RSA key size (e.g., 4096).

or
Perhaps B:
   Otherwise, it MUST contain suitable parameters for the given key
   type, such as a singleton set containing the OID of an Elliptic
   Curve Cryptography (ECC) (e.g., secp384r1) or containing an
   integer value for the RSA key size (e.g., 4096).
-->

Otherwise, it <bcp14>MUST</bcp14> contain suitable parameters for the given key type,
such as a singleton set containing the OID of an EC curve such as <tt>secp384r1</tt>
or containing an integer value for the RSA key size such as 4096.
Many examples for this are given in <xref target="examples"/>.</t>
      </section>
      <section anchor="update-to-rfc9148">
        <name>Update to RFC9148</name>
        <t>The RFC 9148</name>
<!-- [rfced] May we rephrase the sentence below as follows to clarify
"transport"?

Original:
   The updates to EST in this THISRFC equally apply when using
   CoAP as a transport as described in [RFC9148].

Perhaps:
   The updates to EST in this document equally apply when using
   CoAP as a transport mechanism as described in [RFC9148].
-->
<t>The updates to EST in this document equally apply when using the
Constrained Application Protocol (CoAP) as a transport as described in <xref target="RFC9148"/>.
THISRFC
This document therefore adds the following paragraph after the second paragraph
of <xref section="1" sectionFormat="comma" target="RFC9148"/>:</t>
        <aside>
          <t>RFC EDITOR: Please replace THISRFC with
<!-- [rfced] We will update the RFC number for this document.</t>
        </aside>
        <t><tt> sentence below as follows if there are
no objections.

Original:
   EST over CoAP as specified in {{RFC9148}} applies unchanged to
   {{RFC7030}} updated by THISRFC.  Hence, all references to {{RFC7030}} in
   {{RFC9148}} are assumed to indicate {{RFC7030}} updated by THISRFC.
</tt></t>

Perhaps:
   EST over CoAP as specified in [RFC9148] applies unchanged to
   [RFC7030], which is updated by RFC 9908.  Hence, all references to
   [RFC7030] in [RFC9148] are assumed to indicate that [RFC7030] is
   updated by RFC 9908.
-->
        <blockquote>EST over CoAP as specified in <xref target="RFC9148"/> applies unchanged
to <xref target="RFC7030"/> updated by RFC 9908.
Hence, all references to <xref target="RFC7030"/> in <xref target="RFC9148"/> are assumed to indicate
<xref target="RFC7030"/> updated by RFC 9908.</blockquote>
      </section>
      <section anchor="csrtemplate">
        <name>Use of CSR templates</name>
        <t>Alternatively Templates</name>

<!-- [rfced] We note that the following lines exceed the 72-character
limit. Please let us know how the lines should be broken/wrapped.

Section 3.4 (2 characters too long):
   EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL

Sections 5.3.2 and 5.6.2 (11 characters too long):
   33   9:   OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)

Appendix A (3 characters too long):
   TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate }
-->

        <t>As an alternative to the unstructured inclusion of CSR attributes
specified in <xref section="4.5.2" sectionFormat="comma" sectionFormat="of" target="RFC7030"/> with its limitations and ambiguities,
<xref section="B" sectionFormat="of" target="RFC8295"/> describes an approach using a CSR template.
An entire CSR object is returned with various fields filled out, out and other fields waiting to be filled in.

<!-- [rfced] May we rephrase the following sentence to avoid using RFC
2986 as an adjective?

Also, we do not see "Full PKI Data content type" in RFC 5272. We do
see "PKIData content type" and "Full PKI Request/Response". Should
this be updated as "PKIData content type"?

Original:
   In that approach, a pKCS7PDU attribute includes a Full PKI Data
   content type <xref target="RFC5272"/> [RFC5272] and that in turn includes an <xref target="RFC2986"/> [RFC2986] CSR
   or a Certificate Request Message Format (CRMF) formatted request
   (for details see <xref target="RFC6268"/> [RFC6268] Sections 5 or 9, respectively).

Perhaps:
   In that approach, a pKCS7PDU attribute includes a PKIData content
   type [RFC5272] and that, in turn, includes a CSR [RFC2986] or a
   Certificate Request Message Format (CRMF) formatted request (for
   details, see Sections 5 or 9 of [RFC6268], respectively).
-->

In that approach, a pKCS7PDU attribute includes a Full PKI Data content type <xref target="RFC5272"/>
and that, in turn, includes a CSR <xref target="RFC2986"/> or a Certificate Request Message Format (CRMF) formatted request
(for details, see Sections <xref target="RFC6268" sectionFormat="bare" section="5"/> or <xref target="RFC6268" sectionFormat="bare" section="9"/> of <xref target="RFC6268"/>, respectively).</t>
        <t>One drawback to that approach, particularly for the CSR, is that some unused
fields have to be included; specifically, the '<tt>signature</tt>' field on
the CSR is faked with an empty bit string.</t>
        <t>A similar method has been defined in CMP Updates "Certificate Management Protocol (CMP) Updates" <xref target="RFC9480"/>
and the Lightweight CMP profile <xref "Lightweight Certificate Management Protocol (CMP) Profile" (<xref section="4.3.3" sectionFormat="comma" target="RFC9483"/>, target="RFC9483"/>) using a CSR template as defined for CRMF <xref target="RFC4211"/>.
Like the approach mentioned before,
this method does not properly deal with absent Relative Distinguished Name (RDN) values, as it would encode them as invalid empty strings.
Also
Also, encoding an absent '<tt>subjectPublicKey</tt>' value as an empty <tt>BIT STRING</tt>
and an absent X.509 extension value as an empty <tt>OCTET STRING</tt>
can cause issues with strict ASN.1 parsing and decoding.</t>
        <t>These drawbacks are avoided as follows:</t>
        <t>This specification defines a new Certificate Request Information Template attribute
for <tt>CsrAttrs</tt> (as given in <xref target="csrattrs"/>) that is essentially
a partially filled in filled-in PKCS#10 CSR minus the signature wrapper:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
  CertificationRequestInfoTemplate ::= SEQUENCE {
      version       INTEGER { v1(0) } (v1, ... ),
      subject       NameTemplate OPTIONAL,
      subjectPKInfo [0] SubjectPublicKeyInfoTemplate
                                {{ PKInfoAlgorithms }} OPTIONAL,
      attributes    [1] Attributes{{ CRIAttributes }}
  }
]]></artwork>
  }]]></sourcecode>
        <t><xref target="app-asn1-module"/> contains all detail.</t> details.</t>
        <t>The CertificationRequestInfoTemplate closely resembles the CertificationRequestInfo
from <xref section="5" sectionFormat="comma" target="RFC5912"/>:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
  CertificationRequestInfo ::= SEQUENCE {
    version       INTEGER { v1(0) } (v1,...),
    subject       Name,
    subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
    attributes    [0] Attributes{{ CRIAttributes }}
  }
]]></artwork>
  }]]></sourcecode>
        <t>with the following differences.</t> differences:</t>
        <ul spacing="normal">
          <li>
            <t>The '<tt>subject</tt>' field has been made <tt>OPTIONAL</tt>. <tt><bcp14>OPTIONAL</bcp14></tt>.
It MUST <bcp14>MUST</bcp14> be present if the server places any requirements on the RDNs of the subject name; otherwise, it MUST <bcp14>MUST</bcp14> be absent.</t>
          </li>
          <li>
            <t>RelativeDistinguishedNames (RDNs)
            <t>RDNs in the '<tt>subject</tt>' fields are allowed to have no value,
which has been achieved by adding <tt>OPTIONAL</tt> <tt><bcp14>OPTIONAL</bcp14></tt> to the '<tt>value</tt>' field of <tt>SingleAttributeTemplate</tt>.
If the client is expected to provide an RDN of a certain type such as <tt>commonName</tt>,
the respective RDN MUST <bcp14>MUST</bcp14> be present in the '<tt>subject</tt>' field; otherwise otherwise, it MUST <bcp14>MUST</bcp14> be absent.
If
In addition, if the server in addition gives an RDN value,
this means that the client is expected to use this value for the RDN,
otherwise RDN; otherwise, the client is expected to fill in a suitable value.
The example at the end of this section has a '<tt>subject</tt>' field
that contains both forms of RDN specifications.</t>
          </li>
        </ul>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
  SingleAttributeTemplate {ATTRIBUTE:AttrSet} ::= SEQUENCE {
      type      ATTRIBUTE.&id({AttrSet}),
      value     ATTRIBUTE.&Type({AttrSet}{@type}) OPTIONAL
  }

]]></artwork>
  }]]></sourcecode>
        <ul spacing="normal">
          <li>
            <t>The '<tt>subjectPKInfo</tt>' field has been made <tt>OPTIONAL</tt>. <tt><bcp14>OPTIONAL</bcp14></tt>.
The field MUST <bcp14>MUST</bcp14> be absent if the server places no requirements on the key.
Otherwise, key; otherwise, it MUST <bcp14>MUST</bcp14> be present, and the '<tt>algorithm</tt>' field
specifies the type of the key pair the client is expected to use.</t>
          </li>
          <li>
            <t>The '<tt>subjectPublicKey</tt>' field contained in <tt>SubjectPublicKeyInfoTemplate</tt>
has been made <tt>OPTIONAL</tt> <tt><bcp14>OPTIONAL</bcp14></tt> because usually it is usually not needed.
In case the server requires use of an RSA key and needs to specify its size, the field
MUST
<bcp14>MUST</bcp14> be present and contain a placeholder public key value of the desired RSA modulus length.
Otherwise, length; otherwise, the <tt>subjectPublicKey</tt> MUST <bcp14>MUST</bcp14> be absent.</t>
          </li>
        </ul>
        <artwork><![CDATA[
        <sourcecode><![CDATA[
  SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE {
      algorithm        AlgorithmIdentifier{PUBLIC-KEY, {IOSet}},
      subjectPublicKey BIT STRING OPTIONAL
  }
]]></artwork>
  }]]></sourcecode>
        <ul spacing="normal">
          <li>
            <t>A new OID <tt>id-aa-extensionReqTemplate</tt> and the related <tt>ExtensionTemplate</tt> structure
is defined where the '<tt>extnValue</tt>' field has been made <tt>OPTIONAL</tt>. <tt><bcp14>OPTIONAL</bcp14></tt>.
This is only needed to enable specifying partial extensions with values to be filled in
by the client; otherwise otherwise, the <tt>id-ExtensionReq</tt> OID and the respective value of type
<tt>ExtensionReq</tt> MUST <bcp14>MUST</bcp14> be used for specifying requirements on X.509 extensions.</t>
          </li>
        </ul>
        <t>For each extension of type <tt>Extension</tt> or <tt>ExtensionTemplate</tt> provided by the server,
the client is expected to include an extension of the type given by the <tt>extnID</tt>.
If the '<tt>critical</tt>' field is present, the client SHOULD <bcp14>SHOULD</bcp14> use it in the extension as well.
If the '<tt>extnValue</tt>' is present (which is always the case when type <tt>Extension</tt> is used),
the client SHOULD <bcp14>SHOULD</bcp14> use the given extension value in its CSR.
When the type <tt>ExtensionTemplate</tt> is used, the '<tt>extnValue</tt>' can be absent, and then the client SHOULD <bcp14>SHOULD</bcp14> provide an extension value in an <tt>Extension</tt> with the given <tt>extnID</tt>.
For instance, if the server includes an <tt>ExtensionTemplate</tt>
with the <tt>extnID</tt> '<tt>subjectAltName</tt>' but without an <tt>extnValue</tt>,
the client SHOULD <bcp14>SHOULD</bcp14> include a SAN extension with a suitable value.</t>
        <t>In case the server includes an <tt>ExtensionTemplate</tt> with the <tt>extnID</tt> '<tt>subjectAltName</tt>'
and a partially filled in filled-in <tt>extnValue</tt>, such as a '<tt>directoryName</tt>' choice containing the <tt>NULL-DN</tt>
(i.e., an empty sequence of RDNs) or the '<tt>iPAddress</tt>' choice with an empty <tt>OCTET STRING</tt>,
this
it means that the client SHOULD <bcp14>SHOULD</bcp14> fill in the respective <tt>GeneralName</tt> value.</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
  ExtensionTemplate {EXTENSION:ExtensionSet} ::= SEQUENCE {
     extnID      EXTENSION.&id({ExtensionSet}),
     critical    BOOLEAN DEFAULT FALSE,
     extnValue   OCTET STRING (CONTAINING
                 EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL
                 --  contains the DER encoding of the ASN.1 value
                 --  corresponding to the extension type identified
                 --  by extnID when present
  }
]]></artwork>
  }]]></sourcecode>
        <t>The '<tt>version</tt>' field of the <tt>CertificationRequestInfoTemplate</tt> MUST <bcp14>MUST</bcp14> contain v1 (0).</t>
        <t>The '<tt>attributes</tt>' field MUST NOT <bcp14>MUST NOT</bcp14> contain multiple <tt>id-aa-extensionReqTemplate</tt> attributes
and MUST NOT <bcp14>MUST NOT</bcp14> contain both <tt>id-ExtensionReq</tt> and <tt>id-aa-extensionReqTemplate</tt> attributes.</t>
        <t>The '<tt>values</tt>' field of an <tt>id-aa-extensionReqTemplate</tt> attribute
MUST
<bcp14>MUST</bcp14> contain a set with exactly one element,
and this element MUST <bcp14>MUST</bcp14> be of type <tt>ExtensionTemplate</tt>.</t>

<!-- [rfced] Some author comments are present in the XML. Please
confirm that no updates related to these comments are
outstanding. Note that the comments will be deleted prior to
publication.
-->

<!--
Each of the attributes has a single attribute value instance in the
values set.  Even though the syntax is defined as a set, there MUST
be exactly one instance of AttributeValue present.
-->

<t>Suppose the server requires that the CSR will contain:</t>
        <ul spacing="normal">
          <li>
            <t>the '<tt>subject</tt>' field with a common name to be filled in by the EE and
two organizational unit names with given values "myDept" and "myGroup",</t>
          </li>
          <li>
            <t>the '<tt>publicKey</tt>' field contains with an
Elliptic Curve Cryptography (ECC) key on curve <tt>secp256r1</tt>,</t>
          </li>
          <li>
            <t>the 'subjectAltName' extension with two entries; one DNS entry with
name "www.myServer.com" and IP entry that is empty for the IP address
to be filled in.</t> in,</t>
          </li>
          <li>
            <t>the '<tt>keyUsage</tt>' extension marked critical
with the value values digitalSignature and keyAgreement, and</t>
          </li>
          <li>
<!-- [rfced] Should "value" be plural here (option A), or is a
definite article needed (option B)?

Original:
   *  the 'extKeyUsage' extension with value to be filled in
      by the EE.

Perhaps A:
   *  the 'extKeyUsage' extension with values to be filled in
      by the EE.

or
Perhaps B:
   *  the 'extKeyUsage' extension with the value to be filled in
      by the EE.
-->
            <t>the '<tt>extKeyUsage</tt>' extension with value to be filled in by the EE.</t>
          </li>
        </ul>
        <t>Then
        <t>Then, the <tt>CertificationRequestInfo</tt> structure constructed by the server
will be as follows:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
SEQUENCE {
  INTEGER 0
  SEQUENCE {
    SET {
      SEQUENCE {
        OBJECT IDENTIFIER commonName (2 5 4 3)
        }
      }
    SET {
      SEQUENCE {
        OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
        UTF8String "myDept"
        }
      }
    SET {
      SEQUENCE {
        OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
        UTF8String "myGroup"
        }
      }
    }
  [0] {
    SEQUENCE {
      OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
      OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
      }
    }
  [1] {
    SEQUENCE {
      OBJECT IDENTIFIER id-aa-extensionReqTemplate
                        (1 2 840 113549 1 9 TBD3) 62)
      SET {
        SEQUENCE {
          SEQUENCE {
            OBJECT IDENTIFIER subjectAltName (2 5 29 17)
            OCTET STRING, encapsulates {
              SEQUENCE {
                [2] "www.myServer.com"
                [7] ""
                }
              }
            }
          SEQUENCE {
            OBJECT IDENTIFIER keyUsage (2 5 29 15)
            BOOLEAN TRUE
            OCTET STRING, encapsulates {
              BIT STRING 3 unused bits
                "10001"B
              }
            }
          SEQUENCE {
            OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
            }
          }
        }
      }
    }
  }
]]></artwork>
  }]]></sourcecode>
      </section>
    </section>
    <section anchor="co-existence-with-existing-implementations">
      <name>Co-existence
      <name>Coexistence with existing implementations</name>
      <t>EST Existing Implementations</name>
<!-- [rfced] FYI: To avoid hyphenating an RFC number, we have updated
this sentence as shown below. Please see style guidance at
<https://www.rfc-editor.org/styleguide/part2/#rfc_as_compound>.

Original:
   EST servers with legacy clients MAY continue to use the <xref target="RFC7030"/>-style [RFC7030]-
   style unstructured list of attribute/value pairs, and MAY also include
   the template style described in Section 3.4 for newer clients.

Current:
   EST servers with legacy clients MAY continue to use the unstructured
   list of attribute/value pairs as described in [RFC7030] and MAY also
   include the template style described in Section 3.4 for newer clients.
-->
<t>EST servers with legacy clients <bcp14>MAY</bcp14> continue to use the  unstructured list of attribute/value pairs as described in <xref target="RFC7030"/> and <bcp14>MAY</bcp14> also include the template style described in <xref target="csrtemplate"/> for newer clients.
Clients which that understand both MUST <bcp14>MUST</bcp14> use the template only, and
ignore all other <tt>CSRattrs</tt> elements.
Older clients will ignore the new CertificationRequestInfoTemplate element.</t>
    </section>
    <section anchor="examples">
      <name>Examples using Using the original Original Approach in RFC 7030 approach</name> 7030</name>
      <t>Each example has a high-level (English) explanation of what is expected.
Some mapping back to the Attribute and Extension definitions above are included.
The base64 DER encoding is then shown.
The output of "dumpasn1" <xref target="dumpasn1"/> is then provided to detail what the contents are.</t>
      <section anchor="acpNodeName">
        <name>Require an RFC8994/ACP RFC 8994 / ACP subjectAltName with specific Specific otherName</name>
        <t>A single subjectAltName extension is specified in a single <xref target="RFC7030"/> <tt>CsrAttrs</tt>
attribute <xref target="RFC7030"/> with an OID '<tt>id-ExtensionReq</tt>' indicating type <tt>Extensions</tt>.
This is what might be created by an a Registrar <xref target="RFC8995"/> Registrar that is asking for AcpNodeName <xref target="RFC8994"/> AcpNodeName with format '<tt>otherNames</tt>'.</t>
        <section anchor="base64-encoded-example">
          <name>Base64 encoded example</name>
          <name>Base64-Encoded Example</name>
          <t>The Base64:</t>
          <sourcecode type="base64" markers="false"><![CDATA[
MGgwZgYJKoZIhvcNAQkOMVkwVzBVBgNVHREBAf8ESzBJoEcG
CCsGAQUFBwgKoDsWOXJmYzg5OTQrZmQ3MzlmYzIzYzM0NDAx
MTIyMzM0NDU1MDAwMDAwMDArQGFjcC5leGFtcGxlLmNvbQ==
]]></sourcecode>
MTIyMzM0NDU1MDAwMDAwMDArQGFjcC5leGFtcGxlLmNvbQ==]]></sourcecode>
        </section>
        <section anchor="asn1-dump-output">
          <name>ASN.1 DUMP output</name> Output</name>
          <t>There is a single subjectAltName Extension with an Attribute with Extension type.</t>
          <artwork><![CDATA[
          <sourcecode type="asn.1"><![CDATA[
    <30 68>
  0 104: SEQUENCE {
    <30 66>
  2 102:   SEQUENCE {
    <06 09>
  4   9:     OBJECT IDENTIFIER
       :       extensionRequest (1 2 840 113549 1 9 14)
       :       (PKCS #9 via CRMF)
    <31 59>
 15  89:     SET {
    <30 57>
 17  87:       SEQUENCE {
    <30 55>
 19  85:         SEQUENCE {
    <06 03>
 21   3:           OBJECT IDENTIFIER
       :             subjectAltName (2 5 29 17)
       :             (X.509 extension)
    <01 01>
 26   1:           BOOLEAN TRUE
    <04 4B>
 29  75:           OCTET STRING, encapsulates {
    <30 49>
 31  73:             SEQUENCE {
    <A0 47>
 33  71:               [0] {
    <06 08>
 35   8:                 OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 10'
    <A0 3B>
 45  59:                 [0] {
    <16 39>
 47  57:                   IA5String
       :                   'rfc8994+fd739fc23c34401122334455'
       :                   '00000000+@acp.example.com'
       :                   }
       :                 }
       :               }
       :             }
       :           }
       :         }
       :       }
       :     }
       :   }
]]></artwork>   }]]></sourcecode>
        </section>
      </section>
      <section anchor="rfc7030-original-example">
        <name>RFC7030 original example</name>
        <name>Original Example in RFC 7030</name>
        <t>In this example, taken from <xref section="4.5.2" sectionFormat="comma" sectionFormat="of" target="RFC7030"/>, a few different attributes are included.
The original encoding of the '<tt>macAddress</tt>' part in the example is NOT CORRECT.
It was not aligned with the definition of the Extension Request attribute as specified in <xref section="5.4.2" sectionFormat="of" target="RFC2985"/>.
The revised encoding given here does not use an '<tt>id-ExtensionReq</tt>' attribute
because the MAC Address is not an X.509 certificate extension by itself
and because the server provides its OID without a value,
which is not allowed syntactically within a structure of type '<tt>Extension</tt>'.</t>
        <section anchor="base64-encoded-example-1">
          <name>Base64 encoded example</name>
          <name>Base64-Encoded Example</name>
          <t>The Base64:</t>
          <sourcecode type="base64" markers="false"><![CDATA[
MDIGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgcr
BgEBAQEWBggqhkjOPQQDAw==
]]></sourcecode>
BgEBAQEWBggqhkjOPQQDAw==]]></sourcecode>
        </section>
        <section anchor="asn1-dump-output-1">
          <name>ASN.1 DUMP output</name> Output</name>
          <t>The CsrAttrs structure contains:</t>
          <ol spacing="normal" type="1"><li>
              <t>The challengePassword attribute is included to indicate that the
CSR should include this value.</t>
            </li>
            <li>
              <t>An ecPublicKey OID is provided with the value secp384r1 to
indicate what kind of public key should be submitted.</t>
            </li>
            <li>
              <t>The  macAddress OID 1.3.6.1.1.1.1.22 is included to
indicate that the CSR is expected to include
(in a subjectDirectoryAttributes extension) a MAC address value.</t>
            </li>
            <li>
              <t>The ecdsaWithSHA384 OID is included to indicate what kind of hash
is expected to be used for the self-signature in the PKCS#10 CSR.</t>
            </li>
          </ol>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
    <30 32>
  0  50: SEQUENCE {
    <06 09>
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
       :     (PKCS #9)
    <30 12>
 13  18:   SEQUENCE {
    <06 07>
 15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
       :       (ANSI X9.62 public key type)
    <31 07>
 24   7:     SET {
    <06 05>
 26   5:       OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
       :         (SECG (Certicom) named elliptic curve)
       :       }
       :     }
    <06 07>
 33   7:   OBJECT IDENTIFIER '1 3 6 1 1 1 1 22'
    <06 08>
 42   8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
       :     (ANSI X9.62 ECDSA algorithm with SHA384)
       :   }
]]></artwork>   }]]></sourcecode>
        </section>
      </section>
      <section anchor="require-a-specific-subjectaltname-extension">
        <name>Require a specific Specific subjectAltName extension</name> Extension</name>
        <t>This example is the same as the previous one except that instead of the OID
for a macAddress, a subjectAltName is specified as the only Extension element.</t>
        <section anchor="base64-encoded-example-2">
          <name>Base64 encoded example</name>
          <name>Base64-Encoded Example</name>
          <t>The Base64:</t>
          <sourcecode type="base64" markers="false"><![CDATA[
MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq
hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=
]]></sourcecode>
hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=]]></sourcecode>
        </section>
        <section anchor="asn1-dump-output-2">
          <name>ASN.1 DUMP output</name> Output</name>
          <t>The CsrAttrs structure contains:</t>
          <ol spacing="normal" type="1"><li>
              <t>The challengePassword attribute is included to indicate that the CSR should include this value.</t>
            </li>
            <li>
              <t>An ecPublicKey OID is provided with the value secp521r1 to indicate what kind of public key should be submitted.</t>
            </li>
            <li>
              <t>An extensionRequest container with a subjectAltName value containing the name potato@example.com</t> potato@example.com.</t>
            </li>
            <li>
              <t>The ecdsaWithSHA512 OID is included to indicate the SHA-512 hash is expected to be used for the self-signature in the PKCS#10 CSR.</t>
            </li>
          </ol>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
    <30 45>
  0  69: SEQUENCE {
    <06 09>
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
       :     (PKCS #9)
    <30 12>
 13  18:   SEQUENCE {
    <06 07>
 15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
       :       (ANSI X9.62 public key type)
    <31 07>
 24   7:     SET {
    <06 05>
 26   5:       OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
       :         (SECG (Certicom) named elliptic curve)
       :       }
       :     }
    <06 09>
 33   9:   OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)
       :     (PKCS #9 via PKCS #12)
    <06 0A>
 44  10:   OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
    <06 03>
 56   3:   OBJECT IDENTIFIER serialNumber (2 5 4 5)
       :     (X.520 DN component)
    <06 08>
 61   8:   OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
       :     (ANSI X9.62 ECDSA algorithm with SHA512)
       :   }
]]></artwork>   }]]></sourcecode>
        </section>
      </section>
      <section anchor="require-a-public-key-of-a-specific-size">
        <name>Require a public key Public Key of a specific size</name>
        <t>(RFC-editor please remove: Example ref Harkins01)</t> Specific Size</name>
        <t>The CSR requires an RSA public key of a specific size.</t>
        <section anchor="base64-encoded-example-3">
          <name>Base64 encoded example</name>
          <name>Base64-Encoded Example</name>
          <t>The Base64:</t>
          <sourcecode type="base64" markers="false"><![CDATA[
MCkGCSqGSIb3DQEJBzARBgkqhkiG9w0BAQExBAICEAAGCSqG
SIb3DQEBCw==
]]></sourcecode>
SIb3DQEBCw==]]></sourcecode>
        </section>
        <section anchor="asn1-dump-output-3">
          <name>ASN.1 DUMP output</name> Output</name>
          <t>Provide a CSR with an RSA key that's 4096 bits and use SHA256 as the hash algorithm within the signature.</t>
          <artwork><![CDATA[
          <sourcecode type="asn.1"><![CDATA[
    <30 29>
  0  41: SEQUENCE {
    <06 09>
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
       :     (PKCS #9)
    <30 11>
 13  17:   SEQUENCE {
    <06 09>
 15   9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
       :       (PKCS #1)
    <31 04>
 26   4:     SET {
    <02 02>
 28   2:       INTEGER 4096
       :       }
       :     }
    <06 09>
 32   9:   OBJECT IDENTIFIER sha256WithRSAEncryption
                             (1 2 840 113549 1 1 11)
       :     (PKCS #1)
       :   }
]]></artwork>   }]]></sourcecode>
        </section>
      </section>
      <section anchor="require-a-public-key-of-a-specific-curve">
        <name>Require a public key Public Key of a specific curve</name>
        <t>(RFC-editor please remove: Example ref Harkins02)</t> Specific Curve</name>
        <t>The CSR requires an ECC public key with a specific curve.</t>
        <section anchor="base64-encoded-example-4">
          <name>Base64 encoded example</name>
          <name>Base64-Encoded Example</name>
          <t>The Base64:</t>
          <sourcecode type="base64" markers="false"><![CDATA[
MC4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgNV
BAUGCCqGSM49BAMD
]]></sourcecode>
BAUGCCqGSM49BAMD]]></sourcecode>
        </section>
        <section anchor="asn1-dump-output-4">
          <name>ASN.1 DUMP output</name> Output</name>
          <t>Provide a CSR with an ECC key from p384, include your serial number, and
use SHA384 as the hash algorithm within the signature.</t>
          <artwork><![CDATA[
          <sourcecode type="asn.1"><![CDATA[
    <30 2E>
  0  46: SEQUENCE {
    <06 09>
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
       :     (PKCS #9)
    <30 12>
 13  18:   SEQUENCE {
    <06 07>
 15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
       :       (ANSI X9.62 public key type)
    <31 07>
 24   7:     SET {
    <06 05>
 26   5:       OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
       :         (SECG (Certicom) named elliptic curve)
       :       }
       :     }
    <06 03>
 33   3:   OBJECT IDENTIFIER serialNumber (2 5 4 5)
       :     (X.520 DN component)
    <06 08>
 38   8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
       :     (ANSI X9.62 ECDSA algorithm with SHA384)
       :   }
]]></artwork>   }]]></sourcecode>
        </section>
      </section>
      <section anchor="require-specific-extensions-and-attributes">
        <name>Require specific extensions Specific Extensions and attributes</name>
        <t>(RFC-editor please remove: Example ref Harkins03)</t> Attributes</name>
        <t>The CSR is required to have an EC key, to include a serial number,
include a friendly name, include a favorite drink <xref target="favoritedrink"/> [OID 0.9.2342.19200300.100.1.5], and
use SHA512 as the hash algorithm within the signature.</t>
        <section anchor="base64-encoded-example-5">
          <name>Base64 encoded example</name>
          <name>Base64-Encoded Example</name>
          <t>The Base64:</t>
          <sourcecode type="base64" markers="false"><![CDATA[
MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq
hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=
]]></sourcecode>
hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=]]></sourcecode>
        </section>
        <section anchor="asn1-dump-output-5">
          <name>ASN.1 DUMP output</name> Output</name>
          <t>Provide a CSR with an EC key from sha521, sha521 and include your serial number,
friendly name, and favorite drink, and hash it with SHA512.</t>
          <artwork><![CDATA[
          <sourcecode type="asn.1"><![CDATA[
    <30 45>
  0  69: SEQUENCE {
    <06 09>
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
       :     (PKCS #9)
    <30 12>
 13  18:   SEQUENCE {
    <06 07>
 15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
       :       (ANSI X9.62 public key type)
    <31 07>
 24   7:     SET {
    <06 05>
 26   5:       OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
       :         (SECG (Certicom) named elliptic curve)
       :       }
       :     }
    <06 09>
 33   9:   OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)
       :     (PKCS #9 via PKCS #12)
    <06 0A>
 44  10:   OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
    <06 03>
 56   3:   OBJECT IDENTIFIER serialNumber (2 5 4 5)
       :     (X.520 DN component)
    <06 08>
 61   8:   OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
       :     (ANSI X9.62 ECDSA algorithm with SHA512)
       :   }
]]></artwork>   }]]></sourcecode>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations from EST <xref target="RFC7030"/> section 6 target="RFC7030" sectionFormat="comma" section="6"/> are unchanged.</t>
      <section anchor="identity-and-privacy-considerations">
        <name>Identity and Privacy Considerations</name>
        <t>An EST server may use this mechanism to instruct the EST client about the identities it should include in the CSR it sends as part of enrollment.
The client may only be aware of its IDevID Initial Device
   Identifier (IDevID) Subject, which includes a manufacturer serial number.
The EST server can use this mechanism to tell the client to include a specific fully qualified domain name in the CSR in order to complete domain ownership proofs required by the CA.
Additionally, the EST server may deem the manufacturer serial number in an IDevID as personally identifiable information, information and may want to specify a new random opaque identifier that the pledge should use in its CSR.
This may be desirable if the CA and EST server have different operators.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is asked to allocate three new Object Identifiers:</t>
      <ul spacing="normal">
        <li>
          <t>One (TBD1) from the SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) registry for
<t>
For the ASN.1 module: id-mod-critemplate; see module in <xref target="app-asn1-module"/></t>
        </li>
        <li>
          <t>One (TBD2) from target="app-asn1-module"/>, IANA has assigned the SMI following OID in the "SMI Security for S/MIME Attributes
(1.2.840.113549.1.9.16.2) registry for Module Identifier (1.2.840.113549.1.9.16.0)" registry:
</t>

<table anchor="table_1">
  <thead>
    <tr>
      <th>Decimal</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>82</td>
      <td>id-mod-critemplate</td>
      <td>RFC 9908</td>
    </tr>
  </tbody>
</table>

<t>
For the Certification Request Information Template (id-aa-certificationRequestInfoTemplate) attribute; see and Extension Request Template attributes in <xref target="app-asn1-module"/></t>
        </li>
        <li>
          <t>One (TBD3) SMI target="app-asn1-module"/>, IANA has assigned the following OIDs in the "SMI Security for S/MIME Attributes
(1.2.840.113549.1.9.16.2) registry for the extension request
template (id-aa-extensionReqTemplate) attribute; see Appendix A</t>
        </li>
      </ul> (1.2.840.113549.1.9.16.2)" registry:
</t>

<table anchor="table_2">
  <thead>
    <tr>
      <th>Decimal</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>61</td>
      <td>id-aa-certificationRequestInfoTemplate</td>
      <td>RFC 9908</td>
    </tr>
     <tr>
      <td>62</td>
      <td>id-aa-extensionReqTemplate</td>
      <td>RFC 9908</td>
     </tr>
  </tbody>
</table>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Corey Bonnell crafted example02 using a different tool,
  </middle>
  <back>

<!-- [rfced] Informative reference RFC 9480 has been obsoleted by RFCs
9810 and this helped debug other running code.</t>
      <t>Carl Wallace provided major parts of the CertificationRequestInfoTemplate syntax declaration.</t>
      <t>Russ Housley did many reviews of the ASN.1 9811. We recommend replacing RFC 9480 with RFCs 9810 and suggested many fixes.</t>
      <t>Deb Cooley did
9811. However, if RFC 9480 must be referenced, we suggest
mentioning RFCs 9810 and 9811 (e.g., RFC 9480 has been obsoleted
by RFCs 9810 and 9811).  See Section 4.8.6 in the usual Area Director Review.</t>
    </section>
  </middle>
  <back> RFC Style Guide
(RFC 7322).
-->

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC5911">
          <front>
            <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <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 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="5911"/>
          <seriesInfo name="DOI" value="10.17487/RFC5911"/>
        </reference>
        <reference anchor="RFC5912">
          <front>
            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <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>
        <reference anchor="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 fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="July" year="2011"/>
            <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">
          <front>
            <title>Enrollment over Secure Transport</title>
            <author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin"/>
            <author fullname="P. Yee" initials="P." role="editor" surname="Yee"/>
            <author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/>
            <date month="October" year="2013"/>
            <abstract>
              <t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7030"/>
          <seriesInfo name="DOI" value="10.17487/RFC7030"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
        <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680">
          <front>
            <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>
        <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-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="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1:2021"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9148">
          <front>
            <title>EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol</title>
            <author fullname="P. van der Stok" initials="P." surname="van der Stok"/>
            <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="S. Raza" initials="S." surname="Raza"/>
            <date month="April" year="2022"/>
            <abstract>
              <t>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9148"/>
          <seriesInfo name="DOI" value="10.17487/RFC9148"/>
        </reference>
        <reference anchor="RFC2986">
          <front>
            <title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
            <author fullname="M. Nystrom" initials="M." surname="Nystrom"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <date month="November" year="2000"/>
            <abstract>
              <t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2986"/>
          <seriesInfo name="DOI" value="10.17487/RFC2986"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9148.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2985.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8295.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9480.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9483.xml"/>
        <reference anchor="RFC2985">
          <front>
            <title>PKCS #9: Selected Object Classes and Attribute Types Version 2.0</title>
            <author fullname="M. Nystrom" initials="M." surname="Nystrom"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <date month="November" year="2000"/>
            <abstract>
              <t>This memo represents a republication of PKCS #9 v2.0 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 that specification. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2985"/>
          <seriesInfo name="DOI" value="10.17487/RFC2985"/>
        </reference>
        <reference anchor="RFC4211"> anchor="dumpasn1" target="https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
            <title>Dump ASN</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/> initials="P." surname="Gutmann" fullname="Peter Gutmann">
              <organization/>
            </author>
            <date month="September" year="2005"/>
            <abstract>
              <t>This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]</t>
            </abstract> day="22" month="4" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="4211"/>
          <seriesInfo name="DOI" value="10.17487/RFC4211"/>
        </reference>

        <reference anchor="RFC5272"> anchor="favoritedrink" target="https://oid-base.com/get/0.9.2342.19200300.100.1.5">
          <front>
            <title>Certificate Management over CMS (CMC)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="M. Myers" initials="M." surname="Myers"/>
            <title>drink(5) [other identifier: favouriteDrink]</title>
            <author>
              <organization>OID Repository</organization>
            </author>
            <date month="June" year="2008"/>
            <abstract>
              <t>This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</t>
              <t>1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t>
              <t>2. 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> day="4" month="July" year="2019"/>
          </front>
          <seriesInfo name="RFC" value="5272"/>
          <seriesInfo name="DOI" value="10.17487/RFC5272"/>
          <refcontent>OID 0.9.2342.19200300.100.1.5</refcontent>
        </reference>
        <reference anchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined.
      </references>
    </references>

    <section anchor="app-asn1-module">
      <name>ASN.1 Module</name>
<!--[rfced] Does Appendix A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An provide the ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC8295">
          <front>
            <title>EST (Enrollment over Secure Transport) Extensions</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2018"/>
            <abstract>
              <t>The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8295"/>
          <seriesInfo name="DOI" value="10.17487/RFC8295"/>
        </reference>
        <reference anchor="RFC8368">
          <front>
            <title>Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)</title>
            <author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/>
            <author fullname="M. Behringer" initials="M." surname="Behringer"/>
            <date month="May" year="2018"/>
            <abstract>
              <t>Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks Extension
Request Template attribute? Or is often subject to the problem of circular dependencies when relying on connectivity it provided by the network to be managed for the OAM purposes.</t>
              <t>Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.</t>
              <t>This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8368"/>
          <seriesInfo name="DOI" value="10.17487/RFC8368"/>
        </reference>
        <reference anchor="RFC8994">
          <front>
            <title>An Autonomic Control Plane (ACP)</title>
            <author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/>
            <author fullname="M. Behringer" initials="M." role="editor" surname="Behringer"/>
            <author fullname="S. Bjarnason" initials="S." surname="Bjarnason"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration.
Certification Request Information Template attribute only?

Original:
   This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that appendix provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8994"/>
          <seriesInfo name="DOI" value="10.17487/RFC8994"/>
        </reference>
        <reference anchor="RFC8995">
          <front>
            <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="T. Eckert" initials="T." surname="Eckert"/>
            <author fullname="M. Behringer" initials="M." surname="Behringer"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support ASN.1 module [X.680] for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8995"/>
          <seriesInfo name="DOI" value="10.17487/RFC8995"/>
        </reference>
        <reference anchor="RFC9480">
          <front>
            <title>Certificate Management Protocol (CMP) Updates</title>
            <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
            <author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/>
            <author fullname="J. Gray" initials="J." surname="Gray"/>
            <date month="November" year="2023"/>
            <abstract>
              <t>This document contains a set of updates to the syntax of Certificate Management Protocol (CMP) version 2 and its HTTP transfer mechanism. This document updates RFCs 4210, 5912, and 6712.</t>
              <t>The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments.</t>
              <t>CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue Certification
   Request Information Template attribute, and signal it follows the use of an explicit hash AlgorithmIdentifier
   conventions established in certConf messages, as far as needed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9480"/>
          <seriesInfo name="DOI" value="10.17487/RFC9480"/>
        </reference>
        <reference anchor="RFC9483">
          <front>
            <title>Lightweight Certificate Management Protocol (CMP) Profile</title>
            <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
            <author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/>
            <author fullname="S. Fries" initials="S." surname="Fries"/>
            <date month="November" year="2023"/>
            <abstract>
              <t>This document aims at simple, interoperable, [RFC5911], [RFC5912], and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. [RFC6268].

Perhaps:
   This is achieved by profiling the Certificate Management Protocol (CMP), appendix provides an ASN.1 module [X.680] for the related Certificate Certification
   Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed Information Template and self-contained way. To make secure certificate management for simple scenarios Extension Request Template
   attributes, and constrained devices as lightweight as possible, only it follows the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9483"/>
          <seriesInfo name="DOI" value="10.17487/RFC9483"/>
        </reference>
        <reference anchor="dumpasn1" target="https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c">
          <front>
            <title>Dump ASN</title>
            <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="favoritedrink" target="https://oid-base.com/get/0.9.2342.19200300.100.1.5">
          <front>
            <title>Favorite Drink: arbitrary OID</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
      </references>
    </references>
    <?line 861?>

<section anchor="app-asn1-module">
      <name>ASN.1 Module</name>
      <aside>
        <t>RFC EDITOR: Please replace TBD1, TBD2, conventions established in [RFC5911],
   [RFC5912], and TBD3 with the value assigned by IANA
during the publication of this document.</t>
      </aside> [RFC6268].
-->

      <t>This appendix provides an ASN.1 module <xref target="X.680"/> for the Certification
Request Information Template attribute, and it follows the conventions
established in <xref target="RFC5911"/>, <xref target="RFC5912"/>, and <xref target="RFC6268"/>.</t>
      <sourcecode type="asn.1"><![CDATA[
CRITemplateModule
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) id-mod-critemplate(TBD1) id-mod-critemplate(82) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

IMPORTS -- from [RFC5912]

SupportedAttributes
 FROM PKIX1Explicit-2009
  { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}

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

PUBLIC-KEY, AlgorithmIdentifier{}
 FROM AlgorithmInformation-2009
  { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0)
    id-mod-algorithmInformation-02(58)}

CertExtensions
 FROM PKIX1Implicit-2009
  { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

Attributes{}, CRIAttributes, PKInfoAlgorithms
 FROM PKCS-10
  { iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7)
    id-mod(0) id-mod-pkcs10-2009(69) }
;

aa-certificationRequestInfoTemplate ATTRIBUTE ::=
  { TYPE CertificationRequestInfoTemplate IDENTIFIED BY
    id-aa-certificationRequestInfoTemplate }

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

--  like CertificationRequestInfo but OPTIONAL subject, subjectPKInfo
CertificationRequestInfoTemplate ::= SEQUENCE {
    version       INTEGER { v1(0) } (v1, ... ),
    subject       NameTemplate OPTIONAL,
    subjectPKInfo [0] SubjectPublicKeyInfoTemplate
                              {{ PKInfoAlgorithms }} OPTIONAL,
    attributes    [1] Attributes{{ CRIAttributes }}
}

--  like Name, but with OPTIONAL RDN values
NameTemplate ::= CHOICE { -- only one possibility for now --
    rdnSequence  RDNSequenceTemplate }

RDNSequenceTemplate ::= SEQUENCE OF RelativeDistinguishedNameTemplate

RelativeDistinguishedNameTemplate  ::= SET SIZE (1 .. MAX)
    OF SingleAttributeTemplate { {SupportedAttributes} }

--  like Attributes, but with OPTIONAL value
SingleAttributeTemplates{ATTRIBUTE:AttrSet} ::= SEQUENCE OF
    SingleAttributeTemplates{ {AttrSet} }

--  like SingleAttribute, but with OPTIONAL value
SingleAttributeTemplate{ATTRIBUTE:AttrSet} ::= SEQUENCE {
    type      ATTRIBUTE.&id({AttrSet}),
    value     ATTRIBUTE.&Type({AttrSet}{@type}) OPTIONAL
}

--  like SubjectPublicKeyInfo, but with OPTIONAL subjectPublicKey
SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE {
    algorithm        AlgorithmIdentifier{PUBLIC-KEY, {IOSet}},
    subjectPublicKey BIT STRING OPTIONAL
}

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

--  like extensionRequest, but with OPTIONAL Extension extnValues
--  original definition was in PKCS#9 RFC 2985 section 2985, Section 5.4.2
at-extensionReqTemplate ATTRIBUTE ::= {
    TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate }

ExtensionReqTemplate ::= ExtensionTemplates{{CertExtensions}}

--  like Extensions, but with OPTIONAL extnValue
ExtensionTemplates{EXTENSION:ExtensionSet} ::=
    SEQUENCE SIZE (1..MAX) OF ExtensionTemplate{{ExtensionSet}}

--  like Extension, but with OPTIONAL extnValue
ExtensionTemplate{EXTENSION:ExtensionSet} ::= SEQUENCE {
    extnID    EXTENSION.&id({ExtensionSet}),
    critical  BOOLEAN
  --                   (EXTENSION.&Critical({ExtensionSet}{@extnID}))
                     DEFAULT FALSE,
    extnValue OCTET STRING (CONTAINING
              EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL
              --  contains the DER encoding of the ASN.1 value
              --  corresponding to the extension type identified
              --  by extnID when present
}

END
]]></sourcecode>

END]]></sourcecode>

</section>

    <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t><contact fullname="Corey Bonnell"/> crafted Example 2 using a different tool, and
this helped debug other running code.</t>
      <t><contact fullname="Carl Wallace"/> provided major parts of the
CertificationRequestInfoTemplate syntax declaration.</t>
      <t><contact fullname="Russ Housley"/> conducted many reviews of the ASN.1 module and suggested many
fixes.</t>
      <t><contact fullname="Deb Cooley"/> conducted the usual Area Director Review.</t>
    </section>

<!--
Local IspellDict: american
LocalWords:  abbrev CSRAttrs docname ietf rfc csrattrs ipr wg pkcs
LocalWords:  submissionType kw std toc sortrefs symrefs org mcr
LocalWords:  seriesinfo bcp crypto [rfced] Please consider whether the "type" attribute of any
sourcecode element should be set and/or has been set correctly.

We note that "base64" was used as a sourcecode type; however, "base64"
is not on the list of preferred values. Please review and let us know
how we may update this.

The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->

<!-- [rfced] Regarding usage of <tt>, please review the occurrences
and let us know if any updates are needed for consistency. In the
HTML and PDF outputs, <tt> yields fixed-width font.  In the text
output, there is no change.

<tt>algorithm</tt>
<tt>attributes</tt>
<tt>BIT STRING</tt>
<tt>CertificationRequestInfo</tt>
<tt>CertificationRequestInfoTemplate</tt>
<tt>commonName</tt>
<tt>critical</tt>
<tt>CSRattrs</tt>
<tt>CsrAttrs</tt>
<tt>directoryName</tt>
<tt>ecPublicKey</tt>
<tt>Extension</tt>
<tt>ExtensionReq</tt>
<tt>Extensions</tt>
<tt>ExtensionTemplate</tt>
<tt>extKeyUsage</tt>
<tt>extnID</tt>
<tt>extnValue</tt>
<tt>GeneralName</tt>
<tt>id-aa-extensionReqTemplate</tt>
<tt>id-ExtensionReq</tt>
<tt>iPAddress</tt>
<tt>keyUsage</tt>
<tt>macAddress</tt>
<tt>NULL-DN</tt>
<tt>OCTET STRING</tt>
<tt>otherNames</tt>
<tt>pkcs-9-at-extensionRequest</tt>
<tt>publicKey</tt>
<tt>rsaEncryption</tt>
<tt>secp256r1</tt>
<tt>secp384r1</tt>
<tt>signature</tt>
<tt>SingleAttributeTemplate</tt>
<tt>subject</tt>
<tt>subjectAltName</tt>
<tt>subjectPKInfo</tt>
<tt>subjectPublicKey</tt>
<tt>SubjectPublicKeyInfoTemplate</tt>
<tt>type</tt>
<tt>value</tt>
<tt>values</tt>
<tt>version</tt>
-->

<!-- [rfced] Terminology

a) We note that the following terms are used inconsistently. Please
review the list below and let us know if any changes are needed.

  CSR Attribute(s) vs. CSR attribute(s)

  CsrAttrs AttrOrOID IOSet asn
LocalWords:  csrtemplate pKCS CertificationRequestInfoTemplate
LocalWords:  NameTemplate subjectPKInfo PKInfoAlgorithms br acp
LocalWords:  SubjectPublicKeyInfoTemplate AttrSet ExtensionSet
LocalWords:  SingleAttributeTemplate extensionReqTemplate secp
LocalWords:  ExtensionTemplate ExtnType myDept myGroup vs. CSRattrs
LocalWords:  publicKey dumpasn otherName acpNodeName otherNames
LocalWords:  AcpNodeName sourcecode csrattr ecdsaWithSHA sha
LocalWords:  harkins critemplate csrinfo Changelog markdown
LocalWords:  CRITemplateModule ExtensionReq
    [Note: Are these terms different or should one instance of
    "CSRattrs" be "CsrAttrs"?]
-->

</section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+1963LbxtLgfzzFHLlqRe4haV51S3K+UCSlMLEuFqlcTr7U
EgRAEhEIMAAoWlbp1L7IVu2z7KPsk2x3zxUgKMt28mXrVOg4JoHBTE9P36en
Ua1WrfsT1rKs1E8D74T1Ajv2Z75jp34UMjt0mRcu7NDxll6YsmjGbs56h/VW
nfVGN6ybprE/Xadewlxv5oc+PmTZ02nsQafQAhsklhs5ob2Ezt3YnqVV30tn
1cBerpJqPHOws6qTxDY2rTYBkiSFYf+HHUQhPJLGa8+y/FVMX5O0Wa8f15tW
sp4u/SSB4cYPK2g2HIzPLDv2bPgapl4ceqm1mZ+wN92L6xH7IYrv/HDOzuNo
vbLuNrpRtY8gWTDdE5akrrVeuTZM54QhWJXjRvvIslb+CYPPK+bYIVsnHrPj
2H5gJX/G7CBgD15SZlHMFnayYAsv9izG0sg5wRvwNYniNPZmyQl1AWiy10Ga
QAt5/2HJb+NPy16niyg+sarMD+HaRY3d+M7Cjt0EEMsYR+MFXvKC7K0ohumO
AHNesAQ4R9Es3QBCaO44jre0/eCELZ3477gAXyeyac2x4XYc4ep7rp9GsRz9
qsbOYt8L1MBXGy9Ul2jAnp84ke49muHNrx28WnOipeypX2P3QE5XC89fTlV3
/bjG+va972Zv8pn4SHEG4K53/7Xr3kc1XFrd7Tc2Lm2i+4S562vU1XjhwXq7
QDyxbwfsTbQO557R8YI3/zqgGzV4xrLCKF4CC9x7J9AQSL5z3Gjor03x9aB5
cCS+Ir3g1x9rB0f0BYjAjuce0NUiTVfJyevXm82m5qfrmh+mr2PPeT2u3gx6
VXqAt+cc+A/6wQDkGQcCcJN6ziKMgmj+wIBh+f3uFCZkOykbPYSp/Y5dRilv
fBV6rNQdXdYa5RPRdrTyHM3VwMVTO/EdFopHqJUkPfxe5Zgbjm+rY7qAXHHC
mvVmowrch1cSD5Y68QFIOQi1ZjcerDssnUs9nzA9P2gxuno9HPRO2NFRs11t
nGB/HGfHH4uz40/DGWIFJJoTuSgP4nWAvL6FnVPCzkA2u8FmrHQ6uClXREc9
O4xCeCLYatWDViQ3+36SwvW1nyw8d6tZH5r9wWg/LkJ7R6Ld8iWuFJE3j486
4mu7qem9edhUXzltw9ej5rFse9RSXHB0fNw+Yd3etfrZOWGnN6PvhvzCcVt1
AF9b+NVdL1d2Ejay679nEoCT1Oy1cxcAVmu2Uwvfv/7Xar5O6/XGa/l0zdkz
6WGvD9dxtfcKcMwFxd61ByqAna9TkIHhngU3Z/Z9FPup58Z+eLcDnsh3q8A8
Hkq313Drdb12XGu22s1a4xh0U6terzXwb62TBehM9A1CDzsHHTL1gX3jB3Y1
7MPoVrVaZbZgacsaL3zQqZGzJrUrtJKUMxWgJpDXAVfJ9zCLkeesQdaPYztM
VqBwWGkwGpcrzCFt/gB0Zy2iDUtBEva8OOXE7oGQnYc+EaX329pL4DHQ2WVT
rd940F8IOg9139RD9eey6QMQOIMRkBpxeFBmCfHQgzWN0gXZBrbshF1Nf/VA
TA37QPYwWc4ddpBEuXb3dgBAVIAw2coGIJ01QA+E3KkfM+9dCtoA2VO2Shd2
ShMSMHjvAAJUrHDJCXxEDYDlh06wdj34l4HJkOA04QaOG/Mp1yykRdDzDBEO
zHUPE5zF0VIjG8H1U7xPQPPFcGuWJU0hQjbdX079+TpaJzieD8AkeclCK5C1
nCSKa3zRwYwA2BIwEgAQ7Ga5Csj44n2Axg8CD/RUwuGSd8EAcaJwtkYc1awu
3BW9VHBMoI0N9Avynq1DmGKcgORagwEQk7GFJADAbRCl2E6AjZPMEiKnJxBA
NJGsHK3lqZbGBRnjcbyt4ghUPcLNQm/DkNL9+SKFBmCnAEGsoIHtLE6AxpBe
bRDgMDkkU2hCSIMJAhXQGgOgS7DBgCKJVAAnD2zmA2YIZ0CgmjLEHAgGaBdt
kp3UC6ABlRC1ZqX3JYgMkNmX5Rpn1KXvugHYpa/QkIwjd+2QGn2ebV/ItbSu
CtG7+fYPZ1tk2GdZtWYNTVatmOwYep5LVi6Mbk8Dz8RyMUvzVQVG+yAn0zAZ
boZl+SByHx/FOjw9CUQjq009L+TogY5ttgEKBXhAx6YPyBJAlYFg3+3pUo+o
8qBHRJT83YHfQOgOIMvDPoFQYQLoOaAYATkQuxz707UfuCxap7gw3XUahdES
DI9ehEQVsGvQeGjK9a7Lom/QtE9PMNkfFgD1NIpS5KLVCmkBkQItJbv7XAL8
tvZjT3AjYNcDBgMpAHMEyOYgCHDOgK0HJakkA3SDFIme5mzMsyLHyYo2ftkg
Ld8QIjjTpX1HVLhDBpb2XksXcK+Mgitaxw5MXffhh3oBK7i4JA2btYOnpzIO
ALLh3iM8S0gk6cBPUKlrEHjZqXGMKDqdR6B4kM6A8ojYYUHTBYhykKE+mEke
SBjVYBCiRQe6/YE5mi9hYQzBi1NNIhhnpwSvID04BErEAhSGTGg1QJ+hApGA
oDOSiwp7tsbelmgHUO15DDMDEYSLIzQYifb1HEZG3SLZbUOCHUkOrRGAZBee
YXq7brHEfkiYUsk5+PZQCgnxz2zXpTCBHVicR1ZogTLftNxlPwZBQRc4Rdtx
vCTBNfCC2Z4Q7fAfCROX05piPSk6s90oSHJixwV/MHQTKS5xMWdoISYobHGB
AU0uOLZrCjvQ2ikB4qItufRDgVbAk0RPu9YxoiaIqYxJgHyynsFPpFVYNtfH
H0A9Fkwk9myXS2BlV5AghLFWsSeIxckEbKA/pGgOPsjtStFqAky1JoCSw5sw
FgllBqt677gqFM5Twr3Nx0dy7J6e6MtxnciDVsNB8ZtQaAR6EWZKwmZrJMup
7dyRugfzeQUgo2bY+KB71CjwDJqAKOzxJ5ALsFPiKdrnDAuwPSN9a6iZx7Qi
5AAiZB67A/mwAdkLBHlxOxrvVfi/7PKKvt8M3t4ObwZ9/D76pvvmjfpiiRaj
b65u3/T1N/1k7+riYnDZ5w/DVZa5ZO1ddH/a42y4d3U9Hl5ddt/scU1m2gsY
ruEaU60xrIydWJKiSQye9q7/z/9utGG+f0OfrdE4BgTwH0eNQ8TGBrQDHy0K
Aef8J+DuwQJd4YFAQVUHy+PYKz8F7Q5tgQyBW0KKX9WsL/8jAFpm1YP/+IeF
qMxJ62+g6wBtNOvVKzaQapyIE4Cg0BnwmxIPYCh7YMg5nrAPQNa4KN5ARNmr
BV9+vDOL0DqjdQayPLGsf8EHnShYPIy6aQCK5cmWDMFnXyBGKsCCoBZtbnFc
eK5vsy5vIDQxdlS66PbKkhzJNAj5Ms1wZoJXtN6pUdgpOzJ2Y5rCKHUdXOS8
KAJlE+y2f+S0YFU06LbW4Ny8GglDFrSdF4fk5nMzVtldNezoAuxzZFgikG0s
++AckMmJA6YPKzVTAY6LfazWUzCSiL/AUt8sfADJiR9WKRrcc3R7F8tEmkBo
zHM6CGZVlK12CnYaxVUK5gKIQAXhMDDmYALwrHGTIq6zdehsrbhAGwk4NCa5
gMPhkRnY3As9sDYMdVrjxPYCgibhyR5fSXvliQuXjHCUDovBM7YIkXMeRrp4
XjBDe84PCWcEnFkviSmgzk5OvmIjEFeDy96AjYb/HLBSvVa76P5YZldnNOpV
DOY7xjT0L3qq983VEJ4pRb7Lrk6/HfTG4JcPLsfDs+EAqElb+Ap09qS64b8f
WXc8vhme3o4HJ8OrEeihpyxAjyLsxDjBMN2+9t98t/RIDz2pUBqT1D8ajGky
pYYxF/0oBvrlw49fY9dg+T0RbrjiiTGgC6sGBLGwwb5yBXcQV02B16tRWIX1
rm7AJlYKyA/QioPH8eHUxhUC9fEd0DJaYIInN2hSQ78BSk/6wakc0SpNe+6X
7E8Qssk+eKNeQNpbRyr2J3ym6i5yGFpeNgrkEPzpFCHjfg0XKjlXiTvZnjku
0hpnHE1sxbCQsgPlMvHdqiJycCEnFYvPZiFEIEHJGrVm7ahdrzUarU77uNao
wd92zbqMUmE6+7x1gkIFnpys7pykely106pn9I4O6sSk/evveqNXx5z8MeKI
6npMPosEkLRWFHq5eYm5b2GRJBKyjCJR6kghFhCaSiMDPAHRt8dt8orFDX0U
FfyKBmPGCXiiJcKEVOUKxLlp4TWEhYfh0acnza+GJCEOyfOsQeeqqZV5MP+c
wVuA4xCogD7bnKyagd2QUpwaPqdXV28G3UvWH5x1b9+M2Vn3zWhQyfT4PS09
9NgbIzcC812eqwbmp1qVCOZU0B/c6HgQ145cJNJi7e4ijilUQY8J500HBgj9
oCjDlJzAXb1MHwQ2VAMhFrqhgUpk+NhPROwKOUiospzi1MOXeK8gqaIVNzEC
bh3vS6zuo1ypCF/Ry4c0eAeEUgwcmdAkGP9aO6T6hCwhj93kfUGPiSJE9XTF
koarMguWGGcDtgxN4uZUb5u+JJ+SDCGQ16hMaxlwowC3jshxYxv0nbz/9FSx
RCxHPmpGGmakpU2jYGZqbZwKMZ2BVIqV+u89brRiBIMMxCW6VYliSBenZirG
oZi8yddaUSnDkotBIS2mnoQZSUBPw8pbOAC5Nq8mnnNNEwLFMEEzZAJ+9iAk
KwcmMakViyaw+xFwwFv6wI04YU6FERguMU3UQB0sdSjHrllXeHsDFEu+Zkam
JWsw3NF3MrAkDSse1kG842xgpbRVBdMMvBTGQIko+jKxwfl20BPWlpo82D6r
1lE7bkwsHmeWDwobeA7T4BQvgbgZdQkEWlTZT7t+fFCzLuwQ+dXGqIiEGmk/
lqBTqEc24M7cK3ZLsVRhkfF9ecS4DLHCdbSppEs1/mY4QssNUMujIauVcIRE
dLkXda85UlIVICQTzXC0uE+FY5GKEl0aUW3XTXKOi/ZqbIodFDk8lvRdsWdt
+zVIc3xpJ+gYLO34zgV/7Ku9aRA5d3v/wL0GNugPx1c3J+wazJAEeY57VRIy
Re/4I1wvpwCAQq90MsG5e01jgGc3mUwsxBrFSyVGciE3jQIeC/UM+8qiYNHf
dGxDbI2gQBZA1axvUJxVyN8EvAHu4GeSCTOhwZsfCtGbJACxa7KNZT5TNBjO
iKiFhy/QBpdCK+E2u5JhGB9RnlGgIofrUAlmlwvXRGzdZINa1odCk9KWp1VB
+Rb4S5+HABMjqAN6BHezHh+74JrDNN+xU2FN4A6rEUimXQslkrnQtjMzrKGG
ETYkXo+4A0iWMcwHzS8CBsPbGEsiEZXIbZNoLWwhLn7FzY3tp0I1gxxTOywU
FiYjUEJUQZEPlt3hdf/WsMSEekJGO1sDCVx/N2R9O7XlXg6XuIQ+3Gd+ehLm
mE2BcoTa6EISCViNGHOkOaKqMbdG5JbIBXjp9txjZxQRYKXezcVZmfH4AFKN
2P6zSsghrgcCDTzuxBOwYGIHjCDWMmEdHOi4gpFddCeJYlClY6qFG9sbDGtx
CsqgROtd3J4SopHcdl84FhQgXocYcLQEyhf2vQ4DcSf7Cx01BGlWEca9cp61
JRxaMvyKETf7Ti45Ohekg8BcQcsDlhQNEhDPSx+tAlAhi8g145nKXO9dXAvh
mwix1UYr15I2zxuMW288il5jW5g7kImn2rZMlmjVWmg8FFGv6SGT/wwLxjvB
XASUwG/8Ox6HUFyAAg06RiFAIhl3hdGT47NxI4/HxaE1mOwYXfXAEOYImSZI
fTdewCMjRdt9N/3LstxuRugwVh6tA5fbuQTKkq6H0Aj8aY5hjl1w1DD8qk1i
ZF4+JiwcD81og2JfaE870Ss1OR1KA3xCyNY9FO6fZR827feJRX6mTV4qCFXc
MUAcIKQYICIzHUiVLwqM5HocaO5wJZrEuZa27yPfpcCkEaIgDzwb2+arKfd7
i5jUTNcZKzqQwsNCMpjIoMeElWBAw0JQARjcABL+KEaKQ74dbNmFW8PkfTZ4
+uLSD9fCh5WsxDa4n+bFOvqo4db+LMKt4C2MfWAInPw3+gwvx4NzcJAe2X2j
VC+zJ1a6b1RYrVZjKgwiN575BylQjSBDxrmmIEsBDvZz/RcZ7FMUZQJY6DWZ
n8dHxrvq6mAdCL/8qEZ8AT4/N34xwlvQRe9maIS7QEAIL+xfuGsEOK1imk51
GbnrABwI7TyiYcDlr/DvP4hwJ4gS1NggjL3lNBAO3a7HLErm4BrmuNHU0qgj
XfXnVrlodV+ytrC0YmW31zVzXSxi0QIWrwt/OrcY9ZcvRkG4HTedhGEGa/Df
GXdlBIBKuSjlsLRB+E0keYDrM9QxkxUuCkZeZ2YyANmpKJ4eCr0dELSJcsYF
ujBJ6wsr2naBKJ8gIUsWQJUCPCO/EckJye+krGNhufkIWYY44EYm6V3wy0ia
miExmjSoG9+7F1kULol0jQJpPAr/z4xMTUbkdKnVkFSMaJs9E6tW2xshooe7
0LjVjN4f2UzKOcO8vyjEOU8qFvfFpZFCj24tzQ6EfMEUtouQPcysKMbVxMYL
yeREAiqwJ/SwHRq7wruD8tQ650D2Lyt6+Z95HkU7z91QTjH1xD1y4UYyAYIX
6nChDOgvyA3cQgcP2yoxRQkyqK2IUnGmGWWHjCNEyY4FZ486bI43MYxdrDtE
1JxtBc7lY0pn3ItoHduOk8u2KlIuiZVEgZAFOVbn0uYFDI9PZWPKwjIpZPsw
+qgYhyZVHVjbn6iNJLU+0gFLtvam7ih478fPU922qDMNMhGgj8SWAFLY5Dkt
O7F2oQsucttrnaxFsIu26aNUbdUP0TxLPBN3AmOJ3IlH9hIxFUSKSluROVUy
gsadA46hPOdTYpmKitPqLKIAc5GMYB2nKYFJcLt8dIRxaFLdYC9h7kq6yCwd
Bdm2kLgtryWHPIPHx+vb0zfDXvW7wU98d2kHkyh6kFaMUpJDGS+Ojb4qTOwc
PeWNKAkE0/Z2llckq3TJjMUwGW6g2HZml0ORgSLZGDUToE7vHug2KsRg+drp
2dAeCKd2FTd+ETPyFBjaNeEUhYThhSQLjTitMIeN3SQZD+Cbz1kX3xJJlJx/
TOVAq53fQyLE6LkrDaTJCcO+k+wzkkAo/442sjS0eZFRsBMGvj3PaNOu0Pae
DY/WFiyC0LBuNluUq9BioSFj7ehmZUaU8od7J6K/CQ+1a0W/P5HbBmpVMc9L
yjpjXJFeojMGs5sLQAobLwiMjk160X2ykt5ZCDY8Q8vjkoZCoVuY8kncuOUM
EgxgdHg573yKfGfaSaedBYWTItSLcSoF0IuEVS4ylAIIC7BjWEgF0MBVc2bK
6uXg67VBGgL9ntoUpfRzRo6OPBVMQ5vSsjutSkSOIUwIbAAaXWR5GpMtwrIi
MTbqXhrzEhs5eROnSHN8AGr2Eqh5wKHQgTYnYGRs7E9c4FYnjeIHMXFnEfmO
l99mmFzevnlT7V9OrJJf82oVHbMwt7646S5Mwf2Jf93leTe622xYKxvveNb8
FIiWZmNOXE3OKTUkoDkoLEvFtYVN9jj4cTy4HIEsPlE3dyotc8tWPcdNu8zD
0r576d7tro1bVupdXY67w8vCTVwDAhg95GZjBo7HrznET+WM+Zj7VKvs+a3g
VKXH7NgL5j183k4w9qH2gbl4E1LQUOJij47779n8AVj6DwUeJtk9uPsGA39f
JSVojzybcIGbtPKRJeYSozvyvAWhNxmQDbd6IVdkWwFj2xf2+0wmBQqNF3Vi
/VFJFoaHbH35t2rVGog9aAr96qjGwtjTzB9NUCJdsLglbBwAsgaUf08KJVrP
uSAUWVuGLca79tThGYTWmmY3mtUQAJry9jgbCsqrWdXqPyxrtF6toh3WfSZl
eoMySWD0BE3OYkddKgPu+FOkJG+8SRtkMKAMJHQqNxEeLrRD/70t0iXXoc/j
LMIO5KpRYGpv+dD3VukeT1pdPtDR6b2KAdVql7eEmoeyWGTuXo92k3uUEUhb
oA+sNOj1yjw5IBS7zbTL3OwcxI0JDUOjZBXTfl4j4qwA0Xgk8gtalP7liC48
0H1xKpjt4SnC5cOInwcCvPFpDa9FWxU+JmUiQxBwW6R70onu3AaYRgTM4hb3
miYmeLiDCy2lCEd8KMXLSdT155h9O1KhZwQJ+upi5v5SWj/GOND5d0VDaSN+
NxmgEhtLO2qnpDM8E1xM/iNvIVtEplNvO0Uxo+9kXBQPoeYUISb6ST+uIGtw
K5uJ6RAXKzVZh7VZq2zk+pj/fnTfWaa4BZ4wx2k09EC347OjEe3uKO74s4Hg
XLkDCvw/RoYl0nNwbENh5LiwUoM12VG7zhr1ersD3xUM288pxs0/1WINdlje
BqrxEUDtVkY7NzY0FJS6CEAcs/FpX9GMuTyFC7TjYuHcs2eKaMWaMORhOfug
YZZV0DqyV8lapCXk5rFjaPz83PylQJZtNzuEZtuXn6znfj99yuyl6NPz7mTn
Lc3W8c3t4FMRYgRmWmKvnNJ5tya4B1RXb+yd/v7zNESvmmort8Rmx/r7NkuK
3EQ8VhFV6dgLeT3ZUzDZM2OJZemTBEJbB97cdh6EV5NQphnqXz/kakC660bG
TDVJH4JchksA45HZJw2Y11yRYPg04WYb9kynFqRvaqYKMt5nLm8qkytI+jT0
NngGggNbs3oCah6f0AeRuW1LtqGcgBoJ41tcJYLG5KeKA5GsMgHryeabxDJp
smZdUWRT4oeUlngQu81uSe/YaRSd0XGigcxY0/mSUQwqHC0pdUhAZSY8vlIJ
bBY3YOVOBDdbF/58UQ28ey8AUwgsWD9ZlDHWFNihOiu+kVaJCEHVrBFmiyzF
gU+dc2ImPSISdc6rrsoDg06je482vWRaCQ/kY7LnQTvrtfHU7pAfCuLNonW6
WhOt7MmiC3uw1PI7P7WQcr9LBNboLB7u7PKpkBMuj3DbeM4IU7VuuClMAW5+
nus1HS/NylWesCBTSGnV6frjK9tZXUauh7+eeEoLOQS557W15OdS3JQLYeaW
6awDy87mk2KYc3/L+dqXKWpEGvmkcR2jJTwsKVcGDCgn9mQGmx2a59cAKXMf
j/bGyjS1E6pghLxkHnzr6tlz+HhCBYCocATuHWH6FZY1wZXm6SuupEjuC/J7
YkNc0IR1cT7f/HP+07ffRf8cLu6dy+7bu6uL7+82378//f50fvn9NzeD0+7s
aDB6f/ptNHDOrV4vOe++vT073cy/i/rJD1c/frv86f28czV+G/9z+bZ18T6A
38P3P72/qF/2u++si/Hw4YJ+3DYu+t2N+Bu/PT/71el1Au/8LHXO3wVvlpf3
07dffcUd+ccTxk8I40SqZGrHyVd7MxBT3p55C63/r/YAzSjnfKcKxFITeSP/
93/+ryeOFh6b6N9eXAsit8R5BN9wMHP0NMhF5sJ83vEgE7rQex+MfQly4uAI
K9agmdQ+yWshun+A98HoqjdPtvXUl/UDVj/GFm34dXxSrLSkCjoR/+YPZRSa
SY12Of9cCVNm2Ktjdu/blJVVFmA2WAeBaHQYOxJAaMsKZ9E5xNuHcPtQdlYw
104HWx1Dq45sVTzjFrRrNuBXS7d7wbz558N2WrZ9KbffICZdb7B6A+E4gF8N
85EtS+fLepu1T7EtzO2wk4H5Q8YP4qWNyAUks8NWFrQ8brrQFjHdakHbRrat
6QEQEpHwWrBi7CjfsMju2W+AyXUAlNGBP4fsCAhyXw3awsmBlQ9ksN2XMWzj
gLVwLm2ghM7hdlPwFbsd7tMUrwX/7MczB6Xe32fuYet45jRbTqvdrjcazWYL
vnQ6+88+XRefv3+NQkDIPrSfn33saffNnbd23Ci8XHBx61LuQubnkz63KKuM
KKtEyfehyIoXFyoste9AT+vEqMLMZczonYGVJLODUjP4tm1G6GFzod/9ydJ2
dPwe9xT0lha3iQA2DHD2rm5ugAApoUjWNADJPVeZy3xLWpo06tCtErVSsmmd
vZ3QrtK/au1aU6RaG8fQWOzd++hhqGnwsBgpBJVRSlUAw0JDQAdI5b4/wnjR
7TGBA7n5b8s9TaOChGGnTB/E8WQyws2+ZHaFrKeDG29olqhdpmwKkxxOZDpR
sNNJeSoxPcONIBX4kRHZfWP/7NMtiP7wvDf67Xw0nLb6bwffnr7vjk7nzm+L
u1+vrt8OTy/eOueno/Xpabfrw/XYOp2DSfF28MPpfC4avQWT4FMVvygvKeCs
N16q/PVR20xAjKKbMMMGP92tKnlc20mClQXMxPdE8Ufm4I8M+CITY8wXLGxM
Kda+lcyEAow3awwz+o2oDC4z7e8KCzsXUlTndGBIHECNSnYnGJAU4jeSPcTo
U7Jvln7K61q1+PSY5lsauFFr1Q5qDfGn2czNMTNgJq5dvI2O7UsicYt0c19u
IBqpi1r/QjtkInkAX+KozWH1HDexfwBsjL7pAgYkogqXIIMMPENOkGdhNJMS
OM+Zp9Wl/DKSifMWXqvJLTzWqW9beMp+azJhvxXEPLeIq8hey5sv0lgrK0Aa
CEgDTIPG0S5T8lBYcexwhyn5wsigNhm7l6Mh+/G4dtA0qQ3FijYeadhmWw9r
GI8IVUeaWcp0Ko48coIvoaXSaDUB5a1tGxZAGg16uCGKshaUfpk2BtxcfYGt
5wpVr8IZGlwc+GcsJ/6n2dzP2mBtXPqj4mfzxJzDeBt6buXX3cD4oNcfdY0E
KRISvKvyLttBOuG76kBpRhSp/obqJv4Qh8Dx+wpVKB4woh3Ad463SuWJniTF
kjZCb2OFAn5WVAuaihYHcuSMwy6GoFwnrfeNOM0nKanB7UuV1K+n87vfrMWd
f368qZ/2bt6e9+bL0bfRcnzkv7sD1/e827gdnL79aYg+8/tf64Pu5u2/nfL6
YzRXp9kgzfUZaqsbbru5Mocz1kk0GfriAOTSVGjbcIXlcaOvDV+hUN90Gs1n
9Q32B82q2I5KlvzeuqbdEbrm4PgvXfOH6hpOoqau6fwX6JpjqWt2LB8W3Q7d
4IFHNpCM+Mo0muXChWzWd6wkhXjUsxqALioswF6jvkPZ1bHXFug0WQQXFwzD
BobWw/BNB3HcKu4EKxvbwSU/tyx2PvPYxahMs876l1TNAfRLmJazevWg8TK9
isxYoFfzpsNL9GpH4uo5vbqzHAImbVtWCbzQKq++zlbyePcyuvdO5MYDnp6W
lc3rwAZc0otCtpRLIlLEnx3pk1Vk7y6vIm9QFUpNCC7bu9PusDfodqmdJRqe
9j7Vd1vIqb5I7V3LZFCRSMNjsjJjHvXWPq8/QDuHtEuC7jSsXhNoUlgVJJyz
6yurjUppnBe9zWMhetuNP1n0NqToPXwuYkyid1fEmGVqWhQA0iiSv0JeGMK2
LaVpe1vYgtBEJdE8gl9N2YfMFcEF+kix+Axqk4UNi4v8DnSg57UzbYBPp2jS
+Vln5/xJbE864KP5vrmD7we9njmUNHQyg2EK0CfyfvsjYjiX31unXbCne/DA
Rfv4tHvR/yz+b34G/yNaEB8U6URHsaLM1QcYT6gcUSuD7y0LqYBu12dIhYGU
Cgd/GWT/hs5/Sxpkf6gp00IZ+f9diECXZtTHiOi0gM5a/lip1jKkGlUroZH0
oVxek4jqMZmncHLsa9nKEKb1raj3OTB6oQN7fMy84OHpif3nz+i37XyDw3/+
kpEJaDJ+lEz4NwpGSGnc+ixprIUx6GbwpZ4Vx1ZuNZHIsivKr3GXOjXN8b8c
5D9LHv/lIBcC8JeDXKhV+EsasP5qD9QISIxYpjuOKQ4mbjqZm1yAZCroYll1
sa17QFvTqkQZzzHjR4JTfnT6OvbvMXMyP2Q3824MfLuIKk2w9LA7P1ly/cPD
qnzvWb9owJ7i5ite5OeUsLAXyqVcnFToCdJ1cNPDkvM2L/dPRR/Vayz4drTo
HMGhoDfm3dN73aAterLDvncPOkwcqVa1JHXZraUdrmc2RYFzEpYPkCuOXzxn
LEhtHqLLqmFpEfAS71hyjwfr3Qhr6vJYqjlt4w0YSKUBVsAWbaNNCHpo4a8w
UhzNDGNAnEHodWtWV5X8lsWwcgvnet6Sru+evDgjKtDHi7omshqlOGdGJy2N
ouJc3+AAG5sjQb83BvNJY7gNpBmt7N/Wxmm1WMfNYa7u3JMkIcoGq4OztLEi
XmtDJ+85AOKNGV2e26lnSraRzs7AGlc2WFwJpasOu5fdLRKnizyZkJtXmBQg
YtSxx5Ni5duaFPQJHUWil8qNT/uNMuc/CmpfDDUHo1Qdvb4YXgzYBRX5Mbqw
0K8uKCd8UKvj2z4o11Gfu+EGBa8UdIL5//C1igdpRFruF6JO21ZRIQPM5gvA
1NvMu+FrFsCXSRuWOScWK65mVeLnF5wPpBqXtf38kum1yr/7rHTmSaxmlOZm
UXQKYwtyVciwi3TYde7CaINkT2nZltWLYiy2EIUhyhQHX7+p7eJ6U1U21ISd
RlEgT4LjC7K8YIXCxZuu5yL/O16HtHODBitQf8+OA/YD0DZWx1Q7Tkv71ygW
Rb3lW2g+lAAuTga6Hr4bg1rha7/WScK+idZJ4OELO7BnKmx073ubJHvgFYHW
b1yhdjP/HR3A7HtT4M9I9oHPUIEQ1o09m8lcCCAv7Fa8dgpTvgmp1Llgs8dX
eUr5xDKiwNwV/H+TIxvJLL9NB9YvT8cCaYzCxHLXsdwy47al8aazHVVH+du4
JJHot4KFGcbXLxgp5jvrZTXk1LtvxEk1mYR+zysHJhZ0AVKWl/2ThTzxZZ+Y
/6aKhlEynHzFCK8NKVwMwEhYa1i9m6Ecm68KMM8jSNqoBPJy6aHCqU4j96EE
nLdOSsCRZQy2uolf4pxZZlg9vSSsd15JvQRXk6W/9EqNg7JAS4IlxrZFopDM
sPL9wdnwcohntUdseHH9Ztgbjtm4ez7CE+mWdTo4H16CIri4vroZj/DUNInJ
n8VEfxGnVWMgV1OQnN1cXWAxsh8bg3f4Qiw/reKLeM1Z6sPZVfM0WwlElRu5
pYMyf1tG6KXYWtp2JWHAKmsjgSswf/9d6VBO1Jgy3mhUPQlDvVnqNMqY9i/L
H1X0sXYD6mqPDhDiEffkzwOcA0FAH9JameVpisrXPIkp6Hua1v9rp0FtxFTs
ImhwUke4Esik+uiDSTnD5Z9POf7SoJxjohxdNg+YPFM3r7JVfk9NpzeqNuqf
PAeC25hH8RwMnGfm4SSNOuGwdHCMZPSFZb3AwNAVwkgQIOjjn64HH1aByj3s
s9OfJEwvGRCQ+8KW246oBPFTJCj9i8KTo1kJUNvGZ18GkjAhn1DtMhZg4dmd
FSKxwIusjiFzSyrZ8o7WpxQR/dgSoi8uIPq7lg99UfHQjy0d+mQZiKeSmaqM
jka1qjaYWJnJGq+5eUQFp94msorAehHve6EzidFGvhk6dsORLD+DHcsfJjEX
Xc4s29XZ7nKUCpvWB5sw0etYviUEFpnhe0IIUhhkZ4FB9ligvJ8yVGxKt22U
8vosO/pPPljA8OqMQNz5PFNVCTMw5dp/NGAvLKz40rKKn1RUMTOfAm4qmlS+
Ap31+XXxPrMq3otq4im5XuQN7pDlny/Ji+V4EQjCPzZXJJ8TWLQaRjapLKeU
UA/qYItx8mRDZb/lq4zQqcIjJCoISWdLrNyLkIo1sVg40sWDotYZ/fvMtHHC
hR3gIFvFdUDsZi21JxNf+nIRphR+rIJun6mHxYXDh1+BpEg+W42qEMCPhO9j
ynXpal0vqNWlS3WJc4AWL0m19SkZnfXEQ7vLbhUr34IaYLoE2AsLgP0u1b8+
s/TXZ9f9eqboF3LDpcg84WWk3kS4PsNk5QVB33fSEwZKN8b3uvJbP+CrQU9A
hk6nsXePEVmeRO1GDo9ge+mMxTOHycLzzF/FbDMnKZXtgrKS6TWxiFd2h287
x3irwxLQzrE3S1jysKR/wVtgSyfOPe9hRSOfrEtnJd+lqNK69Sv9+Pv37CQ3
BaP+Ar2U44NWfvbxjDWStRa3bL1pzGxnlX3+OT3GhA5lJq3lHt9h3xRKPdx0
zD6+XaRPEjjjVXuYqJvDZNWI7POqrhUTtQ2McgNGsQF9Nfe8eSRf76NLqsns
seE2ePZhsc/OjNgOPkmk0KMtrSCaq7he9tmtIFRGoVAtsv8HVsL4J++JAAA= [rfced] Abbreviations

a) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

b) We note the following instances in the running text.  If any
changes are needed for consistency, please let us know.

  EC key (2 instances)
  ECC key (2 instances)
  ECC public key (1 instance)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this
nature typically result in more precise language, which is
helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best a practice.
-->
  </back>

</rfc>