<?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-tls-tls13-pkcs1-07" number="9963" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->

  <front>
    <title abbrev="Legacy PKCS#1 codepoints PKCS #1 Code Points for TLS 1.3">Legacy RSASSA-PKCS1-v1_5 codepoints Code Points for TLS 1.3</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tls-tls13-pkcs1-07"/> name="RFC" value="9963"/>
    <author initials="D." surname="Benjamin" fullname="David Benjamin">
      <organization>Google LLC</organization>
      <address>
        <email>davidben@google.com</email>
      </address>
    </author>
    <author initials="A." surname="Popov" fullname="Andrei Popov">
      <organization>Microsoft Corp.</organization>
      <address>
        <email>andreipo@microsoft.com</email>
      </address>
    </author>
    <date year="2025" month="December" day="02"/>
    <area>Security</area>
    <workgroup>Transport Layer Security</workgroup> year="2026" month="April"/>

    <area>SEC</area>
    <workgroup>tls</workgroup>

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

<keyword>example</keyword>

    <abstract>
      <?line 76?>
<t>This document allocates code points for the use of RSASSA-PKCS1-v1_5 with
client certificates in TLS 1.3. This removes an obstacle for some deployments
to migrate to TLS 1.3.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://tlswg.github.io/tls13-pkcs1/draft-ietf-tls-tls13-pkcs1.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Transport Layer Security Working Group mailing list (<eref target="mailto:tls@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/tls/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/tls/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/tlswg/tls13-pkcs1"/>.</t>
    </note>
  </front>
  <middle>
    <?line 82?>

    <section anchor="introduction">
      <name>Introduction</name>
      <t>TLS 1.3 <xref target="RFC8446"/> removed support for RSASSA-PKCS1-v1_5 <xref target="RFC8017"/> in
CertificateVerify messages in favor of RSASSA-PSS. While RSASSA-PSS is a
long-established signature algorithm, some legacy hardware cryptographic devices
lack support for it. While uncommon in TLS servers, these devices are sometimes
used by TLS clients for client certificates.</t>
      <t>For example, Trusted Platform Modules (TPMs) are ubiquitous hardware
cryptographic devices that are often used to protect TLS client certificate
private keys. However, a large number of TPMs are unable to produce RSASSA-PSS
signatures compatible with TLS 1.3. TPM specifications prior to 2.0 did not
define RSASSA-PSS support (see Section 5.8.1 of <xref target="TPM12"/>). TPM 2.0
includes RSASSA-PSS, but only those TPM 2.0 devices compatible with US FIPS
186-4 can be relied upon to use the salt length matching the digest length, as
required for compatibility with TLS 1.3 (see Appendix B.7 of <xref target="TPM2"/>).</t>
      <t>TLS connections that rely on such devices cannot migrate to TLS 1.3. Staying on
TLS 1.2 leaks the client certificate to network attackers
<xref target="PRIVACY"/> and additionally prevents such
deployments from protecting traffic against retroactive decryption by an
attacker with a quantum computer <xref target="I-D.ietf-tls-hybrid-design"/>.</t> target="RFC9954"/>.</t>
      <t>Additionally, TLS negotiates protocol versions before client certificates.
Clients send ClientHellos without knowing whether the server will request to
authenticate with legacy keys. Conversely, servers respond with a TLS
version and CertificateRequest without knowing if the client will then
respond with a legacy key. If the client and server, respectively, offer and
negotiate TLS 1.3, the connection will fail due to the legacy key, when it
previously succeeded at TLS 1.2.</t>
      <t>To recover from this failure, one side must globally disable TLS 1.3 or the
client must implement an external fallback. Disabling TLS 1.3 impacts
connections that would otherwise be unaffected by this issue, while external
fallbacks break TLS's security analysis and may introduce vulnerabilities
<xref target="POODLE"/>.</t>
      <t>This document allocates code points to use these legacy keys with client
