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

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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-pkcs8-prikeyinfo-contenttypes-04" number="9939" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.2

<!--[rfced] To more closely match the titles of other RFCs that
discuss "PKCS", we added a colon after the PKCS number in the
document title and short title that spans the running header of
the PDF file. Please let us know of any objection.

Original (document title):
   PKCS #8 Private-Key Information Content Types

Current:
   PKCS #8: Private-Key Information Content Types

...
Original (short title):
   PKCS #8 PrivateKeyInfo Content Types

Current:
   PKCS #8: PrivateKeyInfo Content Types
-->

  <front>
    <title abbrev="PKCS #8 #8: PrivateKeyInfo Content Types">PKCS #8 #8: Private-Key Information Content Types</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pkcs8-prikeyinfo-contenttypes-04"/> name="RFC" value="9939"/>
    <author initials="J." surname="Mandel" fullname="Joe Mandel">
      <organization abbrev="AKAYLA">AKAYLA, Inc.</organization>
      <address>
        <email>joe@akayla.com</email>
      </address>
    </author>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="S." surname="Turner" fullname="Sean Turner">
      <organization abbrev="sn3rd">sn3rd</organization>
      <address>
        <email>sean@sn3rd.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="03"/>
    <area>Security</area>
    <workgroup>Limited Additional Mechanisms year="2026" month="February"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>

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

<keyword>example</keyword>

    <abstract>
      <?line 82?>
<t>This document defines PKCS #8 content types for use with
PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in
RFC 5958.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://github.com/lamps-wg/pkcs8-PriKeyInfoCt"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-lamps-pkcs8-prikeyinfo-contenttypes/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Limited Additional Mechanisms for PKIX and SMIME  mailing list (<eref target="mailto:spasm@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/spasm/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/spasm/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/lamps-wg/pkcs8-PriKeyInfoCt"/>.</t>
    </note>
  </front>
  <middle>
    <?line 88?>

    <section anchor="intro">
      <name>Introduction</name>
      <t>The syntax for private-key information was originally described in <xref target="RFC5208"/>, and
the syntax was later revised by <xref target="RFC5958"/> to include the AsymmetricKeyPackage
content type that supports multiple PrivateKeyInfos. This document defines PKCS #8 content types for
use with one PrivateKeyInfo and one EncryptedPrivateKeyInfo. These content type assignments are
needed for the PrivateKeyInfo and EncryptedPrivateKeyInfo to be carried in the
Cryptographic Message Syntax (CMS) <xref target="RFC5652"/>.</t>
      <t>Note: A very long time ago, media types for PrivateKeyInfo and EncryptedPrivateKeyInfo were assigned
as application/pkcs8 "application/pkcs8" and application/pkcs8-encrypted, "application/pkcs8-encrypted", respectively.</t>
    </section>
    <section anchor="ContentTypes">
      <name>Private-Key Information Content Types</name>
      <t>This section defines a content type for private-key information and
encrypted private-key information.</t>
<t>The PrivateKeyInfo content type is identified by the following object identifier:</t>
      <artwork><![CDATA[

<!--[rfced] In Section 2, we updated <artwork> to <sourcecode>. Please
confirm that this is correct.

In addition, please consider whether the “type" attribute of the
sourcecode elements have been set correctly (all are set to "asn.1").

The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. 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.
-->

      <sourcecode type="asn.1"><![CDATA[
id-ct-privateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
 smime(16) ct(1) TBD1 }
]]></artwork> 52 }]]></sourcecode>

      <t>The EncryptedPrivateKeyInfo content type is identified by the following object identifier:</t>
      <artwork><![CDATA[

      <sourcecode type="asn.1"><![CDATA[
id-ct-encrPrivateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
 smime(16) ct(1) TBD2 }
]]></artwork> 53 }]]></sourcecode>

    </section>
    <section anchor="asn1-mod">
      <name>ASN.1 Module</name>
      <t>The ASN.1 module <xref target="X680"/><xref target="X680"/> <xref target="X690"/> in this section builds upon the modules in <xref target="RFC5911"/>.</t>

      <sourcecode type="asn.1" markers="true"><![CDATA[
PrivateKeyInfoContentTypes
 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
   pkcs-9(9) smime(16) modules(0) id-mod-pkcs8ContentType(TBD0) id-mod-pkcs8ContentType(85) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORTS ALL

IMPORTS

CONTENT-TYPE
 FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
     pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }

PrivateKeyInfo, EncryptedPrivateKeyInfo
 FROM AsymmetricKeyPackageModuleV1 -- in [RFC5958]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0)
      id-mod-asymmetricKeyPkgV1(50) }  ;

