rfc9908.original.xml   rfc9908.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
8) --> -ietf-lamps-rfc7030-csrattrs-23" number="9908" category="std" consensus="true" s
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ubmissionType="IETF" updates="7030, 9148" obsoletes="" tocInclude="true" sortRef
-ietf-lamps-rfc7030-csrattrs-23" category="std" consensus="true" submissionType= s="true" symRefs="true" version="3" xml:lang="en">
"IETF" updates="70309148" tocInclude="true" sortRefs="true" symRefs="true" versi
on="3"> <!-- [rfced] We have updated the document title and short title that
<!-- xml2rfc v2v3 conversion 3.25.0 --> 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> <front>
<title abbrev="CSRAttrs">Clarification and enhancement of RFC7030 CSR Attrib <title abbrev="CSR Attributes">Clarification and Enhancement of the CSR Attr
utes definition</title> ibutes Definition in RFC 7030</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc7030-csrattrs-2 <seriesInfo name="RFC" value="9908"/>
3"/>
<author initials="M." surname="Richardson" fullname="Michael Richardson" rol e="editor"> <author initials="M." surname="Richardson" fullname="Michael Richardson" rol e="editor">
<organization>Sandelman Software Works</organization> <organization>Sandelman Software Works</organization>
<address> <address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
</address> </address>
</author> </author>
<author initials="O." surname="Friel" fullname="Owen Friel"> <author initials="O." surname="Friel" fullname="Owen Friel">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>ofriel@cisco.com</email> <email>ofriel@cisco.com</email>
skipping to change at line 39 skipping to change at line 59
<address> <address>
<email>dev@ddvo.net</email> <email>dev@ddvo.net</email>
</address> </address>
</author> </author>
<author initials="D." surname="Harkins" fullname="Dan Harkins"> <author initials="D." surname="Harkins" fullname="Dan Harkins">
<organization>The Industrial Lounge</organization> <organization>The Industrial Lounge</organization>
<address> <address>
<email>dharkins@lounge.org</email> <email>dharkins@lounge.org</email>
</address> </address>
</author> </author>
<date year="2025" month="June" day="28"/> <date year="2025" month="December"/>
<area>Internet</area> <area>SEC</area>
<workgroup>LAMPS Working Group</workgroup> <workgroup>lamps</workgroup>
<keyword>Internet-Draft</keyword>
<!-- [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> <abstract>
<?line 94?> <t>This document updates RFC 7030, "Enrollment over Secure Transport" (EST), cla
rifying
how the Certificate Signing Request (CSR) Attributes Response can be used by an
EST server to specify both CSR attribute Object Identifiers (OIDs) and CSR attri
bute values, particularly X.509 extension values, that the server expects the cl
ient to include in a subsequent CSR request.
RFC 9148 is derived from RFC 7030 and is also updated.</t>
<t>RFC 7030 is ambiguous in its specification of the CSR Attributes Respon
se.
<t>This document updates RFC7030, Enrollment over Secure Transport (EST), clarif <!--[rfced] May we combine these sentences as shown below to avoid the
ying repetition of "This has resulted in" and "As a result"?
how the Certificate Signiing Request (CSR) Attributes Response can be used by an
EST server to specify Original:
both CSR attribute Object IDs (OID) and also CSR attribute values, This has resulted in implementation challenges and implementor
in particular X.509 extension values, confusion. As a result, there was not universal
that the server expects the client to include in subsequent CSR request. understanding of what was specified.
RFC9148 is derived from RFC7030, and it is also updated.</t>
<t>RFC7030 (EST) is ambiguous in its specification of the CSR Attributes R Perhaps:
esponse. This has resulted in implementation challenges and implementor
This has resulted in implementation challenges and implementor confusion. confusion because there was no universal understanding of what
As a result, there was not universal understanding of what was specified. 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> This document clarifies the encoding rules.</t>
<t>This document therefore also provides a new straightforward approach: u sing <t>This document also provides a new straightforward approach: using
a template for CSR contents that may be partially filled in by the server. 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> This also allows an EST server to specify a subject Distinguished Name (DN).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 112?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document updates RFC7030 Enrollment over Secure Transport (EST) an <t>This document updates RFC 7030 and clarifies
d clarifies how the Certificate Signing Request (CSR) Attributes Response can be used by an
how the Certificate Signing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute OIDs and CSR attribute values.
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 tha t it expects the client to include in the subsequent CSR.</t> In particular, the server needs to be able to specify X.509 extension values tha t it expects the client to include in the subsequent CSR.</t>
<t>Enrollment over Secure Transport <xref target="RFC7030"/> (EST) has bee n used in a wide variety of applications. <t>"Enrollment over Secure Transport" <xref target="RFC7030"/> has been us ed 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 targe t="RFC8368"/>.</t> 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 targe t="RFC8368"/>.</t>
<t>When bootstrapping the ACP, there is a requirement that each node be gi <t>When bootstrapping the ACP, there is a requirement that each node be given a
ven a very specific subjectAltName. very specific subjectAltName.
In <xref target="RFC8994"/>, the ACP specification, the EST server is specified
to make use of the CSR Attributes ("/csrattrs") resource (specified in <xref sec <!--[rfced] We note that "CSR Attributes resource" is not present
tion="2.6" sectionFormat="comma" target="RFC7030"/>) to convey to the EST client in Section 2.6 or any other sections in RFC 7030. Was "CSR
the actual subjectAltName that needs to go Attributes Request" or "CSR Attributes Response" perhaps
into its CSR and thus ultimately into its End Entity certificate.</t> 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 sec
tion="2.6" sectionFormat="comma" target="RFC7030"/>) to convey the actual subjec
tAltName to the EST client that needs to go into its CSR and thus ultimately int
o its End Entity (EE) certificate.</t>
<t>As a result of some implementation challenges, it came to light that th is particular way of using the CSR attributes was not universally agreed upon, a nd it was suggested that it went contrary to <xref section="2.6" sectionFormat=" comma" target="RFC7030"/>.</t> <t>As a result of some implementation challenges, it came to light that th is particular way of using the CSR attributes was not universally agreed upon, a nd 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 <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". descriptive information that the EST server cannot access itself".
This is extended to describe how the EST server can provide values that it deman ds be used.</t> This is extended to describe how the EST server can provide values that it deman ds be used.</t>
<!-- DNE -->
<t>After significant discussion, it has been determined that <t>After significant discussion, it has been determined that
<xref section="4.5" sectionFormat="of" target="RFC7030"/> specification is suffi <xref section="4.5" sectionFormat="of" target="RFC7030"/> is sufficiently diffic
ciently difficult ult
to read and ambiguous to interpret that clarification is needed.</t> to read and ambiguous to interpret, so clarification is needed.</t>
<t>Also, <xref section="4.5.2" sectionFormat="comma" target="RFC7030"/> is <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"/> extended to clarify the use of the existing ASN.1 syntax <xref target="X.680"/>
<xref target="X.690"/>.</t> <xref target="X.690"/>.</t>
<t>This covers all uses and is fully backward compatible with existing use , <t>This covers all uses and is fully backward compatible with existing use ,
including addressesing the needs of <xref target="RFC8994"/> and <xref target="R FC8995"/>.</t> including addressing the needs of <xref target="RFC8994"/> and <xref target="RFC 8995"/>.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<?line -6?> be interpreted as
</t> described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="csr-attributes-handling"> <section anchor="csr-attributes-handling">
<name>CSR Attributes Handling</name> <name>CSR Attributes Handling</name>
<section anchor="extensions-to-rfc-7030-section-26"> <section anchor="extensions-to-rfc-7030-section-26">
<name>Extensions to RFC 7030 section 2.6</name> <name>Extensions to RFC 7030, Section 2.6</name>
<t>Replace the second paragraph with the following text:</t> <!-- [rfced] FYI - We have updated the sentence below. Please let us
<artwork><![CDATA[ know any objections.
These attributes can provide additional information that
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" se
ctionFormat="of" target="RFC7030"/> with the following text:</t>
<blockquote>These attributes can provide additional information that
the EST server cannot access itself, such as the Media Access Control 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 (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 also provide concrete values that it tells the client to include in
the CSR, such as a specific X.509 Subject Alternative Name extension. the CSR, such as a specific X.509 Subject Alternative Name extension.
Moreover, these attributes can indicate the type of the included Moreover, these attributes can indicate the type of the included
public key or which crypto algorithms to use for the self-signature, public key or which crypto algorithms to use for the self-signature,
such as a specific elliptic curve or a specific hash function that such as a specific elliptic curve or a specific hash function that
the client is expected to use when generating the CSR. the client is expected to use when generating the CSR.</blockquote>
]]></artwork>
</section> </section>
<section anchor="csrattrs"> <section anchor="csrattrs">
<name>Extensions to RFC 7030 section 4.5.2</name> <name>Extensions to RFC 7030, Section 4.5.2</name>
<t>The ASN.1 syntax for CSR Attributes as defined in EST <xref section=" <t>The ASN.1 syntax for CSR Attributes as defined in EST (<xref section=
4.5.2" sectionFormat="comma" target="RFC7030"/> is as follows:</t> "4.5.2" sectionFormat="comma" target="RFC7030"/>) is as follows:</t>
<artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
type ATTRIBUTE.&id({IOSet}), type ATTRIBUTE.&id({IOSet}),
values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }]]></sourcec
]]></artwork> ode>
<t>This remains unchanged, such that bits-on-the-wire compatibility is m aintained.</t> <t>This remains unchanged, such that bits-on-the-wire compatibility is m aintained.</t>
<t>Key parts that were unclear were which OID to use in the '<tt>type</t t>' field and <t>Key parts that were unclear were which OID to use in the '<tt>type</t t>' field and
that the '<tt>values</tt>' field can contain an entire sequence of X.509 extensi ons.</t> that the '<tt>values</tt>' field can contain an entire sequence of X.509 extensi ons.</t>
<t>The OID to use for such attributes in the '<tt>type</tt>' field MUST be <tt>id-ExtensionReq</tt>, <t>The OID to use for such attributes in the '<tt>type</tt>' field <bcp1 4>MUST</bcp14> be <tt>id-ExtensionReq</tt>,
which has the value 1.2.840.113549.1.9.14. which has the value 1.2.840.113549.1.9.14.
Note that is the same as <tt>pkcs-9-at-extensionRequest</tt> defined in PKCS#9 < Note that this is the same as <tt>pkcs-9-at-extensionRequest</tt> defined in PKC
xref target="RFC2985"/>. S#9 <xref target="RFC2985"/>.
There MUST be only one such attribute.</t> There <bcp14>MUST</bcp14> be only one such attribute.</t>
<t>The '<tt>values</tt>' field of this attribute MUST contain a set with <t>The '<tt>values</tt>' field of this attribute <bcp14>MUST</bcp14> con
exactly one element, tain a set with exactly one element,
and this element MUST be of type <tt>Extensions</tt>, as per <xref section="4.1" and this element <bcp14>MUST</bcp14> be of type <tt>Extensions</tt>, as per <xre
sectionFormat="of" target="RFC5280"/>:</t> f section="4.1" sectionFormat="of" target="RFC5280"/>:</t>
<artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE { Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE, critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value -- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified -- corresponding to the extension type identified
-- by extnID -- by extnID
} }]]></sourcecode>
]]></artwork>
<t>An Extension comprises the OID of the specific X.509 extension (extnI D), <t>An Extension comprises the OID of the specific X.509 extension (extnI D),
optionally the 'critical' bit, and the extension value (extnValue).</t> optionally the 'critical' bit, and the extension value (extnValue).</t>
<t>An Extensions structure, which is a sequence of elements of type Exte nsion, <t>An Extensions structure, which is a sequence of elements of type Exte nsion,
MUST NOT include more than one element with a particular extnID.</t> <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="csrtempla te"/>, <t>When not using the template-based approach of <xref target="csrtempla te"/>,
specifying the requirement for a public key of a specific type specifying the requirement for a public key of a specific type
and optionally its size and other parameters MUST be done as follows: and optionally its size and other parameters <bcp14>MUST</bcp14> be done as foll ows:
Include exactly one Attribute with the <tt>type</tt> field being the OID specify ing Include exactly one Attribute with the <tt>type</tt> field being the OID specify ing
the type of the key, such as <tt>ecPublicKey</tt> or <tt>rsaEncryption</tt>. the type of the key, such as <tt>ecPublicKey</tt> or <tt>rsaEncryption</tt>.
The '<tt>values</tt>' field MAY be empty to indicate no further requirements on The '<tt>values</tt>' field <bcp14>MAY</bcp14> be empty to indicate no further r
the key. equirements on the key.
Otherwise, it MUST contain suitable parameters for the given key type,
<!-- [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> 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. or containing an integer value for the RSA key size such as 4096.
Many examples for this are given in <xref target="examples"/>.</t> Many examples for this are given in <xref target="examples"/>.</t>
</section> </section>
<section anchor="update-to-rfc9148"> <section anchor="update-to-rfc9148">
<name>Update to RFC9148</name> <name>Update to RFC 9148</name>
<t>The updates to EST in this THISRFC equally apply when using <!-- [rfced] May we rephrase the sentence below as follows to clarify
CoAP as a transport as described in <xref target="RFC9148"/>. "transport"?
THISRFC therefore adds the following paragraph after the second paragraph
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 tar
get="RFC9148"/>.
This document therefore adds the following paragraph after the second paragraph
of <xref section="1" sectionFormat="comma" target="RFC9148"/>:</t> of <xref section="1" sectionFormat="comma" target="RFC9148"/>:</t>
<aside> <!-- [rfced] We will update the sentence below as follows if there are
<t>RFC EDITOR: Please replace THISRFC with the RFC number for this doc no objections.
ument.</t>
</aside> Original:
<t><tt> EST over CoAP as specified in {{RFC9148}} applies unchanged to
EST over CoAP as specified in {{RFC9148}} applies unchanged {{RFC7030}} updated by THISRFC. Hence, all references to {{RFC7030}} in
to {{RFC7030}} updated by THISRFC. {{RFC9148}} are assumed to indicate {{RFC7030}} updated by THISRFC.
Hence, all references to {{RFC7030}} in {{RFC9148}} are assumed to indicate
{{RFC7030}} updated by THISRFC. Perhaps:
</tt></t> 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"/> appli
es unchanged
to <xref target="RFC7030"/> updated by RFC 9908.
Hence, all references to <xref target="RFC7030"/> in <xref target="RFC9148"/> ar
e assumed to indicate
<xref target="RFC7030"/> updated by RFC 9908.</blockquote>
</section> </section>
<section anchor="csrtemplate"> <section anchor="csrtemplate">
<name>Use of CSR templates</name> <name>Use of CSR Templates</name>
<t>Alternatively to the unstructured inclusion of CSR attributes
specified in <xref section="4.5.2" sectionFormat="comma" target="RFC7030"/> with <!-- [rfced] We note that the following lines exceed the 72-character
its limitations and ambiguities, 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 2
0)
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="of" target="RFC7030"/> with it
s limitations and ambiguities,
<xref section="B" sectionFormat="of" target="RFC8295"/> describes an approach us ing a CSR template. <xref section="B" sectionFormat="of" target="RFC8295"/> describes an approach us ing a CSR template.
An entire CSR object is returned with various fields filled out, An entire CSR object is returned with various fields filled out and other fields
and other fields waiting to be filled in. 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 [RFC5272] and that in turn includes an [RFC2986] CSR
or a Certificate Request Message Format (CRMF) formatted request
(for details see [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 <xr ef target="RFC5272"/> In that approach, a pKCS7PDU attribute includes a Full PKI Data content type <xr ef target="RFC5272"/>
and that in turn includes an <xref target="RFC2986"/> CSR or a Certificate Reque and that, in turn, includes a CSR <xref target="RFC2986"/> or a Certificate Requ
st Message Format (CRMF) formatted request est Message Format (CRMF) formatted request
(for details see <xref target="RFC6268"/> Sections 5 or 9, respectively).</t> (for details, see Sections <xref target="RFC6268" sectionFormat="bare" section="
5"/> or <xref target="RFC6268" sectionFormat="bare" section="9"/> of <xref targe
t="RFC6268"/>, respectively).</t>
<t>One drawback to that approach, particularly for the CSR, is that some unused <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 fields have to be included; specifically, the '<tt>signature</tt>' field on
the CSR is faked with an empty bit string.</t> the CSR is faked with an empty bit string.</t>
<t>A similar method has been defined in CMP Updates <xref target="RFC948 <t>A similar method has been defined in "Certificate Management Protocol
0"/> (CMP) Updates" <xref target="RFC9480"/>
and the Lightweight CMP profile <xref section="4.3.3" sectionFormat="comma" targ and "Lightweight Certificate Management Protocol (CMP) Profile" (<xref section="
et="RFC9483"/>, 4.3.3" sectionFormat="comma" target="RFC9483"/>) using a CSR template as defined
using a CSR template as defined for CRMF <xref target="RFC4211"/>. for CRMF <xref target="RFC4211"/>.
Like the approach mentioned before, 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. this method does not properly deal with absent Relative Distinguished Name (RDN) values, as it would encode them as invalid empty strings.
Also encoding an absent '<tt>subjectPublicKey</tt>' value as an empty <tt>BIT ST RING</tt> Also, encoding an absent '<tt>subjectPublicKey</tt>' value as an empty <tt>BIT S TRING</tt>
and an absent X.509 extension value as an empty <tt>OCTET 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> can cause issues with strict ASN.1 parsing and decoding.</t>
<t>These drawbacks are avoided as follows:</t> <t>These drawbacks are avoided as follows:</t>
<t>This specification defines a new Certificate Request Information Temp late attribute <t>This specification defines a new Certificate Request Information Temp late attribute
for <tt>CsrAttrs</tt> (as given in <xref target="csrattrs"/>) that is essentiall y for <tt>CsrAttrs</tt> (as given in <xref target="csrattrs"/>) that is essentiall y
a partially filled in PKCS#10 CSR minus the signature wrapper:</t> a partially filled-in PKCS#10 CSR minus the signature wrapper:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
CertificationRequestInfoTemplate ::= SEQUENCE { CertificationRequestInfoTemplate ::= SEQUENCE {
version INTEGER { v1(0) } (v1, ... ), version INTEGER { v1(0) } (v1, ... ),
subject NameTemplate OPTIONAL, subject NameTemplate OPTIONAL,
subjectPKInfo [0] SubjectPublicKeyInfoTemplate subjectPKInfo [0] SubjectPublicKeyInfoTemplate
{{ PKInfoAlgorithms }} OPTIONAL, {{ PKInfoAlgorithms }} OPTIONAL,
attributes [1] Attributes{{ CRIAttributes }} attributes [1] Attributes{{ CRIAttributes }}
} }]]></sourcecode>
]]></artwork> <t><xref target="app-asn1-module"/> contains all details.</t>
<t><xref target="app-asn1-module"/> contains all detail.</t>
<t>The CertificationRequestInfoTemplate closely resembles the Certificat ionRequestInfo <t>The CertificationRequestInfoTemplate closely resembles the Certificat ionRequestInfo
from <xref section="5" sectionFormat="comma" target="RFC5912"/>:</t> from <xref section="5" sectionFormat="comma" target="RFC5912"/>:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
CertificationRequestInfo ::= SEQUENCE { CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...), version INTEGER { v1(0) } (v1,...),
subject Name, subject Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes [0] Attributes{{ CRIAttributes }} attributes [0] Attributes{{ CRIAttributes }}
} }]]></sourcecode>
]]></artwork> <t>with the following differences:</t>
<t>with the following differences.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The '<tt>subject</tt>' field has been made <tt>OPTIONAL</tt>. <t>The '<tt>subject</tt>' field has been made <tt><bcp14>OPTIONAL</b
It MUST be present if the server places any requirements on the RDNs of the subj cp14></tt>.
ect name; It <bcp14>MUST</bcp14> be present if the server places any requirements on the R
otherwise, it MUST be absent.</t> DNs of the subject name; otherwise, it <bcp14>MUST</bcp14> be absent.</t>
</li> </li>
<li> <li>
<t>RelativeDistinguishedNames (RDNs) in the '<tt>subject</tt>' field <t>RDNs in the '<tt>subject</tt>' fields are allowed to have no valu
s are allowed to have no value, e,
which has been achieved by adding <tt>OPTIONAL</tt> to the '<tt>value</tt>' fiel which has been achieved by adding <tt><bcp14>OPTIONAL</bcp14></tt> to the '<tt>v
d of <tt>SingleAttributeTemplate</tt>. alue</tt>' field of <tt>SingleAttributeTemplate</tt>.
If the client is expected to provide an RDN of a certain type such as <tt>common Name</tt>, If the client is expected to provide an RDN of a certain type such as <tt>common Name</tt>,
the respective RDN MUST be present in the '<tt>subject</tt>' field; otherwise it the respective RDN <bcp14>MUST</bcp14> be present in the '<tt>subject</tt>' fiel
MUST be absent. d; otherwise, it <bcp14>MUST</bcp14> be absent.
If the server in addition gives an RDN value, In addition, if the server gives an RDN value,
this means that the client is expected to use this value for the RDN, this means that the client is expected to use this value for the RDN; otherwise,
otherwise the client is expected to fill in a suitable value. the client is expected to fill in a suitable value.
The example at the end of this section has a '<tt>subject</tt>' field The example at the end of this section has a '<tt>subject</tt>' field
that contains both forms of RDN specifications.</t> that contains both forms of RDN specifications.</t>
</li> </li>
</ul> </ul>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
SingleAttributeTemplate {ATTRIBUTE:AttrSet} ::= SEQUENCE { SingleAttributeTemplate {ATTRIBUTE:AttrSet} ::= SEQUENCE {
type ATTRIBUTE.&id({AttrSet}), type ATTRIBUTE.&id({AttrSet}),
value ATTRIBUTE.&Type({AttrSet}{@type}) OPTIONAL value ATTRIBUTE.&Type({AttrSet}{@type}) OPTIONAL
} }]]></sourcecode>
]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The '<tt>subjectPKInfo</tt>' field has been made <tt>OPTIONAL</tt <t>The '<tt>subjectPKInfo</tt>' field has been made <tt><bcp14>OPTIO
>. NAL</bcp14></tt>.
The field MUST be absent if the server places no requirements on the key. The field <bcp14>MUST</bcp14> be absent if the server places no requirements on
Otherwise, it MUST be present, and the '<tt>algorithm</tt>' field the key; otherwise, it <bcp14>MUST</bcp14> be present, and the '<tt>algorithm</t
specifies the type of the key pair the client is expected to use.</t> t>' field
specifies the type of key pair the client is expected to use.</t>
</li> </li>
<li> <li>
<t>The '<tt>subjectPublicKey</tt>' field contained in <tt>SubjectPub licKeyInfoTemplate</tt> <t>The '<tt>subjectPublicKey</tt>' field contained in <tt>SubjectPub licKeyInfoTemplate</tt>
has been made <tt>OPTIONAL</tt> because usually it is not needed. has been made <tt><bcp14>OPTIONAL</bcp14></tt> because it is usually not needed.
In case the server requires use of an RSA key and needs to specify its size, the field In case the server requires use of an RSA key and needs to specify its size, the field
MUST be present and contain a placeholder public key value of the desired RSA mo <bcp14>MUST</bcp14> be present and contain a placeholder public key value of the
dulus length. desired RSA modulus length; otherwise, the <tt>subjectPublicKey</tt> <bcp14>MUS
Otherwise, the <tt>subjectPublicKey</tt> MUST be absent.</t> T</bcp14> be absent.</t>
</li> </li>
</ul> </ul>
<artwork><![CDATA[ <sourcecode><![CDATA[
SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE { SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE {
algorithm AlgorithmIdentifier{PUBLIC-KEY, {IOSet}}, algorithm AlgorithmIdentifier{PUBLIC-KEY, {IOSet}},
subjectPublicKey BIT STRING OPTIONAL subjectPublicKey BIT STRING OPTIONAL
} }]]></sourcecode>
]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A new OID <tt>id-aa-extensionReqTemplate</tt> and the related <tt >ExtensionTemplate</tt> structure <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>. is defined where the '<tt>extnValue</tt>' field has been made <tt><bcp14>OPTIONA L</bcp14></tt>.
This is only needed to enable specifying partial extensions with values to be fi lled in This is only needed to enable specifying partial extensions with values to be fi lled in
by the client; otherwise the <tt>id-ExtensionReq</tt> OID and the respective val by the client; otherwise, the <tt>id-ExtensionReq</tt> OID and the respective va
ue of type lue of type
<tt>ExtensionReq</tt> MUST be used for specifying requirements on X.509 extensio <tt>ExtensionReq</tt> <bcp14>MUST</bcp14> be used for specifying requirements on
ns.</t> X.509 extensions.</t>
</li> </li>
</ul> </ul>
<t>For each extension of type <tt>Extension</tt> or <tt>ExtensionTemplat e</tt> provided by the server, <t>For each extension of type <tt>Extension</tt> or <tt>ExtensionTemplat e</tt> provided by the server,
the client is expected to include an extension of the type given by the <tt>extn ID</tt>. the client is expected to include an extension of the type given by the <tt>extn ID</tt>.
If the '<tt>critical</tt>' field is present, the client SHOULD use it in the ext ension as well. If the '<tt>critical</tt>' field is present, the client <bcp14>SHOULD</bcp14> us e it in the extension as well.
If the '<tt>extnValue</tt>' is present (which is always the case when type <tt>E xtension</tt> is used), If the '<tt>extnValue</tt>' is present (which is always the case when type <tt>E xtension</tt> is used),
the client SHOULD use the given extension value in its CSR. the client <bcp14>SHOULD</bcp14> use the given extension value in its CSR.
When the type <tt>ExtensionTemplate</tt> is used, the '<tt>extnValue</tt>' can b When the type <tt>ExtensionTemplate</tt> is used, the '<tt>extnValue</tt>' can b
e absent, and then the client SHOULD provide an extension value in an <tt>Extens e absent, and then the client <bcp14>SHOULD</bcp14> provide an extension value i
ion</tt> with the given <tt>extnID</tt>. n an <tt>Extension</tt> with the given <tt>extnID</tt>.
For instance, if the server includes an <tt>ExtensionTemplate</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>, with the <tt>extnID</tt> '<tt>subjectAltName</tt>' but without an <tt>extnValue< /tt>,
the client SHOULD include a SAN extension with a suitable value.</t> the client <bcp14>SHOULD</bcp14> include a SAN extension with a suitable value.< /t>
<t>In case the server includes an <tt>ExtensionTemplate</tt> with the <t t>extnID</tt> '<tt>subjectAltName</tt>' <t>In case the server includes an <tt>ExtensionTemplate</tt> with the <t t>extnID</tt> '<tt>subjectAltName</tt>'
and a partially filled in <tt>extnValue</tt>, such as a '<tt>directoryName</tt>' choice containing the <tt>NULL-DN</tt> and a partially 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 emp ty <tt>OCTET STRING</tt>, (i.e., an empty sequence of RDNs) or the '<tt>iPAddress</tt>' choice with an emp ty <tt>OCTET STRING</tt>,
this means that the client SHOULD fill in the respective <tt>GeneralName</tt> va it means that the client <bcp14>SHOULD</bcp14> fill in the respective <tt>Genera
lue.</t> lName</tt> value.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
ExtensionTemplate {EXTENSION:ExtensionSet} ::= SEQUENCE { ExtensionTemplate {EXTENSION:ExtensionSet} ::= SEQUENCE {
extnID EXTENSION.&id({ExtensionSet}), extnID EXTENSION.&id({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE, critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING (CONTAINING extnValue OCTET STRING (CONTAINING
EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL
-- contains the DER encoding of the ASN.1 value -- contains the DER encoding of the ASN.1 value
-- corresponding to the extension type identified -- corresponding to the extension type identified
-- by extnID when present -- by extnID when present
} }]]></sourcecode>
]]></artwork> <t>The '<tt>version</tt>' field of the <tt>CertificationRequestInfoTempl
<t>The '<tt>version</tt>' field of the <tt>CertificationRequestInfoTempl ate</tt> <bcp14>MUST</bcp14> contain v1 (0).</t>
ate</tt> MUST contain v1 (0).</t> <t>The '<tt>attributes</tt>' field <bcp14>MUST NOT</bcp14> contain multi
<t>The '<tt>attributes</tt>' field MUST NOT contain multiple <tt>id-aa-e ple <tt>id-aa-extensionReqTemplate</tt> attributes
xtensionReqTemplate</tt> attributes and <bcp14>MUST NOT</bcp14> contain both <tt>id-ExtensionReq</tt> and <tt>id-aa-
and MUST NOT contain both <tt>id-ExtensionReq</tt> and <tt>id-aa-extensionReqTem extensionReqTemplate</tt> attributes.</t>
plate</tt> attributes.</t>
<t>The '<tt>values</tt>' field of an <tt>id-aa-extensionReqTemplate</tt> attribute <t>The '<tt>values</tt>' field of an <tt>id-aa-extensionReqTemplate</tt> attribute
MUST contain a set with exactly one element, <bcp14>MUST</bcp14> contain a set with exactly one element,
and this element MUST be of type <tt>ExtensionTemplate</tt>.</t> and this element <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 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 values set. Even though the syntax is defined as a set, there MUST
be exactly one instance of AttributeValue present. be exactly one instance of AttributeValue present.
--> -->
<t>Suppose the server requires that the CSR will contain:</t> <t>Suppose the server requires that the CSR will contain:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>the '<tt>subject</tt>' field with a common name to be filled in b y the EE and <t>the '<tt>subject</tt>' field with a common name to be filled in b y the EE and
two organizational unit names with given values "myDept" and "myGroup",</t> two organizational unit names with given values "myDept" and "myGroup",</t>
</li> </li>
<li> <li>
<t>the '<tt>publicKey</tt>' field contains an <t>the '<tt>publicKey</tt>' field with an
Elliptic Curve Cryptography (ECC) key on curve <tt>secp256r1</tt>,</t> Elliptic Curve Cryptography (ECC) key on curve <tt>secp256r1</tt>,</t>
</li> </li>
<li> <li>
<t>the 'subjectAltName' extension with two entries; one DNS entry wi th <t>the 'subjectAltName' extension with two entries; one DNS entry wi th
name "www.myServer.com" and IP entry that is empty for the IP address name "www.myServer.com" and IP entry that is empty for the IP address
to be filled in.</t> to be filled in,</t>
</li> </li>
<li> <li>
<t>the '<tt>keyUsage</tt>' extension marked critical <t>the '<tt>keyUsage</tt>' extension marked critical
with the value digitalSignature and keyAgreement, and</t> with the values digitalSignature and keyAgreement, and</t>
</li> </li>
<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 b y the EE.</t> <t>the '<tt>extKeyUsage</tt>' extension with value to be filled in b y the EE.</t>
</li> </li>
</ul> </ul>
<t>Then the <tt>CertificationRequestInfo</tt> structure constructed by t he server <t>Then, the <tt>CertificationRequestInfo</tt> structure constructed by the server
will be as follows:</t> will be as follows:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
SEQUENCE { SEQUENCE {
INTEGER 0 INTEGER 0
SEQUENCE { SEQUENCE {
SET { SET {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3) OBJECT IDENTIFIER commonName (2 5 4 3)
} }
} }
SET { SET {
SEQUENCE { SEQUENCE {
skipping to change at line 370 skipping to change at line 549
} }
[0] { [0] {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7)
} }
} }
[1] { [1] {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER id-aa-extensionReqTemplate OBJECT IDENTIFIER id-aa-extensionReqTemplate
(1 2 840 113549 1 9 TBD3) (1 2 840 113549 1 9 62)
SET { SET {
SEQUENCE { SEQUENCE {
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17) OBJECT IDENTIFIER subjectAltName (2 5 29 17)
OCTET STRING, encapsulates { OCTET STRING, encapsulates {
SEQUENCE { SEQUENCE {
[2] "www.myServer.com" [2] "www.myServer.com"
[7] "" [7] ""
} }
} }
skipping to change at line 397 skipping to change at line 576
"10001"B "10001"B
} }
} }
SEQUENCE { SEQUENCE {
OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
} }
} }
} }
} }
} }
} }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="co-existence-with-existing-implementations"> <section anchor="co-existence-with-existing-implementations">
<name>Co-existence with existing implementations</name> <name>Coexistence with Existing Implementations</name>
<t>EST servers with legacy clients MAY continue to use the <xref target="R <!-- [rfced] FYI: To avoid hyphenating an RFC number, we have updated
FC7030"/>-style unstructured list of attribute/value pairs, this sentence as shown below. Please see style guidance at
and MAY also include the template style described in <xref target="csrtemplate"/ <https://www.rfc-editor.org/styleguide/part2/#rfc_as_compound>.
> for newer clients.
Clients which understand both MUST use the template only, and Original:
EST servers with legacy clients MAY continue to use the [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 unstr
uctured list of attribute/value pairs as described in <xref target="RFC7030"/> a
nd <bcp14>MAY</bcp14> also include the template style described in <xref target=
"csrtemplate"/> for newer clients.
Clients that understand both <bcp14>MUST</bcp14> use the template only, and
ignore all other <tt>CSRattrs</tt> elements. ignore all other <tt>CSRattrs</tt> elements.
Older clients will ignore the new CertificationRequestInfoTemplate element.</t> Older clients will ignore the new CertificationRequestInfoTemplate element.</t>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples using the original RFC 7030 approach</name> <name>Examples Using the Original Approach in RFC 7030</name>
<t>Each example has a high-level (English) explanation of what is expected . <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. Some mapping back to the Attribute and Extension definitions above are included.
The base64 DER encoding is then shown. The base64 DER encoding is then shown.
The output of "dumpasn1" <xref target="dumpasn1"/> is then provided to detail wh at the contents are.</t> The output of "dumpasn1" <xref target="dumpasn1"/> is then provided to detail wh at the contents are.</t>
<section anchor="acpNodeName"> <section anchor="acpNodeName">
<name>Require an RFC8994/ACP subjectAltName with specific otherName</nam <name>Require an RFC 8994 / ACP subjectAltName with Specific otherName</
e> name>
<t>A single subjectAltName extension is specified in a single <xref targ <t>A single subjectAltName extension is specified in a single <tt>CsrAtt
et="RFC7030"/> <tt>CsrAttrs</tt> rs</tt>
attribute with OID '<tt>id-ExtensionReq</tt>' indicating type <tt>Extensions</tt attribute <xref target="RFC7030"/> with an OID '<tt>id-ExtensionReq</tt>' indica
>. ting type <tt>Extensions</tt>.
This is what might be created by an <xref target="RFC8995"/> Registrar that is a This is what might be created by a Registrar <xref target="RFC8995"/> that is as
sking for <xref target="RFC8994"/> AcpNodeName with format '<tt>otherNames</tt>' king for AcpNodeName <xref target="RFC8994"/> with format '<tt>otherNames</tt>'.
.</t> </t>
<section anchor="base64-encoded-example"> <section anchor="base64-encoded-example">
<name>Base64 encoded example</name> <name>Base64-Encoded Example</name>
<t>The Base64:</t> <t>The Base64:</t>
<sourcecode type="base64" markers="false"><![CDATA[ <sourcecode type="base64" markers="false"><![CDATA[
MGgwZgYJKoZIhvcNAQkOMVkwVzBVBgNVHREBAf8ESzBJoEcG MGgwZgYJKoZIhvcNAQkOMVkwVzBVBgNVHREBAf8ESzBJoEcG
CCsGAQUFBwgKoDsWOXJmYzg5OTQrZmQ3MzlmYzIzYzM0NDAx CCsGAQUFBwgKoDsWOXJmYzg5OTQrZmQ3MzlmYzIzYzM0NDAx
MTIyMzM0NDU1MDAwMDAwMDArQGFjcC5leGFtcGxlLmNvbQ== MTIyMzM0NDU1MDAwMDAwMDArQGFjcC5leGFtcGxlLmNvbQ==]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="asn1-dump-output"> <section anchor="asn1-dump-output">
<name>ASN.1 DUMP output</name> <name>ASN.1 DUMP Output</name>
<t>There is a single subjectAltName Extension with an Attribute with E xtension type.</t> <t>There is a single subjectAltName Extension with an Attribute with E xtension type.</t>
<artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
<30 68> <30 68>
0 104: SEQUENCE { 0 104: SEQUENCE {
<30 66> <30 66>
2 102: SEQUENCE { 2 102: SEQUENCE {
<06 09> <06 09>
4 9: OBJECT IDENTIFIER 4 9: OBJECT IDENTIFIER
: extensionRequest (1 2 840 113549 1 9 14) : extensionRequest (1 2 840 113549 1 9 14)
: (PKCS #9 via CRMF) : (PKCS #9 via CRMF)
<31 59> <31 59>
15 89: SET { 15 89: SET {
skipping to change at line 475 skipping to change at line 665
: 'rfc8994+fd739fc23c34401122334455' : 'rfc8994+fd739fc23c34401122334455'
: '00000000+@acp.example.com' : '00000000+@acp.example.com'
: } : }
: } : }
: } : }
: } : }
: } : }
: } : }
: } : }
: } : }
: } : }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="rfc7030-original-example"> <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="comm <t>In this example, taken from <xref section="4.5.2" sectionFormat="of"
a" target="RFC7030"/>, a few different attributes are included. target="RFC7030"/>, a few different attributes are included.
The original encoding of the '<tt>macAddress</tt>' part in the example is NOT CO RRECT. The original encoding of the '<tt>macAddress</tt>' part in the example is NOT CO RRECT.
It was not aligned with the definition of the Extension Request attribute as spe cified in <xref section="5.4.2" sectionFormat="of" target="RFC2985"/>. It was not aligned with the definition of the Extension Request attribute as spe cified in <xref section="5.4.2" sectionFormat="of" target="RFC2985"/>.
The revised encoding given here does not use an '<tt>id-ExtensionReq</tt>' attri bute The revised encoding given here does not use an '<tt>id-ExtensionReq</tt>' attri bute
because the MAC Address is not an X.509 certificate extension by itself because the MAC Address is not an X.509 certificate extension by itself
and because the server provides its OID without a value, and because the server provides its OID without a value,
which is not allowed syntactically within a structure of type '<tt>Extension</tt >'.</t> which is not allowed syntactically within a structure of type '<tt>Extension</tt >'.</t>
<section anchor="base64-encoded-example-1"> <section anchor="base64-encoded-example-1">
<name>Base64 encoded example</name> <name>Base64-Encoded Example</name>
<t>The Base64:</t> <t>The Base64:</t>
<sourcecode type="base64" markers="false"><![CDATA[ <sourcecode type="base64" markers="false"><![CDATA[
MDIGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgcr MDIGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgcr
BgEBAQEWBggqhkjOPQQDAw== BgEBAQEWBggqhkjOPQQDAw==]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="asn1-dump-output-1"> <section anchor="asn1-dump-output-1">
<name>ASN.1 DUMP output</name> <name>ASN.1 DUMP Output</name>
<t>The CsrAttrs structure contains:</t> <t>The CsrAttrs structure contains:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The challengePassword attribute is included to indicate that th e <t>The challengePassword attribute to indicate that the
CSR should include this value.</t> CSR should include this value.</t>
</li> </li>
<li> <li>
<t>An ecPublicKey OID is provided with the value secp384r1 to <t>An ecPublicKey OID with the value secp384r1 to
indicate what kind of public key should be submitted.</t> indicate what kind of public key should be submitted.</t>
</li> </li>
<li> <li>
<t>The macAddress OID 1.3.6.1.1.1.1.22 is included to <t>The macAddress OID 1.3.6.1.1.1.1.22 to
indicate that the CSR is expected to include indicate that the CSR is expected to include
(in a subjectDirectoryAttributes extension) a MAC address value.</t> (in a subjectDirectoryAttributes extension) a MAC address value.</t>
</li> </li>
<li> <li>
<t>The ecdsaWithSHA384 OID is included to indicate what kind of ha sh <t>The ecdsaWithSHA384 OID to indicate what kind of hash
is expected to be used for the self-signature in the PKCS#10 CSR.</t> is expected to be used for the self-signature in the PKCS#10 CSR.</t>
</li> </li>
</ol> </ol>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
<30 32> <30 32>
0 50: SEQUENCE { 0 50: SEQUENCE {
<06 09> <06 09>
2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7) 2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
: (PKCS #9) : (PKCS #9)
<30 12> <30 12>
13 18: SEQUENCE { 13 18: SEQUENCE {
<06 07> <06 07>
15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
: (ANSI X9.62 public key type) : (ANSI X9.62 public key type)
skipping to change at line 540 skipping to change at line 728
<06 05> <06 05>
26 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34) 26 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
: (SECG (Certicom) named elliptic curve) : (SECG (Certicom) named elliptic curve)
: } : }
: } : }
<06 07> <06 07>
33 7: OBJECT IDENTIFIER '1 3 6 1 1 1 1 22' 33 7: OBJECT IDENTIFIER '1 3 6 1 1 1 1 22'
<06 08> <06 08>
42 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3) 42 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
: (ANSI X9.62 ECDSA algorithm with SHA384) : (ANSI X9.62 ECDSA algorithm with SHA384)
: } : }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="require-a-specific-subjectaltname-extension"> <section anchor="require-a-specific-subjectaltname-extension">
<name>Require a specific subjectAltName extension</name> <name>Require a Specific subjectAltName Extension</name>
<t>This example is the same as the previous one except that instead of t he OID <t>This example is the same as the previous one except that instead of t he OID
for a macAddress, a subjectAltName is specified as the only Extension element.</ t> for a macAddress, a subjectAltName is specified as the only Extension element.</ t>
<section anchor="base64-encoded-example-2"> <section anchor="base64-encoded-example-2">
<name>Base64 encoded example</name> <name>Base64-Encoded Example</name>
<t>The Base64:</t> <t>The Base64:</t>
<sourcecode type="base64" markers="false"><![CDATA[ <sourcecode type="base64" markers="false"><![CDATA[
MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq
hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ= hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="asn1-dump-output-2"> <section anchor="asn1-dump-output-2">
<name>ASN.1 DUMP output</name> <name>ASN.1 DUMP Output</name>
<t>The CsrAttrs structure contains:</t> <t>The CsrAttrs structure contains:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The challengePassword attribute is included to indicate that th e CSR should include this value.</t> <t>The challengePassword attribute to indicate that the CSR should include this value.</t>
</li> </li>
<li> <li>
<t>An ecPublicKey OID is provided with the value secp521r1 to indi cate what kind of public key should be submitted.</t> <t>An ecPublicKey OID with the value secp521r1 to indicate what ki nd of public key should be submitted.</t>
</li> </li>
<li> <li>
<t>An extensionRequest container with a subjectAltName value conta ining the name potato@example.com</t> <t>An extensionRequest container with a subjectAltName value conta ining the name potato@example.com.</t>
</li> </li>
<li> <li>
<t>The ecdsaWithSHA512 OID is included to indicate the SHA-512 has h is expected to be used for the self-signature in the PKCS#10 CSR.</t> <t>The ecdsaWithSHA512 OID to indicate the SHA-512 hash is expecte d to be used for the self-signature in the PKCS#10 CSR.</t>
</li> </li>
</ol> </ol>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
<30 45> <30 45>
0 69: SEQUENCE { 0 69: SEQUENCE {
<06 09> <06 09>
2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7) 2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
: (PKCS #9) : (PKCS #9)
<30 12> <30 12>
13 18: SEQUENCE { 13 18: SEQUENCE {
<06 07> <06 07>
15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
: (ANSI X9.62 public key type) : (ANSI X9.62 public key type)
skipping to change at line 601 skipping to change at line 787
33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20) 33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)
: (PKCS #9 via PKCS #12) : (PKCS #9 via PKCS #12)
<06 0A> <06 0A>
44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5' 44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
<06 03> <06 03>
56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5) 56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)
: (X.520 DN component) : (X.520 DN component)
<06 08> <06 08>
61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) 61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: (ANSI X9.62 ECDSA algorithm with SHA512) : (ANSI X9.62 ECDSA algorithm with SHA512)
: } : }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="require-a-public-key-of-a-specific-size"> <section anchor="require-a-public-key-of-a-specific-size">
<name>Require a public key of a specific size</name> <name>Require a Public Key of a Specific Size</name>
<t>(RFC-editor please remove: Example ref Harkins01)</t>
<t>The CSR requires an RSA public key of a specific size.</t> <t>The CSR requires an RSA public key of a specific size.</t>
<section anchor="base64-encoded-example-3"> <section anchor="base64-encoded-example-3">
<name>Base64 encoded example</name> <name>Base64-Encoded Example</name>
<t>The Base64:</t> <t>The Base64:</t>
<sourcecode type="base64" markers="false"><![CDATA[ <sourcecode type="base64" markers="false"><![CDATA[
MCkGCSqGSIb3DQEJBzARBgkqhkiG9w0BAQExBAICEAAGCSqG MCkGCSqGSIb3DQEJBzARBgkqhkiG9w0BAQExBAICEAAGCSqG
SIb3DQEBCw== SIb3DQEBCw==]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="asn1-dump-output-3"> <section anchor="asn1-dump-output-3">
<name>ASN.1 DUMP output</name> <name>ASN.1 DUMP Output</name>
<t>Provide a CSR with an RSA key that's 4096 bits and use SHA256 as th e hash algorithm within the signature.</t> <t>Provide a CSR with an RSA key that's 4096 bits and use SHA256 as th e hash algorithm within the signature.</t>
<artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
<30 29> <30 29>
0 41: SEQUENCE { 0 41: SEQUENCE {
<06 09> <06 09>
2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7) 2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
: (PKCS #9) : (PKCS #9)
<30 11> <30 11>
13 17: SEQUENCE { 13 17: SEQUENCE {
<06 09> <06 09>
15 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 15 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
: (PKCS #1) : (PKCS #1)
<31 04> <31 04>
26 4: SET { 26 4: SET {
<02 02> <02 02>
28 2: INTEGER 4096 28 2: INTEGER 4096
: } : }
: } : }
<06 09> <06 09>
32 9: OBJECT IDENTIFIER sha256WithRSAEncryption 32 9: OBJECT IDENTIFIER sha256WithRSAEncryption
(1 2 840 113549 1 1 11) (1 2 840 113549 1 1 11)
: (PKCS #1) : (PKCS #1)
: } : }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="require-a-public-key-of-a-specific-curve"> <section anchor="require-a-public-key-of-a-specific-curve">
<name>Require a public key of a specific curve</name> <name>Require a Public Key of a Specific Curve</name>
<t>(RFC-editor please remove: Example ref Harkins02)</t>
<t>The CSR requires an ECC public key with a specific curve.</t> <t>The CSR requires an ECC public key with a specific curve.</t>
<section anchor="base64-encoded-example-4"> <section anchor="base64-encoded-example-4">
<name>Base64 encoded example</name> <name>Base64-Encoded Example</name>
<t>The Base64:</t> <t>The Base64:</t>
<sourcecode type="base64" markers="false"><![CDATA[ <sourcecode type="base64" markers="false"><![CDATA[
MC4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgNV MC4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgNV
BAUGCCqGSM49BAMD BAUGCCqGSM49BAMD]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="asn1-dump-output-4"> <section anchor="asn1-dump-output-4">
<name>ASN.1 DUMP output</name> <name>ASN.1 DUMP Output</name>
<t>Provide a CSR with an ECC key from p384, include your serial number , and <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> use SHA384 as the hash algorithm within the signature.</t>
<artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
<30 2E> <30 2E>
0 46: SEQUENCE { 0 46: SEQUENCE {
<06 09> <06 09>
2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7) 2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
: (PKCS #9) : (PKCS #9)
<30 12> <30 12>
13 18: SEQUENCE { 13 18: SEQUENCE {
<06 07> <06 07>
15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
: (ANSI X9.62 public key type) : (ANSI X9.62 public key type)
skipping to change at line 685 skipping to change at line 865
26 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34) 26 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
: (SECG (Certicom) named elliptic curve) : (SECG (Certicom) named elliptic curve)
: } : }
: } : }
<06 03> <06 03>
33 3: OBJECT IDENTIFIER serialNumber (2 5 4 5) 33 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)
: (X.520 DN component) : (X.520 DN component)
<06 08> <06 08>
38 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3) 38 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
: (ANSI X9.62 ECDSA algorithm with SHA384) : (ANSI X9.62 ECDSA algorithm with SHA384)
: } : }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="require-specific-extensions-and-attributes"> <section anchor="require-specific-extensions-and-attributes">
<name>Require specific extensions and attributes</name> <name>Require Specific Extensions and Attributes</name>
<t>(RFC-editor please remove: Example ref Harkins03)</t> <t>The CSR is required to have an EC key, include a serial number,
<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"/>
a friendly name, favorite drink <xref target="favoritedrink"/> [OID 0.9.2342.192 [OID 0.9.2342.19200300.100.1.5], and
00300.100.1.5], and
use SHA512 as the hash algorithm within the signature.</t> use SHA512 as the hash algorithm within the signature.</t>
<section anchor="base64-encoded-example-5"> <section anchor="base64-encoded-example-5">
<name>Base64 encoded example</name> <name>Base64-Encoded Example</name>
<t>The Base64:</t> <t>The Base64:</t>
<sourcecode type="base64" markers="false"><![CDATA[ <sourcecode type="base64" markers="false"><![CDATA[
MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq
hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ= hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="asn1-dump-output-5"> <section anchor="asn1-dump-output-5">
<name>ASN.1 DUMP output</name> <name>ASN.1 DUMP Output</name>
<t>Provide a CSR with an EC key from sha521, include your serial numbe <t>Provide a CSR with an EC key from sha521 and include your serial nu
r, mber,
friendly name, and favorite drink, and hash it with SHA512.</t> friendly name, and favorite drink, and hash it with SHA512.</t>
<artwork><![CDATA[ <sourcecode type="asn.1"><![CDATA[
<30 45> <30 45>
0 69: SEQUENCE { 0 69: SEQUENCE {
<06 09> <06 09>
2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7) 2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
: (PKCS #9) : (PKCS #9)
<30 12> <30 12>
13 18: SEQUENCE { 13 18: SEQUENCE {
<06 07> <06 07>
15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
: (ANSI X9.62 public key type) : (ANSI X9.62 public key type)
skipping to change at line 736 skipping to change at line 913
33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20) 33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)
: (PKCS #9 via PKCS #12) : (PKCS #9 via PKCS #12)
<06 0A> <06 0A>
44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5' 44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
<06 03> <06 03>
56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5) 56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)
: (X.520 DN component) : (X.520 DN component)
<06 08> <06 08>
61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4) 61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
: (ANSI X9.62 ECDSA algorithm with SHA512) : (ANSI X9.62 ECDSA algorithm with SHA512)
: } : }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations from EST <xref target="RFC7030"/> section 6 are unchanged.</t> <t>The security considerations from <xref target="RFC7030" sectionFormat=" comma" section="6"/> are unchanged.</t>
<section anchor="identity-and-privacy-considerations"> <section anchor="identity-and-privacy-considerations">
<name>Identity and Privacy Considerations</name> <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. <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 Subject, which includes a manufacture The client may only be aware of its Initial Device
r serial number. Identifier (IDevID) Subject, which includes a manufacturer serial number.
The EST server can use this mechanism to tell the client to include a specific f ully qualified domain name in the CSR in order to complete domain ownership proo fs required by the CA. The EST server can use this mechanism to tell the client to include a specific f ully qualified domain name in the CSR in order to complete domain ownership proo fs required by the CA.
Additionally, the EST server may deem the manufacturer serial number in an IDevI D as personally identifiable information, and may want to specify a new random o paque identifier that the pledge should use in its CSR. Additionally, the EST server may deem the manufacturer serial number in an IDevI D as personally identifiable information and may want to specify a new random op aque identifier that the pledge should use in its CSR.
This may be desirable if the CA and EST server have different operators.</t> This may be desirable if the CA and EST server have different operators.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is asked to allocate three new Object Identifiers:</t> <t>
<ul spacing="normal"> For the ASN.1 module in <xref target="app-asn1-module"/>, IANA has assigned the
<li> following OID in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.
<t>One (TBD1) from the SMI Security for S/MIME Module Identifier 1.9.16.0)" registry:
(1.2.840.113549.1.9.16.0) registry for the ASN.1 module: id-mod-critemplate; see </t>
<xref target="app-asn1-module"/></t>
</li> <table anchor="table_1">
<li> <thead>
<t>One (TBD2) from the SMI Security for S/MIME Attributes <tr>
(1.2.840.113549.1.9.16.2) registry for the Certification Request <th>Decimal</th>
Information Template (id-aa-certificationRequestInfoTemplate) attribute; see <xr <th>Description</th>
ef target="app-asn1-module"/></t> <th>Reference</th>
</li> </tr>
<li> </thead>
<t>One (TBD3) SMI Security for S/MIME Attributes <tbody>
(1.2.840.113549.1.9.16.2) registry for the extension request <tr>
template (id-aa-extensionReqTemplate) attribute; see Appendix A</t> <td>82</td>
</li> <td>id-mod-critemplate</td>
</ul> <td>RFC 9908</td>
</section> </tr>
<section anchor="acknowledgments"> </tbody>
<name>Acknowledgments</name> </table>
<t>Corey Bonnell crafted example02 using a different tool, and this helped
debug other running code.</t> <t>
<t>Carl Wallace provided major parts of the CertificationRequestInfoTempla For the Certification Request Information Template and Extension Request Templat
te syntax declaration.</t> e attributes in <xref target="app-asn1-module"/>, IANA has assigned the followin
<t>Russ Housley did many reviews of the ASN.1 and suggested many fixes.</t g OIDs in the "SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)" reg
> istry:
<t>Deb Cooley did the usual Area Director Review.</t> </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>
</middle> </middle>
<back> <back>
<!-- [rfced] Informative reference RFC 9480 has been obsoleted by RFCs
9810 and 9811. We recommend replacing RFC 9480 with RFCs 9810 and
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 RFC Style Guide
(RFC 7322).
-->
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC5911"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 911.xml"/>
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
S/MIME</title> 912.xml"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="J. Schaad" initials="J." surname="Schaad"/> 268.xml"/>
<date month="June" year="2010"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 030.xml"/>
<t>The Cryptographic Message Syntax (CMS) format, and many associa
ted 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 f
ormats; 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.5
09 (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 fo
rmat, 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 c
hanges to any of the formats; this is simply a change to the syntax. This docume
nt is not an Internet Standards Track specification; it is published for informa
tional purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5912"/>
<seriesInfo name="DOI" value="10.17487/RFC5912"/>
</reference>
<reference anchor="RFC6268">
<front>
<title>Additional New ASN.1 Modules for the Cryptographic Message Sy
ntax (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 associa
ted 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 co
nform 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 s
imply a change to the syntax. This document is not an Internet Standards Track s
pecification; 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="H
arkins"/>
<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 pr
ofile, called Enrollment over Secure Transport (EST), describes a simple, yet fu
nctional, certificate management protocol targeting Public Key Infrastructure (P
KI) clients that need to acquire client certificates and associated Certificatio
n Authority (CA) certificates. It also supports client-generated public/private
key pairs as well as key pairs generated by the CA.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7030"/>
<seriesInfo name="DOI" value="10.17487/RFC7030"/>
</reference>
<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680"> <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680">
<front> <front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title> <title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
skipping to change at line 861 skipping to change at line 1020
<front> <front>
<title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1:2021"/> <seriesInfo name="ISO/IEC" value="8825-1:2021"/>
</reference> </reference>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
le> 174.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="March" year="1997"/> 148.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<t>In many standards track documents several words are used to sig 986.xml"/>
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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 C
onstrained Application Protocol</title>
<author fullname="P. van der Stok" initials="P." surname="van der St
ok"/>
<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 lightweigh
t Constrained Application Protocol (CoAP) for message exchanges. This document d
efines how to transport EST payloads over secure CoAP (EST-coaps), which allows
constrained devices to use existing EST functionality for provisioning certifica
tes.</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 contro
l 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 communi
ty.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2986"/>
<seriesInfo name="DOI" value="10.17487/RFC2986"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC2985"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 985.xml"/>
<title>PKCS #9: Selected Object Classes and Attribute Types Version <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
2.0</title> 211.xml"/>
<author fullname="M. Nystrom" initials="M." surname="Nystrom"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/> 272.xml"/>
<date month="November" year="2000"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<abstract> 280.xml"/>
<t>This memo represents a republication of PKCS #9 v2.0 from RSA L <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
aboratories' Public-Key Cryptography Standards (PKCS) series, and change control 295.xml"/>
is retained within the PKCS process. The body of this document, except for the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
security considerations section, is taken directly from that specification. This 368.xml"/>
memo provides information for the Internet community.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 994.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="RFC" value="2985"/> 995.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2985"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</reference> 480.xml"/>
<reference anchor="RFC4211"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 483.xml"/>
<title>Internet X.509 Public Key Infrastructure Certificate Request
Message Format (CRMF)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="September" year="2005"/>
<abstract>
<t>This document describes the Certificate Request Message Format
(CRMF) syntax and semantics. This syntax is used to convey a request for a certi
ficate to a Certification Authority (CA), possibly via a Registration Authority
(RA), for the purposes of X.509 certificate production. The request will typical
ly include a public key and the associated registration information. This docume
nt does not define a certificate request protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4211"/>
<seriesInfo name="DOI" value="10.17487/RFC4211"/>
</reference>
<reference anchor="RFC5272">
<front>
<title>Certificate Management over CMS (CMC)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<author fullname="M. Myers" initials="M." surname="Myers"/>
<date month="June" year="2008"/>
<abstract>
<t>This document defines the base syntax for CMC, a Certificate Ma
nagement protocol using the Cryptographic Message Syntax (CMS). This protocol ad
dresses two immediate needs within the Internet Public Key Infrastructure (PKI)
community:</t>
<t>1. The need for an interface to public key certification produc
ts and services based on CMS and PKCS #10 (Public Key Cryptography Standard), an
d</t>
<t>2. The need for a PKI enrollment protocol for encryption only k
eys due to algorithm or hardware design.</t>
<t>CMC also requires the use of the transport document and the req
uirements usage document along with this document for a full definition. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5272"/>
<seriesInfo name="DOI" value="10.17487/RFC5272"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate 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 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [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 Infrastru
cture) services, namely certificate enrollment (e.g., /simpleenroll). This docum
ent defines a number of other PKI services as additional path components -- spec
ifically, firmware and trust anchors as well as symmetric, asymmetric, and encry
pted keys. This document also specifies the PAL (Package Availability List), whi
ch is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notati
on) object that clients use to retrieve packages available and authorized for th
em. This document extends the EST server path components to provide these additi
onal 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 N
etwork Operations, Administration, and Maintenance (OAM)</title>
<author fullname="T. Eckert" initials="T." role="editor" surname="Ec
kert"/>
<author fullname="M. Behringer" initials="M." surname="Behringer"/>
<date month="May" year="2018"/>
<abstract>
<t>Operations, Administration, and Maintenance (OAM), as per BCP 1
61, for data networks is often subject to the problem of circular dependencies w
hen relying on connectivity provided by the network to be managed for the OAM pu
rposes.</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 prot
ocols are not secure enough to be carried across the network without security co
ncerns.</t>
<t>This document describes how to integrate OAM processes with an
autonomic control plane in order to provide stable and secure connectivity for t
hose OAM processes. This connectivity is not subject to the aforementioned circu
lar 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="Ec
kert"/>
<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 idea
lly be self-managing and be as independent as possible of configuration. This do
cument 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 "vi
rtual out-of-band channel" for Operations, Administration, and Management (OAM)
communications over a network that provides automatically configured, hop-by-hop
authenticated and encrypted communications via automatically configured IPv6 ev
en 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 man
ufacturer's authorizing service, both online and offline. We call this process t
he Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrappin
g a new device can occur when using a routable address and a cloud service, only
link-local connectivity, or limited/disconnected networks. Support for deployme
nt models with less stringent security requirements is included. Bootstrapping i
s complete when the cryptographic identity of the new key infrastructure is succ
essfully deployed to the device. The established secure connection can be used t
o 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 Certif
icate 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 Enveloped
Data instead of EncryptedValue, clarifying the handling of p10cr messages, impro
ving the crypto agility, as well as adding new general message types, extended k
ey usages to identify certificates for use with CMP, and well-known URI path seg
ments.</t>
<t>CMP version 3 is introduced to enable signaling support of Enve
lopedData instead of EncryptedValue and signal the use of an explicit hash Algor
ithmIdentifier 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</ti
tle>
<author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
<author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/
>
<author fullname="S. Fries" initials="S." surname="Fries"/>
<date month="November" year="2023"/>
<abstract>
<t>This document aims at simple, interoperable, and automated PKI
management operations covering typical use cases of industrial and Internet of T
hings (IoT) scenarios. This is achieved by profiling the Certificate Management
Protocol (CMP), the related Certificate Request Message Format (CRMF), and trans
fer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but s
ufficiently detailed and self-contained way. To make secure certificate manageme
nt for simple scenarios and constrained devices as lightweight as possible, only
the most crucial types of operations and options are specified as mandatory. Mo
re 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/~pgut 001/dumpasn1.c"> <reference anchor="dumpasn1" target="https://www.cs.auckland.ac.nz/~pgut 001/dumpasn1.c">
<front> <front>
<title>Dump ASN</title> <title>Dump ASN</title>
<author initials="P." surname="Gutmann" fullname="Peter Gutmann"> <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date day="22" month="4" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="favoritedrink" target="https://oid-base.com/get/0.9.2 342.19200300.100.1.5"> <reference anchor="favoritedrink" target="https://oid-base.com/get/0.9.2 342.19200300.100.1.5">
<front> <front>
<title>Favorite Drink: arbitrary OID</title> <title>drink(5) [other identifier: favouriteDrink]</title>
<author> <author>
<organization/> <organization>OID Repository</organization>
</author> </author>
<date>n.d.</date> <date day="4" month="July" year="2019"/>
</front> </front>
<refcontent>OID 0.9.2342.19200300.100.1.5</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<?line 861?>
<section anchor="app-asn1-module"> <section anchor="app-asn1-module">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<aside> <!--[rfced] Does Appendix A provide the ASN.1 module for the Extension
<t>RFC EDITOR: Please replace TBD1, TBD2, and TBD3 with the value assign Request Template attribute? Or is it provided for the
ed by IANA Certification Request Information Template attribute only?
during the publication of this document.</t>
</aside> Original:
This appendix provides an ASN.1 module [X.680] for the Certification
Request Information Template attribute, and it follows the
conventions established in [RFC5911], [RFC5912], and [RFC6268].
Perhaps:
This appendix provides an ASN.1 module [X.680] for the Certification
Request Information Template and Extension Request Template
attributes, and it follows the conventions established in [RFC5911],
[RFC5912], and [RFC6268].
-->
<t>This appendix provides an ASN.1 module <xref target="X.680"/> for the C ertification <t>This appendix provides an ASN.1 module <xref target="X.680"/> for the C ertification
Request Information Template attribute, and it follows the conventions Request Information Template attribute, and it follows the conventions
established in <xref target="RFC5911"/>, <xref target="RFC5912"/>, and <xref tar get="RFC6268"/>.</t> established in <xref target="RFC5911"/>, <xref target="RFC5912"/>, and <xref tar get="RFC6268"/>.</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
CRITemplateModule CRITemplateModule
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-critemplate(TBD1) } pkcs-9(9) smime(16) modules(0) id-mod-critemplate(82) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS -- from [RFC5912] IMPORTS -- from [RFC5912]
SupportedAttributes SupportedAttributes
FROM PKIX1Explicit-2009 FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) { iso(1) identified-organization(3) dod(6) internet(1) security(5)
skipping to change at line 1139 skipping to change at line 1126
security(5) mechanisms(5) pkix(7) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-pkcs10-2009(69) } id-mod(0) id-mod-pkcs10-2009(69) }
; ;
aa-certificationRequestInfoTemplate ATTRIBUTE ::= aa-certificationRequestInfoTemplate ATTRIBUTE ::=
{ TYPE CertificationRequestInfoTemplate IDENTIFIED BY { TYPE CertificationRequestInfoTemplate IDENTIFIED BY
id-aa-certificationRequestInfoTemplate } id-aa-certificationRequestInfoTemplate }
id-aa-certificationRequestInfoTemplate OBJECT IDENTIFIER ::= id-aa-certificationRequestInfoTemplate OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) id-aa-certificationRequestInfoTemplate(TBD2) } smime(16) aa(2) id-aa-certificationRequestInfoTemplate(61) }
-- like CertificationRequestInfo but OPTIONAL subject, subjectPKInfo -- like CertificationRequestInfo but OPTIONAL subject, subjectPKInfo
CertificationRequestInfoTemplate ::= SEQUENCE { CertificationRequestInfoTemplate ::= SEQUENCE {
version INTEGER { v1(0) } (v1, ... ), version INTEGER { v1(0) } (v1, ... ),
subject NameTemplate OPTIONAL, subject NameTemplate OPTIONAL,
subjectPKInfo [0] SubjectPublicKeyInfoTemplate subjectPKInfo [0] SubjectPublicKeyInfoTemplate
{{ PKInfoAlgorithms }} OPTIONAL, {{ PKInfoAlgorithms }} OPTIONAL,
attributes [1] Attributes{{ CRIAttributes }} attributes [1] Attributes{{ CRIAttributes }}
} }
skipping to change at line 1177 skipping to change at line 1164
} }
-- like SubjectPublicKeyInfo, but with OPTIONAL subjectPublicKey -- like SubjectPublicKeyInfo, but with OPTIONAL subjectPublicKey
SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE { SubjectPublicKeyInfoTemplate{PUBLIC-KEY:IOSet} ::= SEQUENCE {
algorithm AlgorithmIdentifier{PUBLIC-KEY, {IOSet}}, algorithm AlgorithmIdentifier{PUBLIC-KEY, {IOSet}},
subjectPublicKey BIT STRING OPTIONAL subjectPublicKey BIT STRING OPTIONAL
} }
id-aa-extensionReqTemplate OBJECT IDENTIFIER ::= id-aa-extensionReqTemplate OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) aa(2) id-aa-extensionReqTemplate(TBD3) } smime(16) aa(2) id-aa-extensionReqTemplate(62) }
-- like extensionRequest, but with OPTIONAL Extension extnValues -- like extensionRequest, but with OPTIONAL Extension extnValues
-- original definition was in PKCS#9 RFC 2985, Section 5.4.2
at-extensionReqTemplate ATTRIBUTE ::= { at-extensionReqTemplate ATTRIBUTE ::= {
TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate } TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate }
ExtensionReqTemplate ::= ExtensionTemplates{{CertExtensions}} ExtensionReqTemplate ::= ExtensionTemplates{{CertExtensions}}
-- like Extensions, but with OPTIONAL extnValue -- like Extensions, but with OPTIONAL extnValue
ExtensionTemplates{EXTENSION:ExtensionSet} ::= ExtensionTemplates{EXTENSION:ExtensionSet} ::=
SEQUENCE SIZE (1..MAX) OF ExtensionTemplate{{ExtensionSet}} SEQUENCE SIZE (1..MAX) OF ExtensionTemplate{{ExtensionSet}}
-- like Extension, but with OPTIONAL extnValue -- like Extension, but with OPTIONAL extnValue
skipping to change at line 1203 skipping to change at line 1190
critical BOOLEAN critical BOOLEAN
-- (EXTENSION.&Critical({ExtensionSet}{@extnID})) -- (EXTENSION.&Critical({ExtensionSet}{@extnID}))
DEFAULT FALSE, DEFAULT FALSE,
extnValue OCTET STRING (CONTAINING extnValue OCTET STRING (CONTAINING
EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL
-- contains the DER encoding of the ASN.1 value -- contains the DER encoding of the ASN.1 value
-- corresponding to the extension type identified -- corresponding to the extension type identified
-- by extnID when present -- by extnID when present
} }
END END]]></sourcecode>
]]></sourcecode>
<!--
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 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 CSRattrs
LocalWords: publicKey dumpasn otherName acpNodeName otherNames
LocalWords: AcpNodeName sourcecode csrattr ecdsaWithSHA sha
LocalWords: harkins critemplate csrinfo Changelog markdown
LocalWords: CRITemplateModule ExtensionReq
</section> </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=
<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 Revi
ew.</t>
</section>
<!-- [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 vs. CSRattrs
[Note: Are these terms different or should one instance of
"CSRattrs" be "CsrAttrs"?]
-->
<!-- [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> </rfc>
 End of changes. 135 change blocks. 
966 lines changed or deleted 707 lines changed or added

This html diff was produced by rfcdiff 1.48.