doc: Add RFC documents

1 files changed, 578 insertions, 0 deletions

diff --git a/doc/rfc/rfc8773.txt b/doc/rfc/rfc8773.txt
new file mode 100644
index 0000000..97dcad9
--- /dev/null
+++ b/doc/rfc/rfc8773.txt
@@ -0,0 +1,578 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Housley
+Request for Comments: 8773                                Vigil Security
+Category: Experimental                                        March 2020
+ISSN: 2070-1721
+
+
+TLS 1.3 Extension for Certificate-Based Authentication with an External
+                             Pre-Shared Key
+
+Abstract
+
+   This document specifies a TLS 1.3 extension that allows a server to
+   authenticate with a combination of a certificate and an external pre-
+   shared key (PSK).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are candidates for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8773.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Motivation and Design Rationale
+   4.  Extension Overview
+   5.  Certificate with External PSK Extension
+     5.1.  Companion Extensions
+     5.2.  Authentication
+     5.3.  Keying Material
+   6.  IANA Considerations
+   7.  Security Considerations
+   8.  Privacy Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgments
+   Author's Address
+
+1.  Introduction
+
+   The TLS 1.3 [RFC8446] handshake protocol provides two mutually
+   exclusive forms of server authentication.  First, the server can be
+   authenticated by providing a signature certificate and creating a
+   valid digital signature to demonstrate that it possesses the
+   corresponding private key.  Second, the server can be authenticated
+   by demonstrating that it possesses a pre-shared key (PSK) that was
+   established by a previous handshake.  A PSK that is established in
+   this fashion is called a resumption PSK.  A PSK that is established
+   by any other means is called an external PSK.  This document
+   specifies a TLS 1.3 extension permitting certificate-based server
+   authentication to be combined with an external PSK as an input to the
+   TLS 1.3 key schedule.
+
+   Several implementors wanted to gain more experience with this
+   specification before producing a Standards Track RFC.  As a result,
+   this specification is being published as an Experimental RFC to
+   enable interoperable implementations and gain deployment and
+   operational experience.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Motivation and Design Rationale
+
+   The development of a large-scale quantum computer would pose a
+   serious challenge for the cryptographic algorithms that are widely
+   deployed today, including the digital signature algorithms that are
+   used to authenticate the server in the TLS 1.3 handshake protocol.
+   It is an open question whether or not it is feasible to build a
+   large-scale quantum computer, and if so, when that might happen.
+   However, if such a quantum computer is invented, many of the
+   cryptographic algorithms and the security protocols that use them
+   would become vulnerable.
+
+   The TLS 1.3 handshake protocol employs key agreement algorithms and
+   digital signature algorithms that could be broken by the development
+   of a large-scale quantum computer [TRANSITION].  The key agreement
+   algorithms include Diffie-Hellman (DH) [DH1976] and Elliptic Curve
+   Diffie-Hellman (ECDH) [IEEE1363]; the digital signature algorithms
+   include RSA [RFC8017] and the Elliptic Curve Digital Signature
+   Algorithm (ECDSA) [FIPS186].  As a result, an adversary that stores a
+   TLS 1.3 handshake protocol exchange today could decrypt the
+   associated encrypted communications in the future when a large-scale
+   quantum computer becomes available.
+
+   In the near term, this document describes a TLS 1.3 extension to
+   protect today's communications from the future invention of a large-
+   scale quantum computer by providing a strong external PSK as an input
+   to the TLS 1.3 key schedule while preserving the authentication
+   provided by the existing certificate and digital signature
+   mechanisms.
+
+4.  Extension Overview
+
+   This section provides a brief overview of the
+   "tls_cert_with_extern_psk" extension.
+
+   The client includes the "tls_cert_with_extern_psk" extension in the
+   ClientHello message.  The "tls_cert_with_extern_psk" extension MUST
+   be accompanied by the "key_share", "psk_key_exchange_modes", and
+   "pre_shared_key" extensions.  The client MAY also find it useful to
+   include the "supported_groups" extension.  Since the
+   "tls_cert_with_extern_psk" extension is intended to be used only with
+   initial handshakes, it MUST NOT be sent alongside the "early_data"
+   extension.  These extensions are all described in Section 4.2 of
+   [RFC8446], which also requires the "pre_shared_key" extension to be
+   the last extension in the ClientHello message.
+
+   If the client includes both the "tls_cert_with_extern_psk" extension
+   and the "early_data" extension, then the server MUST terminate the
+   connection with an "illegal_parameter" alert.
+
+   If the server is willing to use one of the external PSKs listed in
+   the "pre_shared_key" extension and perform certificate-based
+   authentication, then the server includes the
+   "tls_cert_with_extern_psk" extension in the ServerHello message.  The
+   "tls_cert_with_extern_psk" extension MUST be accompanied by the
+   "key_share" and "pre_shared_key" extensions.  If none of the external
+   PSKs in the list provided by the client is acceptable to the server,
+   then the "tls_cert_with_extern_psk" extension is omitted from the
+   ServerHello message.
+
+   When the "tls_cert_with_extern_psk" extension is successfully
+   negotiated, the TLS 1.3 key schedule processing includes both the
+   selected external PSK and the (EC)DHE shared secret value.  (EC)DHE
+   refers to Diffie-Hellman over either finite fields or elliptic
+   curves.  As a result, the Early Secret, Handshake Secret, and Master
+   Secret values all depend upon the value of the selected external PSK.
+   Of course, the Early Secret does not depend upon the (EC)DHE shared
+   secret.
+
+   The authentication of the server and optional authentication of the
+   client depend upon the ability to generate a signature that can be
+   validated with the public key in their certificates.  The
+   authentication processing is not changed in any way by the selected
+   external PSK.
+
+   Each external PSK is associated with a single hash algorithm, which
+   is required by Section 4.2.11 of [RFC8446].  The hash algorithm MUST
+   be set when the PSK is established, with a default of SHA-256.
+
+5.  Certificate with External PSK Extension
+
+   This section specifies the "tls_cert_with_extern_psk" extension,
+   which MAY appear in the ClientHello message and ServerHello message.
+   It MUST NOT appear in any other messages.  The
+   "tls_cert_with_extern_psk" extension MUST NOT appear in the
+   ServerHello message unless the "tls_cert_with_extern_psk" extension
+   appeared in the preceding ClientHello message.  If an implementation
+   recognizes the "tls_cert_with_extern_psk" extension and receives it
+   in any other message, then the implementation MUST abort the
+   handshake with an "illegal_parameter" alert.
+
+   The general extension mechanisms enable clients and servers to
+   negotiate the use of specific extensions.  Clients request extended
+   functionality from servers with the extensions field in the
+   ClientHello message.  If the server responds with a HelloRetryRequest
+   message, then the client sends another ClientHello message as
+   described in Section 4.1.2 of [RFC8446], including the same
+   "tls_cert_with_extern_psk" extension as the original ClientHello
+   message, or aborts the handshake.
+
+   Many server extensions are carried in the EncryptedExtensions
+   message; however, the "tls_cert_with_extern_psk" extension is carried
+   in the ServerHello message.  Successful negotiation of the
+   "tls_cert_with_extern_psk" extension affects the key used for
+   encryption, so it cannot be carried in the EncryptedExtensions
+   message.  Therefore, the "tls_cert_with_extern_psk" extension is only
+   present in the ServerHello message if the server recognizes the
+   "tls_cert_with_extern_psk" extension and the server possesses one of
+   the external PSKs offered by the client in the "pre_shared_key"
+   extension in the ClientHello message.
+
+   The Extension structure is defined in [RFC8446]; it is repeated here
+   for convenience.
+
+     struct {
+         ExtensionType extension_type;
+         opaque extension_data<0..2^16-1>;
+     } Extension;
+
+   The "extension_type" identifies the particular extension type, and
+   the "extension_data" contains information specific to the particular
+   extension type.
+
+   This document specifies the "tls_cert_with_extern_psk" extension,
+   adding one new type to ExtensionType:
+
+     enum {
+         tls_cert_with_extern_psk(33), (65535)
+     } ExtensionType;
+
+   The "tls_cert_with_extern_psk" extension is relevant when the client
+   and server possess an external PSK in common that can be used as an
+   input to the TLS 1.3 key schedule.  The "tls_cert_with_extern_psk"
+   extension is essentially a flag to use the external PSK in the key
+   schedule, and it has the following syntax:
+
+     struct {
+         select (Handshake.msg_type) {
+             case client_hello: Empty;
+             case server_hello: Empty;
+         };
+     } CertWithExternPSK;
+
+5.1.  Companion Extensions
+
+   Section 4 lists the extensions that are required to accompany the
+   "tls_cert_with_extern_psk" extension.  Most of those extensions are
+   not impacted in any way by this specification.  However, this section
+   discusses the extensions that require additional consideration.
+
+   The "psk_key_exchange_modes" extension is defined in of Section 4.2.9
+   of [RFC8446].  The "psk_key_exchange_modes" extension restricts the
+   use of both the PSKs offered in this ClientHello and those that the
+   server might supply via a subsequent NewSessionTicket.  As a result,
+   when the "psk_key_exchange_modes" extension is included in the
+   ClientHello message, clients MUST include psk_dhe_ke mode.  In
+   addition, clients MAY also include psk_ke mode to support a
+   subsequent NewSessionTicket.  When the "psk_key_exchange_modes"
+   extension is included in the ServerHello message, servers MUST select
+   the psk_dhe_ke mode for the initial handshake.  Servers MUST select a
+   key exchange mode that is listed by the client for subsequent
+   handshakes that include the resumption PSK from the initial
+   handshake.
+
+   The "pre_shared_key" extension is defined in Section 4.2.11 of
+   [RFC8446].  The syntax is repeated below for convenience.  All of the
+   listed PSKs MUST be external PSKs.  If a resumption PSK is listed
+   along with the "tls_cert_with_extern_psk" extension, the server MUST
+   abort the handshake with an "illegal_parameter" alert.
+
+     struct {
+         opaque identity<1..2^16-1>;
+         uint32 obfuscated_ticket_age;
+     } PskIdentity;
+
+     opaque PskBinderEntry<32..255>;
+
+     struct {
+         PskIdentity identities<7..2^16-1>;
+         PskBinderEntry binders<33..2^16-1>;
+     } OfferedPsks;
+
+     struct {
+         select (Handshake.msg_type) {
+             case client_hello: OfferedPsks;
+             case server_hello: uint16 selected_identity;
+         };
+     } PreSharedKeyExtension;
+
+   "OfferedPsks" contains the list of PSK identities and associated
+   binders for the external PSKs that the client is willing to use with
+   the server.
+
+   The identities are a list of external PSK identities that the client
+   is willing to negotiate with the server.  Each external PSK has an
+   associated identity that is known to the client and the server; the
+   associated identities may be known to other parties as well.  In
+   addition, the binder validation (see below) confirms that the client
+   and server have the same key associated with the identity.
+
+   The "obfuscated_ticket_age" is not used for external PSKs.  As stated
+   in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0,
+   and servers MUST ignore the value.
+
+   The binders are a series of HMAC [RFC2104] values, one for each
+   external PSK offered by the client, in the same order as the
+   identities list.  The HMAC value is computed using the binder_key,
+   which is derived from the external PSK, and a partial transcript of
+   the current handshake.  Generation of the binder_key from the
+   external PSK is described in Section 7.1 of [RFC8446].  The partial
+   transcript of the current handshake includes a partial ClientHello up
+   to and including the PreSharedKeyExtension.identities field, as
+   described in Section 4.2.11.2 of [RFC8446].
+
+   The "selected_identity" contains the index of the external PSK
+   identity that the server selected from the list offered by the
+   client.  As described in Section 4.2.11 of [RFC8446], the server MUST
+   validate the binder value that corresponds to the selected external
+   PSK, and if the binder does not validate, the server MUST abort the
+   handshake with an "illegal_parameter" alert.
+
+5.2.  Authentication
+
+   When the "tls_cert_with_extern_psk" extension is successfully
+   negotiated, authentication of the server depends upon the ability to
+   generate a signature that can be validated with the public key in the
+   server's certificate.  This is accomplished by the server sending the
+   Certificate and CertificateVerify messages, as described in Sections
+   4.4.2 and 4.4.3 of [RFC8446].
+
+   TLS 1.3 does not permit the server to send a CertificateRequest
+   message when a PSK is being used.  This restriction is removed when
+   the "tls_cert_with_extern_psk" extension is negotiated, allowing
+   certificate-based authentication for both the client and the server.
+   If certificate-based client authentication is desired, this is
+   accomplished by the client sending the Certificate and
+   CertificateVerify messages as described in Sections 4.4.2 and 4.4.3
+   of [RFC8446].
+
+5.3.  Keying Material
+
+   Section 7.1 of [RFC8446] specifies the TLS 1.3 key schedule.  The
+   successful negotiation of the "tls_cert_with_extern_psk" extension
+   requires the key schedule processing to include both the external PSK
+   and the (EC)DHE shared secret value.
+
+   If the client and the server have different values associated with
+   the selected external PSK identifier, then the client and the server
+   will compute different values for every entry in the key schedule,
+   which will lead to the client aborting the handshake with a
+   "decrypt_error" alert.
+
+6.  IANA Considerations
+
+   IANA has updated the "TLS ExtensionType Values" registry [IANA] to
+   include "tls_cert_with_extern_psk" with a value of 33 and the list of
+   messages "CH, SH" in which the "tls_cert_with_extern_psk" extension
+   may appear.
+
+7.  Security Considerations
+
+   The Security Considerations in [RFC8446] remain relevant.
+
+   TLS 1.3 [RFC8446] does not permit the server to send a
+   CertificateRequest message when a PSK is being used.  This
+   restriction is removed when the "tls_cert_with_extern_psk" extension
+   is offered by the client and accepted by the server.  However, TLS
+   1.3 does not permit an external PSK to be used in the same fashion as
+   a resumption PSK, and this extension does not alter those
+   restrictions.  Thus, a certificate MUST NOT be used with a resumption
+   PSK.
+
+   Implementations must protect the external pre-shared key (PSK).
+   Compromise of the external PSK will make the encrypted session
+   content vulnerable to the future development of a large-scale quantum
+   computer.  However, the generation, distribution, and management of
+   the external PSKs is out of scope for this specification.
+
+   Implementers should not transmit the same content on a connection
+   that is protected with an external PSK and a connection that is not.
+   Doing so may allow an eavesdropper to correlate the connections,
+   making the content vulnerable to the future invention of a large-
+   scale quantum computer.
+
+   Implementations must generate external PSKs with a secure key-
+   management technique, such as pseudorandom generation of the key or
+   derivation of the key from one or more other secure keys.  The use of
+   inadequate pseudorandom number generators (PRNGs) to generate
+   external PSKs can result in little or no security.  An attacker may
+   find it much easier to reproduce the PRNG environment that produced
+   the external PSKs and search the resulting small set of
+   possibilities, rather than brute-force searching the whole key space.
+   The generation of quality random numbers is difficult.  [RFC4086]
+   offers important guidance in this area.
+
+   If the external PSK is known to any party other than the client and
+   the server, then the external PSK MUST NOT be the sole basis for
+   authentication.  The reasoning is explained in Section 4.2 of
+   [K2016].  When this extension is used, authentication is based on
+   certificates, not the external PSK.
+
+   In this extension, the external PSK preserves confidentiality if the
+   (EC)DH key agreement is ever broken by cryptanalysis or the future
+   invention of a large-scale quantum computer.  As long as the attacker
+   does not know the PSK and the key derivation algorithm remains
+   unbroken, the attacker cannot derive the session secrets, even if
+   they are able to compute the (EC)DH shared secret.  Should the
+   attacker be able compute the (EC)DH shared secret, the forward-
+   secrecy advantages traditionally associated with ephemeral (EC)DH
+   keys will no longer be relevant.  Although the ephemeral private keys
+   used during a given TLS session are destroyed at the end of a
+   session, preventing the attacker from later accessing them, these
+   private keys would nevertheless be recoverable due to the break in
+   the algorithm.  However, a more general notion of "secrecy after key
+   material is destroyed" would still be achievable using external PSKs,
+   if they are managed in a way that ensures their destruction when they
+   are no longer needed, and with the assumption that the algorithms
+   that use the external PSKs remain quantum-safe.
+
+   TLS 1.3 key derivation makes use of the HMAC-based Key Derivation
+   Function (HKDF) algorithm, which depends upon the HMAC [RFC2104]
+   construction and a hash function.  This extension provides the
+   desired protection for the session secrets, as long as HMAC with the
+   selected hash function is a pseudorandom function (PRF) [GGM1986].
+
+   This specification does not require that the external PSK is known
+   only by the client and server.  The external PSK may be known to a
+   group.  Since authentication depends on the public key in a
+   certificate, knowledge of the external PSK by other parties does not
+   enable impersonation.  Since confidentiality depends on the shared
+   secret from (EC)DH, knowledge of the external PSK by other parties
+   does not enable eavesdropping.  However, group members can record the
+   traffic of other members and then decrypt it if they ever gain access
+   to a large-scale quantum computer.  Also, when many parties know the
+   external PSK, there are many opportunities for theft of the external
+   PSK by an attacker.  Once an attacker has the external PSK, they can
+   decrypt stored traffic if they ever gain access to a large-scale
+   quantum computer, in the same manner as a legitimate group member.
+
+   TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are
+   bound to a specific hash function and KDF.  By contrast, TLS 1.2
+   [RFC5246] allows PSKs to be used with any hash function and the TLS
+   1.2 PRF.  Thus, the safest approach is to use a PSK exclusively with
+   TLS 1.2 or exclusively with TLS 1.3.  Given one PSK, one can derive a
+   PSK for exclusive use with TLS 1.2 and derive another PSK for
+   exclusive use with TLS 1.3 using the mechanism specified in [IMPORT].
+
+   TLS 1.3 [RFC8446] has received careful security analysis, and the
+   following informal reasoning shows that the addition of this
+   extension does not introduce any security defects.  This extension
+   requires the use of certificates for authentication, but the
+   processing of certificates is unchanged by this extension.  This
+   extension places an external PSK in the key schedule as part of the
+   computation of the Early Secret.  In the initial handshake without
+   this extension, the Early Secret is computed as:
+
+      Early Secret = HKDF-Extract(0, 0)
+
+   With this extension, the Early Secret is computed as:
+
+      Early Secret = HKDF-Extract(External PSK, 0)
+
+   Any entropy contributed by the external PSK can only make the Early
+   Secret better; the External PSK cannot make it worse.  For these two
+   reasons, TLS 1.3 continues to meet its security goals when this
+   extension is used.
+
+8.  Privacy Considerations
+
+   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
+   PSKs.  The guidance in this section remains relevant.
+
+   This extension makes use of external PSKs to improve resilience
+   against attackers that gain access to a large-scale quantum computer
+   in the future.  This extension is always accompanied by the
+   "pre_shared_key" extension to provide the PSK identities in plaintext
+   in the ClientHello message.  Passive observation of the these PSK
+   identities will aid an attacker in tracking users of this extension.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+9.2.  Informative References
+
+   [DH1976]   Diffie, W. and M. Hellman, "New Directions in
+              Cryptography", IEEE Transactions on Information Theory,
+              Vol. 22, No. 6, DOI 10.1109/TIT.1976.1055638, November
+              1976, <https://ieeexplore.ieee.org/document/1055638>.
+
+   [FIPS186]  NIST, "Digital Signature Standard (DSS)", Federal
+              Information Processing Standards Publication (FIPS) 186-4,
+              DOI 10.6028/NIST.FIPS.186-4, July 2013,
+              <https://doi.org/10.6028/NIST.FIPS.186-4>.
+
+   [GGM1986]  Goldreich, O., Goldwasser, S., and S. Micali, "How to
+              construct random functions", Journal of the ACM, Vol. 33,
+              No. 4, pp. 792-807, DOI 10.1145/6490.6503, August 1986,
+              <https://doi.org/10.1145/6490.6503>.
+
+   [IANA]     IANA, "TLS ExtensionType Values",
+              <https://www.iana.org/assignments/tls-extensiontype-
+              values/tls-extensiontype-values.xhtml>.
+
+   [IEEE1363] IEEE, "IEEE Standard Specifications for Public-Key
+              Cryptography", IEEE Std 1363-2000,
+              DOI 10.1109/IEEESTD.2000.92292, August 2000,
+              <https://ieeexplore.ieee.org/document/891000>.
+
+   [IMPORT]   Benjamin, D. and C. Wood, "Importing External PSKs for
+              TLS", Work in Progress, Internet-Draft, draft-ietf-tls-
+              external-psk-importer-03, 15 February 2020,
+              <https://tools.ietf.org/html/draft-ietf-tls-external-psk-
+              importer-03>.
+
+   [K2016]    Krawczyk, H., "A Unilateral-to-Mutual Authentication
+              Compiler for Key Exchange (with Applications to Client
+              Authentication in TLS 1.3)", CCS '16: Proceedings of the
+              2016 ACM Communications Security, pp. 1438-50,
+              DOI 10.1145/2976749.2978325, October 2016,
+              <https://dl.acm.org/doi/10.1145/2976749.2978325>.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <https://www.rfc-editor.org/info/rfc2104>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
+              "PKCS #1: RSA Cryptography Specifications Version 2.2",
+              RFC 8017, DOI 10.17487/RFC8017, November 2016,
+              <https://www.rfc-editor.org/info/rfc8017>.
+
+   [TRANSITION]
+              Hoffman, P., "The Transition from Classical to Post-
+              Quantum Cryptography", Work in Progress, Internet-Draft,
+              draft-hoffman-c2pq-06, 25 November 2019,
+              <https://tools.ietf.org/html/draft-hoffman-c2pq-06>.
+
+Acknowledgments
+
+   Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian
+   Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja Kühlewind,
+   Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee
+   for their review and comments; their efforts have improved this
+   document.
+
+Author's Address
+
+   Russ Housley
+   Vigil Security, LLC
+   516 Dranesville Road
+   Herndon, VA 20170
+   United States of America
+
+   Email: housley@vigilsec.com