PrivateKeyInfoContentTypes CONTENT-TYPE ::= {
 ct-privateKeyInfo | ct-encrPrivateKeyInfo,
 ... -- Expect additional content types --  }

ct-privateKeyInfo CONTENT-TYPE ::= { PrivateKeyInfo
 IDENTIFIED BY id-ct-privateKeyInfo }

id-ct-privateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
 smime(16) ct(1) TBD1 52 }

ct-encrPrivateKeyInfo CONTENT-TYPE ::= { EncryptedPrivateKeyInfo
 IDENTIFIED BY id-ct-encrPrivateKeyInfo }

id-ct-encrPrivateKeyInfo OBJECT IDENTIFIER ::= { iso(1)
 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
 smime(16) ct(1) TBD2 53 }

END
]]></sourcecode>

END]]></sourcecode>

    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations in <xref target="RFC5958"/> apply here.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>For each of the private key info private-key information content types defined in section <xref target="ContentTypes"/>,
IANA is requested to assign has assigned an object identifier (OID) for each of the content types. Object Identifier (OID). The
OIDs for the content types should be alloacted have been allocated in the "SMI Security for S/MIME CMS Content Type" Type (1.2.840.113549.1.9.16.1)" registry (1.2.840.113549.1.9.16.1) <xref target="IANA-CMS-CTS"/>, and the description should be set to id-ct-privateKeyInfo (TDB1)
and id-ct-encrPrivateKeyInfo (TBD2).</t> target="IANA-CMS-CTS"/> as follows:
      </t>

  <table>
        <thead>
          <tr>
            <th align="left">Decimal</th>
            <th align="left">Description</th>
	     <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">52</td>
            <td align="left">id-ct-privateKeyInfo</td>
	    <td align="left">RFC 9939</td>
          </tr>
	   <tr>
            <td align="left">53</td>
            <td align="left">id-ct-encrPrivateKeyInfo</td>
	    <td align="left">RFC 9939</td>
          </tr>
        </tbody>
      </table>

      <t>For the ASN.1 Module module in <xref target="asn1-mod"/>, IANA is requested to assign has assigned an
object identifier (OID) OID for the module identifier. The OID for the module
should be
has been allocated in the "SMI Security for S/MIME Module Identifier" Identifier (1.2.840.113549.1.9.16.0)"
registry (1.2.840.113549.1.9.16.0)  <xref target="IANA-SMIME-MODS"/>, and the Description for the new OID should be set
to "id-mod-pkcs8ContentType".</t> target="IANA-SMIME-MODS"/> as follows:</t>

 <table>
        <thead>
          <tr>
            <th align="left">Decimal</th>
            <th align="left">Description</th>
	     <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">85</td>
            <td align="left">id-mod-pkcs8ContentType</td>
	    <td align="left">RFC 9939</td>
          </tr>
        </tbody>
      </table>

      <t>IANA is also requested to update has updated the application/cms registration entry in the "Media Types" registry by adding RFC 9939 to add [ RFC-to-be] the "Interoperability considerations" section and to the list of RFCs where Inner Content Types (ICTs) are defined in (see the "Optional parameters" section) and the "Interoperability considerations" sections.</t>
      <t>IANA is also requested to update the application/cms entry in the "Media Types" registry to