certificates in TLS 1.3. This reduces the pressure on implementations to select
one of these problematic mitigations and unblocks TLS 1.3 deployment.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="pkcs1-v15-signaturescheme-types">
      <name>PKCS#1 v1.5 SignatureScheme Types</name>
      <t>The following SignatureScheme values are defined for use with TLS 1.3.</t>
      <artwork><![CDATA[
    enum {
        rsa_pkcs1_sha256_legacy(0x0420),
        rsa_pkcs1_sha384_legacy(0x0520),
        rsa_pkcs1_sha512_legacy(0x0620),
    } SignatureScheme;
]]></artwork> SignatureScheme;]]></artwork>

      <t>The above code points indicate a signature algorithm using RSASSA-PKCS1-v1_5
<xref target="RFC8017"/> with the corresponding hash algorithm as defined in
<xref target="SHS"/>. They are only defined for signatures in
the client CertificateVerify message and are not defined for use in other
contexts. In particular, servers intending that intend to advertise support for
RSASSA-PKCS1-v1_5 signatures in the certificates themselves should use the
<tt>rsa_pkcs1_*</tt> constants defined in <xref target="RFC8446"/>.</t>
      <t>Clients MUST NOT <bcp14>MUST NOT</bcp14> advertise these values in the <tt>signature_algorithms</tt> extension
of the ClientHello. They MUST NOT <bcp14>MUST NOT</bcp14> accept these values in the server
CertificateVerify message.</t>
      <t>Servers that wish to support clients authenticating with legacy
RSASSA-PKCS1-v1_5-only keys MAY <bcp14>MAY</bcp14> send these values in the
<tt>signature_algorithms</tt> extension of the CertificateRequest message and accept
them in the client CertificateVerify message. Servers MUST NOT <bcp14>MUST NOT</bcp14> accept these code
points if not offered in the CertificateRequest message.</t>
      <t>Clients
<!-- [rfced] Please clarify whether "them" refers to the "legacy keys" or "signature algorithms".  May we update the text as follows?

Original (the full paragraph included for context):
   Clients with such legacy keys MAY negotiate the use of these
   signature algorithms if offered by the server.  Clients SHOULD NOT
   negotiate them with keys that support RSASSA-PSS, though this may not
   be practical to determine in all applications.  For example,
   attempting to test a key for support might display a message to the
   user or have other side effects.

   Perhaps:
      ... Clients with such legacy keys MAY negotiate the use of these
   signature algorithms if offered by the server.  Clients SHOULD NOT
   negotiate the use of these signature algorithms with keys that support RSASSA-PSS, though it may not
   be practical to determine which keys support RSASSA-PSS in all applications.

   In addition, please clarify "display" in the last sentence - we wonder whether "might result in" or "might expose" might be more clear.

 -->
<t>Clients with such legacy keys <bcp14>MAY</bcp14> negotiate the use of these signature
algorithms if offered by the server.  Clients <bcp14>SHOULD NOT</bcp14> negotiate them with
keys that support RSASSA-PSS, though this may not be practical to determine in
all applications. For example, attempting to test a key for support might
display a message to the user or have other side effects.</t>
      <t>TLS implementations SHOULD <bcp14>SHOULD</bcp14> disable these code points by default. See
<xref target="security-considerations"/>.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The considerations in <xref target="introduction"/> do not apply to server keys, so these new
code points are forbidden for use with server certificates. RSASSA-PSS continues
to be required for TLS 1.3 servers using RSA keys. This minimizes the impact to
only those cases in which it is necessary to unblock deployment of TLS 1.3 deployment.</t> 1.3.</t>
      <t>When implemented incorrectly, RSASSA-PKCS1-v1_5 admits signature
