Network Working Group                                          R. Barnes
Internet-Draft                                                   Mozilla
Intended status: Standards Track                              S. Iyengar
Expires: January 3, February 18, 2019                                      Facebook
                                                             N. Sullivan
                                                              Cloudflare
                                                             E. Rescorla
                                                              RTFM, Inc.
                                                           July 02,
                                                         August 17, 2018

                     Delegated Credentials for TLS
                       draft-ietf-tls-subcerts-01
                       draft-ietf-tls-subcerts-02

Abstract

   The organizational separation between the operator of a TLS server
   and the certificate certification authority that provides it credentials can cause
   problems, for example when it comes to reducing create limitations.  For example,
   the lifetime of
   certificates or supporting new cryptographic algorithms. certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism to allow TLS server by
   which operators to
   create may delegate their own credential delegations credentials for use in TLS,
   without breaking compatibility with clients that do not support this
   specification.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/. https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, February 18, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (http://trustee.ietf.org/license-info)
   (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
     1.1.  Change Log  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   3   4
     2.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .   4   5
     2.2.  Related Work  . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Client and Server behavior  . .  Delegated Credentials . . . . . . . . . . . . . . .   6
   4.  Delegated Credentials . . . . .   6
     3.1.  Client and Server behavior  . . . . . . . . . . . . . . .   7
     4.1.   8
     3.2.  Certificate Requirements  . . . . . . . . . . . . . . . .   8
   5.   9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     6.1.  10
     5.1.  Security of delegated private key . . . . . . . . . . . .   9
     6.2.  10
     5.2.  Revocation of delegated credentials . . . . . . . . . . .   9
     6.3.  10
     5.3.  Privacy considerations  . . . . . . . . . . . . . . . . .   9
   7.  10
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11  12

1.  Introduction

   Typically, a TLS server uses a certificate provided by some entity
   other than the operator of the server (a "Certification Authority" or
   CA) [RFC5246] [RFC8446] [RFC5280].  This organizational separation makes the
   TLS server operator dependent on the CA for some aspects of its
   operations, for example:

   o  Whenever the server operator wants to deploy a new certificate, it
      has to interact with the CA.

   o  The server operator can only use TLS authentication schemes for
      which the CA will issue credentials.

   These dependencies cause problems in practice.  Server operators
   often want to create short-lived certificates for servers in low-
   trust zones such as CDNs or remote data centers.  This allows server
   operators to limit the exposure of keys in cases that they do not
   realize a compromise has occurred.  The risk inherent in cross-
   organizational transactions makes it operationally infeasible to rely
   on an external CA for such short-lived credentials.  In OCSP
   stapling, stapling
   (i.e., using the Certificate Status extension types ocsp [RFC6066] or
   ocsp_multi [RFC6961]), if an operator chooses to talk frequently to
   the CA to obtain stapled responses, then failure to fetch an OCSP
   stapled response results only in degraded performance.  On the other
   hand, failure to fetch a potentially large number of short lived
   certificates would result in the service not being available available, which
   creates greater operational risk.

   To remove these dependencies, this document proposes a limited
   delegation mechanism that allows a TLS server operator to issue its
   own credentials within the scope of a certificate issued by an
   external CA.  Because the above problems do not relate to the CAs CA's
   inherent function of validating possession of names, it is safe to
   make such delegations as long as they only enable the recipient of
   the delegation to speak for names that the CA has authorized.  For
   clarity, we will refer to the certificate issued by the CA as a
   "certificate"
   "certificate", or "delegation certificate", and the one issued by the
   operator as a "delegated credential".

1.1.  Change Log

   (*) indicates changes to the wire protocol.

   draft-02

   o  Change public key type. (*)

   o  Change DelegationUsage extension to be NULL and define its object
      identifier.

   o  Drop support for TLS 1.2.

   o  Add the protocol version and credential signature algorithm to the
      Credential structure. (*)

   o  Specify undefined behavior in a few cases: when the client
      receives a DC without indicated support; when the client indicates
      the extension in an invalid protocol version; and when DCs are
      sent as extensions to certificates other than the end-entity
      certificate.

2.  Solution Overview

   A delegated credential is a digitally signed data structure with the
   following two
   semantic fields:

   o  A a validity interval

   o  A and a public key (with (along with its
   associated algorithm) signature algorithm).  The signature on the credential
   indicates a delegation from the certificate that is issued to the TLS
   server operator.  The secret key used to sign a credential is presumed
   corresponds to be one whose
   corresponding the public key is contained in an X.509 certificate that
   associates one or more names to of the credential. TLS server's X.509 end-entity
   certificate.

   A TLS handshake that uses delegated credentials differs from a normal
   handshake in a few important ways:

   o  The client provides an extension in its ClientHello that indicates
      support for this mechanism.

   o  The server provides both the certificate chain terminating in its
      certificate as well as the delegated credential.

   o  The client uses information in the server's certificate to verify
      the signature on the delegated credential and verify that the server is asserting an
      expected identity.

   o  The client uses the public key in the credential as the server's
      working key for the TLS handshake.

   Delegated credentials can be used either

   As detailed in TLS 1.3 or TLS 1.2.
   Differences between Section 3, the use of delegated credentials in the protocols
   are credential is
   cryptographically bound to the end-entity certificate and the
   protocol in which the credential may be used.  This document
   specifies the use of delegated credentials in TLS 1.3 or later; their
   use in prior versions of the protocol is explicitly stated. disallowed.

   Delegated credentials allow the server to terminate TLS connections
   on behalf of the certificate owner.  If a credential is stolen, there
   is no mechanism for revoking it without revoking the certificate
   itself.  To limit exposure in case a delegated credential is
   compromised, servers may not issue credentials with a validity period
   longer than 7 days.  This mechanism is described in detail in
   Section 3.1.

   It was noted in [XPROT] that certificates in use by servers that
   support outdated protocols such as SSLv2 can be used to forge
   signatures for certificates that contain the keyEncipherment KeyUsage
   ([RFC5280] section 4.2.1.3) 4.2.1.3).  In order to prevent this type of cross-
   protocol attack, we define a new DelegationUsage extension to X.509
   that permits use of delegated credentials.  Clients MUST NOT accept
   delegated credentials associated with certificates without this
   extension.

   Credentials allow the server to terminate TLS connections on behalf
   of the certificate owner.  If a credential is stolen, there is no
   mechanism for revoking it without revoking the certificate itself.
   To limit the exposure of a delegation credential compromise, servers
   MUST NOT issue credentials with a validity period longer than 7 days.
   Clients MUST NOT accept credentials with longer validity periods.  (See Section 3.2.)

2.1.  Rationale

   Delegated credentials present a better alternative than other
   delegation mechanisms like proxy certificates [RFC3820] for several
   reasons:

   o  There is no change needed to certificate validation at the PKI
      layer.

   o  X.509 semantics are very rich.  This can cause unintended
      consequences if a service owner creates a proxy cert certificate where
      the properties differ from the leaf certificate.

   o  Delegated  For this reason,
      delegated credentials have very restricted semantics which should
      not conflict with X.509 semantics.

   o  Proxy certificates rely on the certificate path building process
      to establish a binding between the proxy certificate and the
      server certificate.  Since the cert certificate path building process
      is not cryptographically protected, it is possible that a proxy
      certificate could be bound to another certificate with the same
      public key, with different X.509 parameters.  Delegated
      credentials, which rely on a cryptographic binding between the
      entire certificate and the delegated credential, cannot.

   o  Delegated credentials are  Each delegated credential is bound to a specific versions version of TLS. TLS
      and signature algorithm.  This prevents them from being used for
      other protocols if a or with other signature algorithms than service
      owner allows multiple versions of TLS. allows.

2.2.  Related Work

   Many of the use cases for delegated credentials can also be addressed
   using purely server-side mechanisms that do not require changes to
   client behavior (e.g., LURK [I-D.mglt-lurk-tls-requirements]).  These
   mechanisms, however, incur per-transaction latency, since the front-
   end server has to interact with a back-end server that holds a
   private key.  The mechanism proposed in this document allows the
   delegation to be done off-line, with no per-transaction latency.  The
   figure below compares the message flows for these two mechanisms with
   TLS 1.3 [I-D.ietf-tls-tls13]. [I-D.ietf-tls-tls13], where DC is delegated credentials.

   LURK:

   Client            Front-End            Back-End
     |----ClientHello--->|                    |
     |<---ServerHello----|                    |
     |<---Certificate----|                    |
     |                   |<-------LURK------->|
     |<---CertVerify-----|                    |
     |        ...        |                    |

   Delegated credentials:

   Client            Front-End            Back-End
     |                   |<--Cred Provision-->|                   |<----DC minting---->|
     |----ClientHello--->|                    |
     |<---ServerHello----|                    |
     |<---Certificate----|                    |
     |<---CertVerify-----|                    |
     |        ...        |                    |

   These two mechanisms can be complementary.  A server could use
   credentials for clients that support them, while using LURK to
   support legacy clients.

   It is possible to address the short-lived certificate concerns above
   by automating certificate issuance, e.g., with ACME
   [I-D.ietf-acme-acme].  In addition to requiring frequent
   operationally-critical interactions with an external party, this
   makes the server operator dependent on the CA's willingness to issue
   certificates with sufficiently short lifetimes.  It also fails to
   address the issues with algorithm support.  Nonetheless, existing
   automated issuance APIs like ACME may be useful for provisioning
   credentials, within an operator network.

3.  Client and Server behavior

   This document defines  Delegated Credentials

   While X.509 forbids end-entity certificates from being used as
   issuers for other certificates, it is perfectly fine to use them to
   issue other signed objects as long as the following extension code point.

       enum {
         ...
         delegated_credential(TBD),
         (65535)
       } ExtensionType;

   A client which supports certificate contains the
   digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new
   signed object format that would encode only the semantics that are
   needed for this document SHALL send an empty
   "delegated_credential" extension in its ClientHello.

   If application.  The credential has the extension is present, following
   structure:

      struct {
        uint32 valid_time;
        SignatureScheme expected_cert_verify_algorithm;
        ProtocolVersion expected_version;
        opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
      } Credential;

   valid_time:  Relative time in seconds from the server MAY send a
   DelegatedCredential extension.  If beginning of the extension is not present,
      delegation certificate's notBefore value after which the
   server MUST NOT send a credential.  A delegated
      credential MUST NOT be provided
   unless a Certificate message is also sent.

   When negotiating TLS 1.3, and using Delegated credentials, no longer valid.

   expected_cert_verify_algorithm:  The signature algorithm of the server
   MUST send
      credential key pair, where the DelegatedCredential type SignatureScheme is as an extension defined
      in [RFC8446].  This is expected to be the
   CertificateEntry same as
      CertificateVerify.algorithm sent by the server.

   expected_version:  The version of its end-entity certificate.  When negotiating TLS
   1.2, the DelegatedCredential MUST be sent as an extension in which the
   ServerHello.

   The DelegatedCredential contains a signature from credential will be
      used, where the public key type ProtocolVersion is as defined in [RFC8446].
      This is expected to match the end-entity certificate using a signature algorithm advertised protocol version that is negotiated
      by the client in the "signature_algorithms" extension.  Additionally,
   the and server.

   ASN1_subjectPublicKeyInfo:  The credential's public key MUST be of key, a type that enables at least
   one of the supported signature algorithms.  A DER-
      encoded [X690] SubjectPublicKeyInfo as defined in [RFC5280].

   The delegated credential
   MUST NOT be negotiated by has the server if its following structure:

      struct {
        Credential cred;
        SignatureScheme algorithm;
        opaque signature<0..2^16-1>;
      } DelegatedCredential;

   algorithm:  The signature is not
   compatible with any of the supported algorithm used to verify
      DelegatedCredential.signature.

   signature:  The signature algorithms or over the
   credential's public key is not usable credential with the supported signature
   algorithms of the client, even if the client advertises support for
   delegated credentials.

   On receiving a credential and a certificate chain, the client
   validates the certificate chain and matches the end-entity
   certificate to the server's expected identity following its normal
   procedures.  It then takes the following steps:

   o  Verify that the current time is within
      certificate's public key, using the validity interval scheme.

   The signature of the credential and that the credential's time to live DelegatedCredential is no more
      than 7 days.

   o  Verify that the certificate has the DelegationUsage extension,
      which permits computed over the use
   concatenation of:

   1.  A string that consists of Delegated credentials.

   o  Use the public key in octet 32 (0x20) repeated 64 times.

   2.  The context string "TLS, server delegated credentials".

   3.  A single 0 byte, which serves as the server's separator.

   4.  The DER-encoded X.509 end-entity certificate used to
      verify sign the
       DelegatedCredential.

   5.  DelegatedCredential.algorithm.

   6.  DelegatedCredential.scheme.

   The signature on effectively binds the credential.

   If one or more credential to the parameters of these checks fail, then
   the delegated credential handshake in which it is
   deemed invalid.  Clients used.  In particular, it ensures that receive invalid delegated
   credentials
   MUST terminate the connection are only used with an "illegal_parameter" alert.  If
   successful, the client uses certificate, protocol, and
   signature algorithm chosen by the public key delegator.  Minimizing their
   semantics in this way is intended to mitigate the credential risk of cross
   protocol attacks involving delegated credentials.

   The code changes to create and verify a signature provided in delegated credentials would be
   localized to the handshake: in particular, TLS stack, which has the advantage of avoiding
   changes to security-critical and often delicate PKI code (though of
   course moves that complexity to the
   CertificateVerify message in TLS 1.3 stack).

3.1.  Client and Server behavior

   This document defines the ServerKeyExchange in
   1.2.

4.  Delegated Credentials

   While X.509 forbids end-entity certificates from being used as
   issuers for other certificates, it is perfectly fine to use them to
   issue other signed objects as long as the certificate contains the
   digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a
   new signed object format that would encode only the semantics that
   are needed for this application.

   struct {
     uint32 valid_time;
     opaque public_key<0..2^16-1>;
   } Credential;

   struct following extension code point.

      enum {
     Credential cred;
     SignatureScheme scheme;
     opaque signature<0..2^16-1>;
        ...
        delegated_credential(TBD),
        (65535)
      } DelegatedCredential;

   valid_time:  Relative time in seconds from the beginning of the
      certificate's notBefore value after ExtensionType;

   A client which supports this specification SHALL send an empty
   "delegated_credential" extension in its ClientHello.  If the client
   receives a delegated credential without indicating support, then the
   client MUST abort with an "unexpected_message" alert.

   If the extension is no longer valid.

   public_key:  The present, the server MAY send a delegated credential's public key, which
   credential; if the extension is an
      encoded SubjectPublicKeyInfo [RFC5280].

   scheme:  The signature algorithm used to sign not present, the server MUST NOT send
   a delegated credential.

   signature:  A delegated credential MUST NOT be provided
   unless a Certificate message is also sent.  The signature over server MUST ignore
   the extension unless TLS 1.3 or a later version is negotiated.

   The server MUST send the delegated credential with as an extension in the
   CertificateEntry of its end-entity
      certificate's public key, using certificate; the scheme.

   The DelegatedCredential structure is similar client SHOULD
   ignore delegated credentials sent as extensions to any other
   certificate.

   The algorithm and expected_cert_verify_algorithm fields MUST be of a
   type advertised by the CertificateVerify
   structure client in TLS 1.3.  Since the SignatureScheme is defined in TLS
   1.3, TLS 1.2 clients should translate "signature_algorithms"
   extension.  A delegated credential MUST NOT be negotiated otherwise,
   even if the scheme into an appropriate
   group client advertises support for delegated credentials.

   On receiving a delegated credential and signature algorithm a certificate chain, the
   client validates the certificate chain and matches the end-entity
   certificate to perform validation.

   The signature of the DelegatedCredential is computed over server's expected identity following its normal
   procedures.  It also takes the
   concatenation of: following steps:

   1.  A string  Verify that consists the current time is within the validity interval of octet 32 (0x20) repeated 64 times.
       the credential and that the credential's time to live is no more
       than 7 days.

   2.  The context string "TLS, server delegated credentials".  Verify that expected_cert_verify_algorithm matches the scheme
       indicated in the server's CertificateVerify message.

   3.  A single 0 byte which serves as  Verify that expected_version matches the separator. protocol version
       indicated in the server's "supported_versions" extension.

   4.  Big endian serialized 2 bytes ProtocolVersion of  Verify that the negotiated
       TLS version, defined by TLS.

   5.  DER encoded X.509 end-entity certificate used to sign satisfies the
       DelegatedCredential.

   6.  Big endian serialized 2 byte SignatureScheme scheme.

   7.  The Credential structure.

   This signature has a few desirable properties:

   o  It is bound to conditions
       specified in Section 3.2.

   5.  Use the public key in the server's end-entity certificate that signed it.

   o  It is bound to
       verify the protocol version that is negotiated.  This signature of the credential using the algorithm
       indicated by DelegatedCredential.algorithm.

   If one or more of these checks fail, then the delegated credential is
      intended to avoid cross-protocol attacks with signing oracles.

   The code changes to create and verify
   deemed invalid.  Clients that receive invalid delegated credentials would be
   localized to
   MUST terminate the TLS stack, which has connection with an "illegal_parameter" alert.  If
   successful, the advantage of avoiding
   changes to security-critical and often delicate PKI code (though of
   course moves that complexity client uses the public key in the credential to
   verify the TLS stack).

4.1. signature in the server's CertificateVerify message.

3.2.  Certificate Requirements

   We define a new X.509 extension, DelegationUsage DelegationUsage, to be used in the
   certificate when the certificate permits the usage of delegated
   credentials.  When this extension is not present the client MUST not
   accept a delegated credential even if it is negotiated by the server.
   When it is present, the client MUST follow the validation procedure.

   id-ce-delegationUsage OBJECT IDENTIFIER ::=  { TBD 1.3.6.1.4.1.44363.44 }
   DelegationUsage ::= BIT STRING { allowed (0) }
   Conforming CAs MUST mark this NULL

   The extension as MUST be marked non-critical.  This allows  (See Section 4.2 of
   [RFC5280].)  The client MUST NOT accept a delegated credential unless
   the server's end-entity certificate to be used by service owners for clients that do not
   support certificate delegation as well and not need to obtain two
   certificates.

5. satisfies the following criteria:

   o  It has the DelegationUsage extension.

   o  It has the digitalSignature KeyUsage (see the KeyUsage extension
      defined in [RFC5280]).

4.  IANA Considerations

   TBD

6.

5.  Security Considerations

6.1.

5.1.  Security of delegated private key

   Delegated credentials limit the exposure of the TLS private key by
   limiting its validity.  An attacker who compromises the private key
   of a delegated credential can act as a man in the middle until the
   delegate credential expires, however they cannot create new delegated
   credentials.  Thus delegated credentials should not be used to send a
   delegation to an untrusted party, but is meant to be used between
   parties that have some trust relationship with each other.  The
   secrecy of the delegated private key is thus important and several
   access control mechanisms SHOULD be used to protect it such as file
   system controls, physical security or hardware security modules.

6.2.

5.2.  Revocation of delegated credentials

   Delegated credentials do not provide any additional form of early
   revocation.  Since it is short lived, the expiry of the delegated
   credential would revoke the credential.  Revocation of the long term
   private key that signs the delegated credential also implictly implicitly
   revokes the delegated credential.

6.3.

5.3.  Privacy considerations

   Delegated credentials can be valid for 7 days and it is much easier
   for a service to create delegated credential than a certificate
   signed by a CA.  A service could determine the client time and clock
   skew by creating several delegated credentials with different expiry
   timestamps and observing whether the client would accept it.  Client
   time could be unique and thus privacy sensitive clients, such as
   browsers in incognito mode, who do not trust the service might not
   want to advertise support for delegated credentials or limit the
   number of probes that a server can perform.

7.

6.  Acknowledgements

   Thanks to Christopher Patton, Kyle Nekritz, Anirudh Ramachandran,
   Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor for their
   discussions, ideas, and bugs
   they've they have found.

8.

7.  References

8.1.

7.1.  Normative References

   [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>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

8.2.

   [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>.

   [X690]     ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

7.2.  Informative References

   [I-D.ietf-acme-acme]
              Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", draft-ietf-acme-acme-12 draft-ietf-acme-acme-14 (work in progress), April
              August 2018.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
              March 2018.

   [I-D.mglt-lurk-tls-requirements]
              Migault, D. and K. Ma, "Authentication Model and Security
              Requirements for the TLS/DTLS Content Provider Edge Server
              Split Use Case", draft-mglt-lurk-tls-requirements-00 (work
              in progress), January 2016.

   [RFC3820]  Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M.
              Thompson, "Internet X.509 Public Key Infrastructure (PKI)
              Proxy Certificate Profile", RFC 3820,
              DOI 10.17487/RFC3820, June 2004, <https://www.rfc-
              editor.org/info/rfc3820>.
              <https://www.rfc-editor.org/info/rfc3820>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <https://www.rfc-editor.org/info/rfc6066>.

   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
              Multiple Certificate Status Request Extension", RFC 6961,
              DOI 10.17487/RFC6961, June 2013,
              <https://www.rfc-editor.org/info/rfc6961>.

   [XPROT]    Jager, T., Schwenk, J., and J. Somorovsky, "On the
              Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
              v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC
              Conference on Computer and Communications Security , 2015.

Authors' Addresses

   Richard Barnes
   Mozilla

   Email: rlb@ipv.sx

   Subodh Iyengar
   Facebook

   Email: subodh@fb.com

   Nick Sullivan
   Cloudflare

   Email: nick@cloudflare.com

   Eric Rescorla
   RTFM, Inc.

   Email: ekr@rtfm.com