add by adding the following values to the "innerContent" list:</t> list of ICTs:</t>
      <ul spacing="normal"> spacing="compact">
        <li>
          <t>privateKeyInfo</t>
        </li>
        <li>
          <t>encrPrivateKeyInfo</t>
        </li>
      </ul>
      <t>And, to update the following row in
      <t>IANA has also updated the application/cms entry's "Security considerations" section:</t> section in the application/csm entry as follows:</t>
      <table>
        <thead>
          <tr>
            <th align="left">RFC</th>
            <th align="left">CMS Protecting Content Type and Algorithms</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">[ RFC-to-be ]</td> align="left">RFC 9939</td>
            <td align="left">privateKeyInfo and encrPrivateKeyInfo</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC5958">
          <front>
            <title>Asymmetric Key Packages</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="August" year="2010"/>
            <abstract>
              <t>This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5958"/>
          <seriesInfo name="DOI" value="10.17487/RFC5958"/>
        </reference>
        <reference anchor="RFC5911">
          <front>
            <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5911"/>
          <seriesInfo name="DOI" value="10.17487/RFC5911"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/>

        <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
          <front>
	    <title>Information technology -- - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>

        <reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
            <title>Information technology -- - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1-2021"/> value="8825-1:2021"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC5208">
          <front>
            <title>Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2</title>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.</t>
              <t>This document describes a syntax for private-key information. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5208"/>
          <seriesInfo name="DOI" value="10.17487/RFC5208"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5208.xml"/>
        <reference anchor="IANA-SMIME-MODS" target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-0"> target="https://www.iana.org/assignments/smi-numbers">
          <front>
            <title>SMI Security for S/MIME Module Identifier</title> Identifier (1.2.840.113549.1.9.16.0)</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="IANA-CMS-CTS" target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1"> target="https://www.iana.org/assignments/smi-numbers">
          <front>
            <title>SMI Security for S/MIME CMS Content Type</title> Type (1.2.840.113549.1.9.16.1)</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
      </references>
    </references>
    <?line 207?>

    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to John Gray, Deb Cooley, Mohamed Boucadair, Orie Steele, and Éric Vyncke <contact fullname="John Gray"/>, <contact fullname="Deb
      Cooley"/>, <contact fullname="Mohamed Boucadair"/>, <contact
      fullname="Orie Steele"/>, and <contact fullname="Éric Vyncke"/> for
      reviewing the document and providing comments.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+1ZW2/bOBZ+5684cB7q7EZynCZF4kUXdRyn6zaOg9hbtBj0