forgeries <xref target="MFSA201473"/>. Implementations producing or verifying signatures
with these algorithms MUST <bcp14>MUST</bcp14> implement RSASSA-PKCS1-v1_5 as specified in section
8.2 of <xref target="RFC8017"/>. target="RFC8017" section="8.2"/>. In particular, clients MUST <bcp14>MUST</bcp14> include the mandatory NULL
parameter in the DigestInfo structure and produce a valid DER <xref target="X690"/>
encoding. Servers MUST <bcp14>MUST</bcp14> reject signatures which do not meet these requirements.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to create has created the following entries in the
TLS SignatureScheme
"TLS SignatureScheme" registry. The "Recommended" column
should be
has been set to "N", and the "Reference" column should be set refers to this document.</t>
      <table>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0x0420</td>
            <td align="left">
              <tt>rsa_pkcs1_sha256_legacy</tt></td>
          </tr>
          <tr>
            <td align="left">0x0520</td>
            <td align="left">
              <tt>rsa_pkcs1_sha384_legacy</tt></td>
          </tr>
          <tr>
            <td align="left">0x0620</td>
            <td align="left">
              <tt>rsa_pkcs1_sha512_legacy</tt></td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
            <author fullname="K. Moriarty" initials="K." role="editor" surname="Moriarty"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
            <author fullname="A. Rusch" initials="A." surname="Rusch"/>
            <date month="November" year="2016"/>
            <abstract>
              <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
              <t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</t>
              <t>This document also obsoletes RFC 3447.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8017"/>
          <seriesInfo name="DOI" value="10.17487/RFC8017"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="X690"> anchor="X690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
            <title>Information technology - ASN.1 encoding Rules: rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2002"/> year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1:2002"/> value="8825-1:2021"/>
        </reference>

        <reference anchor="TPM12" target="https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf">
          <front>
            <title>TPM Main Specification Level 2 Version 1.2, Revision 116, Main, Part 2 - Structures of the TPM</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2011" month="March" day="01"/>
          </front>
          <refcontent>Level 2, Version 1.2, Revision 116</refcontent>
        </reference>
        <reference anchor="TPM2" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf">
          <front>
            <title>Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59, Library, Part 1: Architecture</title>
            <author>
              <organization>Trusted Computing Group</organization>
            </author>
            <date year="2019" month="November" day="08"/>
          </front>
          <refcontent>Family 2.0, Level 00, Revision 01.59</refcontent>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="SHS"> anchor="SHS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
          <front>
            <title>Secure hash standard</title> Hash Standard</title>
            <author>
              <organization/>
              <organization abbrev="NIST">National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="NIST FIPS" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/>
          <refcontent>National Institute of Standards and Technology (U.S.)</refcontent> value="10.6028/NIST.FIPS.180-4"/>
        </reference>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="MFSA201473" target="https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/">
          <front>
            <title>RSA
            <title>Mozilla Foundation Security Advisory 2014-73: RSA Signature Forgery in NSS</title>
            <author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
              <organization/>
            </author>
            <date year="2014" month="September" day="23"/> day="24"/>
          </front>
        </reference>
        <reference anchor="POODLE" target="https://security.googleblog.com/2014/10/this-poodle-bites-exploiting-ssl-30.html">
          <front>
            <title>This POODLE bites: exploiting the SSL 3.0 fallback</title>
            <author initials="B." surname="Moeller" fullname="Bodo Moeller">
              <organization/>
            </author>
            <date year="2014" month="October" day="14"/>
          </front>
          <refcontent>Google Security Blog</refcontent>
        </reference>
        <reference anchor="PRIVACY">
          <front>
            <title>Push away your privacy: Precise user tracking based on TLS client certificate authentication</title>
            <author fullname="Matthias Wachs" initials="M." surname="Wachs">
              <organization/>
            </author>
            <author fullname="Quirin Scheitle" initials="Q." surname="Scheitle">
              <organization/>
            </author>
            <author fullname="Georg Carle" initials="G." surname="Carle">
              <organization/>
            </author>
            <date month="June" year="2017"/>
          </front>
          <seriesInfo name="2017
          <refcontent>2017 Network Traffic Measurement and Analysis Conference (TMA)" value="pp. 1-9"/> (TMA). pp. 1-9</refcontent>
          <seriesInfo name="DOI" value="10.23919/tma.2017.8002897"/>
          <refcontent>IEEE</refcontent>
        </reference>
<!-- [rfced] draft-ietf-tls-hybrid-design is currently in AUTH48 as RFC-to-be 9954.  We have updated the reference to point to RFC 9954, in hopes it will complete AUTH48 around the same time as this document.
-->
   <reference anchor="I-D.ietf-tls-hybrid-design"> anchor="RFC9954" target="https://www.rfc-editor.org/info/rfc9954">

     <front>
       <title>Hybrid key exchange Key Exchange in TLS 1.3</title>

       <author fullname="Douglas Stebila" initials="D." surname="Stebila">
              <organization>University of Waterloo</organization> surname="Stebila" fullname="Douglas Stebila">
         <organization />
       </author>
       <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization> surname="Fluhrer" fullname="Scott Fluhrer">
         <organization />
       </author>
       <author fullname="Shay Gueron" initials="S." surname="Gueron">
              <organization>University of Haifa and Meta</organization> surname="Gueron" fullname="Shay Gueron">
         <organization />
       </author>

       <date day="7" month="September" year="2025"/>
            <abstract>
              <t>   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if a way is found to defeat the encryption for all but
   one of the component algorithms.  It is motivated by transition to
   post-quantum cryptography.  This document provides a construction for
   hybrid key exchange in the Transport Layer Security (TLS) protocol
   version 1.3.

              </t>
            </abstract> month="April" year="2026" />
     </front>
     <seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design-16"/> name="RFC" value="9954" />
     <seriesInfo name="DOI" value="10.17487/RFC9954"/>

   </reference>
<!--
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-hybrid-design.xml"/>
-->
      </references>
    </references>
    <?line 200?>

    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to Rifaat Shekh-Yusef, Martin Thomson, and Paul Wouters <contact fullname="Rifaat Shekh-Yusef"/>, <contact fullname="Martin Thomson"/>, and <contact fullname="Paul Wouters"/> for providing feedback on this document.</t>
    </section>
  </back>

  <!-- ##markdown-source:
H4sIAAAAAAAAA71Za3PjthX9jl+BKh+a7YjUw4+13ek08mOzmvpVy5ttZjrj
hUhIQkwSDEHKq3jd395zAVCkZDnpp3omWYkELu7z3HOhIAhYqcpEnvDOpZyL
aMXvJqPJZBTc/uNsMgiWg4cDHulY5lplpeEzXfD7ywkfhHsdJqbTQi6bnbTl
u8GbyyNRyrkuVifclDFjsY4ykeLguBCzMlCynAVlYui/wV6QP0ZmEPTfM1NN
U2WM0lm5yrF6fHH/gfPvuEiMxtEqw2ES/8vKTpd3ZKxKXSiR0Jfx6BT/QIXO
+O7+Q4dlVTqVxQmLocgJi3RmZGYqc8LLopIMhuwxUUgBqRMZVYUqVx32pIvH
eaGrHE/vC5GZXBclvxQrWfBm1VJmFURy/sdLOXd2dD5Dssrm/EfaQs9ToRI8
h/0/kDNCXczpsSiiBR4vyjI3J70eraJHainDelmPHvSmhX4ysof9Pdo3V+Wi
mjqBT/Ney630NoEPTNmSa1eFblOodHt97+0IhYsyTTqMiapcaLiWB5DNucrg
1c55yE9l9otIVdaxj128O+diqeKtV7BCZOo3USLQWPKj1vNE8svLM/daOufE
tHMqsx/m9n0Y6XTzyFHIb3WulxvnjbK4kKr9Yuu0KxUV2uhZyc90kYcbRwq7
Odc/pPUieyrLdJFi/9KG/e7D2XAwOPYfj/qD9/XH/f1D+vivw+P+iRVbV9s4
mzkJOuOljBaZTvR8xQM+mlyHAy4zlBGlx12VSFg2yWWkZipyG/SMnwqjIn6x
sYx/f3px967Lz0SmM6xNXr0/w3syiZ8rU+J5pcxCxq+WnWOZ84KtFT7s94f2
6zrO3LsRBXn/Kbi3D4wslDQKhtULxpOb3vji7IQfHQ0PgsGJl3N/ezUYbroD
j/iVUNmWoZdyKRM+5D/JgiAAQDLs8ju5VO7b4LDLbwWqbAjHTVDGUVkVMAD+
KReSztm0YgBI2Qv6g7dsuS8qU8IfZzrNq3JdnU5TUcwlKmZdMG5tVC+1pW+r
8SkPAC4lIKlX5YkWselBk4DMC0jbYBjQ90bfhyXsegCWwqCH/qC/R5qGeTxz
vtp2lVfyFjVMOcSvdFxRsahpIYrVpge7/AOKLFnxYdjvenf2+y0f9gfhwbH3
4uCEjwhakI+k15bvjgNy39H/33dnPz6QFx6KQX5w/ECaDh7aej7kgCzyFlN1
UbmyvPowGUHx/fd7mx5Ei+MTNc8E7eYfcK6E35B815NJZ4d9a2w5l4ndFlyK
pajijn+/xpkSbU/uXrV2437QPw6Gezv98vT0FKb6N5UkwnpDZsGnSc/45tET
MYKmqch66cwIK+z9Xg+ibm9uzi8vtvJkoYx/wafwFWyQX+FTZYND9TGZXPK9
sM9nIkmmInp82/bTEFkmk0QWWzaf6lhvvmoZOugHg/2dhtYmhQ7Ip8A+gtUe
besN+r0Suge51nEiA6t70KgeGJMEe33belgYhoyxIAi4mJqyEFHJmDUc9KJK
kUYgCokm6mEsMeEtZkIuqIwktNgiPf8G63lCK2RRokhGJIvSlRTEIE88pwm5
PaqQqV7ihQAwQwkRoRhJvtGp5KAniV6RJoaVmqdqXkAKx8daiFM/VTGMZew7
Ps7KAhUdUfnCGLeKPz/7dvLy4g+MualyyzHosB0WuC1oRtiiMnbWGAE4VbMV
T6UxYu5MmoklpLRcMZmE/PNCwZbmCYe1giUaQQB7ENPEtQ+zriWRgOHBcWnX
WZ84ZrgQRfwEbsWjYpWXGi7IF+heMUAokoYlyL0NY1RZn12hM6UpcMp7HT1m
iV7QpeAZWUvgJJsOLBVsYghqzKcru8FF0AV8RzThfdQ/CkOkeSK7/A1wRU8E
BJl39qBqqn6twDMrszaM7TQMSorSbgFtkBm3eiHyeaEJulr6tXVieaGWlCOP
cmVC/lE/AbWLLhcgbagi7mgshYpUchpliIX0opE67ZixdXSoAtIc6EhrKb1b
eYz2a9p9w0CSohrR1Dl4DMKW6ZLFckYI18qIOmzfGymJ5tq2fRAegcNAw+dn
2+tfXt65MyALIB0lVQxtGildPq1KrjP0KWCPkfXatSO3Ff804R/GtxM2ODoM
9nmEyptKlAV8GfMqJ0qlbWlTiRuRlEjEbI596A3oGx7+YoXcr1/Bv4YVEoEt
IMNmiz9TJQCqDX85Y0c5DR7qKz8N369ttaa6qkUfy5w/fCJAvxWMhMuiRWOZ
yODYXbgAQiNWpCtgwD0bQlfxaKzyr/OG9maypImFixIw9IhCYc/Pf7+9G/80
Ovv5b+c343DQD4d7x4Pj3v3VKATavg+PwMmOjgkjiBeKGBMUVAZqrpACyDwq
HtKYtZCMzwqd1mls3YkJAVpwMQfJMWQqMAxgjEYMS21xUF6gJkXGauWcTwX/
tRJZWaXc0QE8h87j4DxcDxyL1bRQcYCcQSq/vMC/o5aaXeuxDLNlqSxAk146
0glfOtZokBwI6C6fof7PPEBgGAR5sV8+op1pY9XTyMvHTD+RkU8LCc+7vuFw
CEuShFPWUCKV2s5BEODiYc3zCOhq+UxnpJMkpT2SYTcGRRztnQFbmNfbBqSF
2nf+nG291KydEVYl0oJtSW40Cfl4Ywud49TpWnWkDRwpqWczWIn3bO3fOj+7
TsI6yd3BMwxNPK5sMtL75tAu+Q84XjJKKwX0RIYhsSIpY1ScKL3gIZWPhh6R
Jg/bTCM6YEUDxaAUEMgo9PIUWM3niZ7abI2VsShYF6nr8HULt2sVgbxjBRkw
H7mGDFrTn5CmImpq8GktBDuQxoa9KuYnXSUx15QQTwpIM7UoDHdFpWs+Vmdl
TCXJcupl9YGsPhCJWaCg6bA/UwI6TgTdRLIy1GoRl1QQMy09rC+rJJOFsJgE
GojqdgTPFsX/wnsaXDTt4Lhk9/nA/ojukCoOhRBKWEgNLmuc6xsIjkKmwx+M
AuZGMkNbNKJEJD0C6pVq7peTsVUGJkh+qd3fYE5I1MjWT9asP6d2ZIHAkPm2
ZSIyRWww1H+a3NMtEP3Lr2/s57uLf34a312c0+fJx9Hl5fpDvWLy8ebTJd4z
/6nZeXZzdXVxfe424ynfenQ1+hn/kFadm9v78c316LJDzqM8YE1UClsayBaE
QxbwH6WLQNykiQo1xRfsOT275YN9R+DoYgHg/Pz8J2Jzg/f7Ly+MKsmdZXum
+wr3InfQlERBMhB/NJdclSIx1Ny4WeinjCNfpfWlv63D6HnQDEOTaIEQ8vtV
Lr1HZxp5ZGFme9FSJJWnXo4WuLZJ6bVBLhj7D/7cnQq4C3/2EwTnhREP9hrp
wSzE8ODwwSXk9/2v/f1h/11398K9o/3WwoO3Fx4Mhq2Fh+uFL9um/NVpaO0V
U8DORskoNHmL52IX0YW99uLkFf1mbfptHeLwsvCwTLsWwixaomwaOE+CryPi
k4+Tumsfokv3rseT+5CITzg46gfIBCpJirqtQMLAViBavA/SWnD/5iDgGABk
ESPZjilSyqIds/P51xLtbJzxHNO4iiow06ajUWY7+5DpmFnpOAhoEXy2Y1rZ
UNf5qg1DeJACTmjOQiIT9nocY1+aoP/lCzUkTCYUt8aV7eEJ6Vh3/BoZWjo6
iPKZ7dX4stbsYR0q88WieUZtmvnbphZ38GFpDkCXy8ud0p3T3h7OoO/E+9X1
HYxcFlq9N+v5psU8LFdpuMcOZwc2WSzuA7Yc9dmhHPsj0+uLth0kZSOlrPmU
guk6tn+QimC/3urdTqQCZXWBzmzCWq7i4v37OrVSwLrJ8vF2LySfNHyndU3g
zl47hTVOISVqBWzzryMbcl4f1nSUTempu2uwR9sY17FtD0hE+eYLxyqIE5DF
U+qmxLLpqhc5EaOZFCkNaCh4wn90g6Qe6EK+MeiChMs0L32V0o8BwDdqnxY6
vAKYShYY+pTJExwp1kH15A5eKYhmLQQg04KD42XS0iDj56BtXuDdUNO1Jp41
4E4tjokqKSkLJICwpkZ0N0gnFE6UrWa0svrXFeIHrdcO0De3ODRQrSsWoHOs
rTvJWytHWyy5p4DQPYZXMZNPrK0mASWcNVVxDF670fq8gI1Boz00E4SqDDnJ
HBfYmDtr7lPD6brB+CHCkjBEWaXqN0/DHEulAaQ1Q0fC4DVYKwWtsIZ5frWb
Xn229LwOli0k262ikiaBHYgtYvA30yqHmb1JBS+Fi5u7V+pS460ccNcUdrgt
aExD5dOXpgewumOaVq/1YNCw+F1Kmfoiw0GBcaydHWF6tkP6uim/6l9Ruy/4
Wwrr3hQgJkoNH15/urxk2CNSKrUaas7tRQL9osNNfalvga++jRGEqwp89eIO
GtCPQSBx9U88W1BXyF/obqjVDjE90IWBS9JUyhoDfdbYidwVwnh0PXpVBPah
5e0WBd0VVITBw2Nbw/AgyEbPoz9lyTbpK+RcwcaV7XCgxZKu5+j317iDrE6q
NGO+PU8JASknwZY9MS7dFkLJLJL1Bv5qQ9keZGDZN/4TtSXOv3FQfuLJ7jph
99839i3wf+sPv/eH9dwxTsj/8gYn/cL9soMdyxpGul52uGNZw0dpmbv2pTGQ
IjeKaJpPZDx38WTPJ+6eT8Z/62BeNLLzQngmskc7Wd2pmUCnmCzk4yL4GcAz
6/IrymVMawudGu3ng1vAKP+s6VrF3YEiJZfKkrMZBm86nma3LY//F7805bkX
IAAA [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>