gZYYmxNZ1JBSXCN13/d37R/bc0jJlmynl9kpdh42QGGJPDyX71ypep7HUplG
ogW1m7edIeydwo2WDzwV3luxgF58p/SMp1LF0FFxKuIURotEmBrj47EWD9vn
8Bid2iQPcGui9KIFJg0ZC1UQ8xmKDTW/Sz0p0jsv4rPEeMl9YE69RMt7sZDI
yAsco5T4eIfHzGTjmTQGVaKlFvS6o0sWZ7Ox0C0WopgWwyNGxCYzLUh1Jhiq
+ZxxLTiqOxRBpmW6qLG50vcTrbIEV6/kTKYihHYYSrKWR9AXwZTH0swMIAhw
87b3HngcwrDf63drDNVDBmGLgcceRJyhWIDfzw7AWVOjxxmXET6ahJvZK8LG
V3pCG1wHU9yYpmliWo0G0dGSfBB+QdaghcZYq7kRDcuhQScnMp1mYzzrUJ5P
Gg5o9FrusU5KdBECaNKSDHfQD9Ss8dWjjGfpVKELPHCefaME9NFCESFbVKwF
7bftD1ftA4yqwCdj8ghyy7ggnN2/KvGK3/NFxEnqit9tZgz8Q2UmEouC4zs5
kREULj2Aq6tOiXF1dy1g6pi8eqB9I4KKmKHgMYwyHQtdSDHxcx2W+BbvOTuD
J17ZNcuIxS5lHmxE3F52Tl6cHBWPZyenq8dmkx7fvzg9pF8MAK4nAqEvkJ/P
575MM1/GaUOLoDHybrsd772PBxy9S9y/2xeo5GqKwRarSE0WgBnu9ttjk2oe
pDBcxCn/BNcqdcSDWEC9Pbz2m/utnHaYiEDeycARqDsYcyMDiPMjlqrwNz17
Dqje6J/eyC7YPISjw6Omd3hkV4zQUhjK6EKIpYZbgaDNRBxazi1Y24cUw0Gj
1+204PT06NhrtoifhezsRyE7+32QESgg4kCFMp6AziKBJWULnHMLTrcguyUy
qJ93b/cPckYdHqsYT0RbVB2ksnXgQpoU1zNpplg4NskukOwno362C/UTr+lZ
1GUB1Tqsjw5tLPfa123PVjGvP7gYtspA13B9lYC27g0bRAl9FaJh0AuxsiOW
Qtee9iePuStsWPQnMSqdmoaZSc/V/Mqz/2mazqI9k0v0cGsmvMNCy05/6HVG
36kiElea2M/UsPl/HP8gHBnzPA8rtat1jI2m0gBOGxlxg1DcyRjzqZhZ8tnC
9l7XlzMjYI4tj22MM5SimJR6kWBf39wzYFxNwMyVMcPkAKr0vlNmJsMwEozt
Yb1JNTossIXjcU/S65J0FGBcUSYVknwAwwkDZKlCzVGO0tizcJyIFmiLCbQc
W5Hw+Jhn5HJ5QLqydM2TzlFb14DdSxo8MF7kB1DJ5RJShSyCKAsF0LG2WWBp
SLUM0MAbHtzziWBlpJCKp2CyJFE6NTDLolQmGIVVWIwPPwg+K8AHFW9y+5oD
SJDAoxUdSzGEY5NgsRAhmm5nr+93LUIzRsZca+dbAoh1iFRNNE+mWPf7whhE
qGirdYz3/RxebPzLJUYBtlrMkDY8CL2ASGFZTzFagU/UAcxEKHkpAH9AubnQ
hZ0iZOhlniRR3pfcjGaPb616omB4gCFBoUtlPVr4FKPfNf5j8Obv9nWZ55kR
LrQLT/OqS74W3BSzK7WeovJdrmzAUJGBWsiiGNpAp4i+U1Gk5tRO1fhX1HFN
gp2UffnyhcnQC1IvqTIenL/pdkbQu+hej3qXve4ttFov4RFlqHoT2/FMUCny
xipc1I/2sXTUT48P90EbHhpZbzafnxyf7QNBjuT21zurn+FBW6zqzRf7EKS0
NTq/aMLSKmINfMrhf5ylBPXN/87ao8LavXzGyvvY4x43cdObqTAvi253lu8+
0rC8XNLvGf66fCzF3TiTUWggS5RN1PycWRdInLltQqJsTJzYb26U+XJQs5Xt
P2Y6tbeV9SXjc2XqeBB9gG/uqlsSWUdkcBdNv+he9q57o97gegi9/s1Vr9Mb
waj9ekg+Yefd171r6i3QfX8zuB0NoX11xRgS0gtjncH1CJ3ojT7cdBlc3g76
UClZecVyBQvHu8MzHHkJpF9yjD6SDb/f+u+1P5gZkn6Mw2r9uGkNr7rj4KlM
yK3a1alcJL1rVkw6ObUm/Vc2fcOonCg3jVc0u5+8a9ZPyLUAf2ObVpaDDsq+
cwnIYLsyfYadOYzXDd/3yfLuJ6rqwNffH6rdFkkI7m3O2/JhE/pVhbiA8w+w
s3Ii6z9FRWW7S90OI58MtF3W7mC5svhPUFlZ9/rCltfHFhiV6QAve6HwZlzf
4+T88hl9E3u2pOK7mtcxBg22Cm3brMlH0mIzqGyWqqmdHmm8WMAUZxEsrDTk
4g1hi98ltn6qyHk8QNHYN8LSDQ520Cpq+uNjZdJYHjArAKu+Fr9lwtC4kKp8
DMIxYrvxQX3Qu9i304fgwZRu7KRKRbIdIRnSuSFsax/MVGVRSMMgDt8Krxar
cfBHbj5aTPCaj0Ngvekf+ehl33nXb/r474XfpMmxfMXKx3krxw38iUVlrY4R
qR3gd6VbfXRxjgFGDJ4MTmo6R/v+2kWVhmx9verJqMzXwWdfA3/dkUv7FnhA
mg0SVgWcPh9/G/Adt+FvIX64Qnx99S6DflECvdAwFnOrccUJDHGoPdHYawhv
ARyPjKqilyX03cZyLo/q2B0Bz+vFyuy+vSq4D+qwMozwD0P4hb7JeKnyxuIj
rdGJCCko3HHHwJxSFEf6GJ1SHebrvc7I7NMtqZyAVuQgydtHwjXHhob1o7bC
pob3WaFVgmk+ltF2pagVSWx+rv2M7K9Ovw88QgEFDjVJVudG1ywsOA3/Barp
ggvb+cFYO8ZrUlXNtRyt5oV6O3V/Ztb/4/AUOqjKZ3KRGyCwt1PduNF4Zwzo
i2DFWRb7djRRyHCKQj6zzy1v9ffX0vM3//BoOWjgI0pOti+fO0oGSnVfNsY4
ctkZPriP1TwS4cTet7HvuK80InxZu0OHi5od53l8b13yRk1jeK354gDTa4z2
qUjgc19NMcRCOFdZwEMu9QEM8NoNw1SISLiU/Pe/cKSCd4s4uHf3SfqkIawr
bIksvjUQbaLVg7QfUd23zpTC8D8ViePs8hoAAA== [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 practice.
-->

</rfc>