draft-ietf-tls-subcerts-02.txt   draft-ietf-tls-subcerts-03.txt 
Network Working Group R. Barnes Network Working Group R. Barnes
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Iyengar Intended status: Standards Track S. Iyengar
Expires: February 18, 2019 Facebook Expires: August 23, 2019 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
August 17, 2018 February 19, 2019
Delegated Credentials for TLS Delegated Credentials for TLS
draft-ietf-tls-subcerts-02 draft-ietf-tls-subcerts-03
Abstract Abstract
The organizational separation between the operator of a TLS server The organizational separation between the operator of a TLS server
and the certification authority can create limitations. For example, and the certification authority can create limitations. For example,
the lifetime of certificates, how they may be used, and the the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the algorithms they support are ultimately determined by the
certification authority. This document describes a mechanism by certification authority. This document describes a mechanism by
which operators may delegate their own credentials for use in TLS, which operators may delegate their own credentials for use in TLS,
without breaking compatibility with clients that do not support this without breaking compatibility with clients that do not support this
specification. specification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2019. This Internet-Draft will expire on August 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5
3. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 6 3. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 6
3.1. Client and Server behavior . . . . . . . . . . . . . . . 8 3.1. Client and Server behavior . . . . . . . . . . . . . . . 8
3.2. Certificate Requirements . . . . . . . . . . . . . . . . 9 3.2. Certificate Requirements . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Security of delegated private key . . . . . . . . . . . . 10 5.1. Security of delegated private key . . . . . . . . . . . . 10
5.2. Revocation of delegated credentials . . . . . . . . . . . 10 5.2. Revocation of delegated credentials . . . . . . . . . . . 10
5.3. Privacy considerations . . . . . . . . . . . . . . . . . 10 5.3. Privacy considerations . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Typically, a TLS server uses a certificate provided by some entity Typically, a TLS server uses a certificate provided by some entity
other than the operator of the server (a "Certification Authority" or other than the operator of the server (a "Certification Authority" or
CA) [RFC8446] [RFC5280]. This organizational separation makes the CA) [RFC8446] [RFC5280]. This organizational separation makes the
TLS server operator dependent on the CA for some aspects of its TLS server operator dependent on the CA for some aspects of its
skipping to change at page 3, line 25 skipping to change at page 3, line 25
To remove these dependencies, this document proposes a limited To remove these dependencies, this document proposes a limited
delegation mechanism that allows a TLS server operator to issue its delegation mechanism that allows a TLS server operator to issue its
own credentials within the scope of a certificate issued by an own credentials within the scope of a certificate issued by an
external CA. Because the above problems do not relate to the CA's external CA. Because the above problems do not relate to the CA's
inherent function of validating possession of names, it is safe to inherent function of validating possession of names, it is safe to
make such delegations as long as they only enable the recipient of make such delegations as long as they only enable the recipient of
the delegation to speak for names that the CA has authorized. For 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 clarity, we will refer to the certificate issued by the CA as a
"certificate", or "delegation certificate", and the one issued by the "certificate", or "delegation certificate", and the one issued by the
operator as a "delegated credential". operator as a "delegated credential" or "DC".
1.1. Change Log 1.1. Change Log
(*) indicates changes to the wire protocol. (*) indicates changes to the wire protocol.
draft-03
o Remove protocol version from the Credential structure. (*)
draft-02 draft-02
o Change public key type. (*) o Change public key type. (*)
o Change DelegationUsage extension to be NULL and define its object o Change DelegationUsage extension to be NULL and define its object
identifier. identifier.
o Drop support for TLS 1.2. o Drop support for TLS 1.2.
o Add the protocol version and credential signature algorithm to the o Add the protocol version and credential signature algorithm to the
skipping to change at page 4, line 32 skipping to change at page 4, line 32
certificate as well as the delegated credential. certificate as well as the delegated credential.
o The client uses information in the server's certificate to verify o The client uses information in the server's certificate to verify
the delegated credential and that the server is asserting an the delegated credential and that the server is asserting an
expected identity. expected identity.
o The client uses the public key in the credential as the server's o The client uses the public key in the credential as the server's
working key for the TLS handshake. working key for the TLS handshake.
As detailed in Section 3, the delegated credential is As detailed in Section 3, the delegated credential is
cryptographically bound to the end-entity certificate and the cryptographically bound to the end-entity certificate with which the
protocol in which the credential may be used. This document credential may be used. This document specifies the use of delegated
specifies the use of delegated credentials in TLS 1.3 or later; their credentials in TLS 1.3 or later; their use in prior versions of the
use in prior versions of the protocol is explicitly disallowed. protocol is not allowed.
Delegated credentials allow the server to terminate TLS connections Delegated credentials allow the server to terminate TLS connections
on behalf of the certificate owner. If a credential is stolen, there on behalf of the certificate owner. If a credential is stolen, there
is no mechanism for revoking it without revoking the certificate is no mechanism for revoking it without revoking the certificate
itself. To limit exposure in case a delegated credential is itself. To limit exposure in case a delegated credential is
compromised, servers may not issue credentials with a validity period compromised, servers may not issue credentials with a validity period
longer than 7 days. This mechanism is described in detail in longer than 7 days. This mechanism is described in detail in
Section 3.1. Section 3.1.
It was noted in [XPROT] that certificates in use by servers that It was noted in [XPROT] that certificates in use by servers that
skipping to change at page 5, line 17 skipping to change at page 5, line 17
Delegated credentials present a better alternative than other Delegated credentials present a better alternative than other
delegation mechanisms like proxy certificates [RFC3820] for several delegation mechanisms like proxy certificates [RFC3820] for several
reasons: reasons:
o There is no change needed to certificate validation at the PKI o There is no change needed to certificate validation at the PKI
layer. layer.
o X.509 semantics are very rich. This can cause unintended o X.509 semantics are very rich. This can cause unintended
consequences if a service owner creates a proxy certificate where consequences if a service owner creates a proxy certificate where
the properties differ from the leaf certificate. For this reason, the properties differ from the leaf certificate. For this reason,
delegated credentials have very restricted semantics which should delegated credentials have very restricted semantics that should
not conflict with X.509 semantics. not conflict with X.509 semantics.
o Proxy certificates rely on the certificate path building process o Proxy certificates rely on the certificate path building process
to establish a binding between the proxy certificate and the to establish a binding between the proxy certificate and the
server certificate. Since the certificate path building process server certificate. Since the certificate path building process
is not cryptographically protected, it is possible that a proxy is not cryptographically protected, it is possible that a proxy
certificate could be bound to another certificate with the same certificate could be bound to another certificate with the same
public key, with different X.509 parameters. Delegated public key, with different X.509 parameters. Delegated
credentials, which rely on a cryptographic binding between the credentials, which rely on a cryptographic binding between the
entire certificate and the delegated credential, cannot. entire certificate and the delegated credential, cannot.
o Each delegated credential is bound to a specific version of TLS o Each delegated credential is bound to a specific signature
and signature algorithm. This prevents them from being used for algorithm that may be used to sign the TLS handshake ([RFC8446]
other protocols or with other signature algorithms than service section 4.2.3). This prevents them from being used with other,
owner allows. perhaps unintended signature algorithms.
2.2. Related Work 2.2. Related Work
Many of the use cases for delegated credentials can also be addressed Many of the use cases for delegated credentials can also be addressed
using purely server-side mechanisms that do not require changes to using purely server-side mechanisms that do not require changes to
client behavior (e.g., LURK [I-D.mglt-lurk-tls-requirements]). These client behavior (e.g., LURK [I-D.mglt-lurk-tls-requirements]). These
mechanisms, however, incur per-transaction latency, since the front- mechanisms, however, incur per-transaction latency, since the front-
end server has to interact with a back-end server that holds a end server has to interact with a back-end server that holds a
private key. The mechanism proposed in this document allows the private key. The mechanism proposed in this document allows the
delegation to be done off-line, with no per-transaction latency. The delegation to be done off-line, with no per-transaction latency. The
figure below compares the message flows for these two mechanisms with figure below compares the message flows for these two mechanisms with
TLS 1.3 [I-D.ietf-tls-tls13], where DC is delegated credentials. TLS 1.3 [I-D.ietf-tls-tls13].
LURK: LURK:
Client Front-End Back-End Client Front-End Back-End
|----ClientHello--->| | |----ClientHello--->| |
|<---ServerHello----| | |<---ServerHello----| |
|<---Certificate----| | |<---Certificate----| |
| |<-------LURK------->| | |<-------LURK------->|
|<---CertVerify-----| | |<---CertVerify-----| |
| ... | | | ... | |
skipping to change at page 6, line 37 skipping to change at page 6, line 37
support legacy clients. support legacy clients.
It is possible to address the short-lived certificate concerns above It is possible to address the short-lived certificate concerns above
by automating certificate issuance, e.g., with ACME by automating certificate issuance, e.g., with ACME
[I-D.ietf-acme-acme]. In addition to requiring frequent [I-D.ietf-acme-acme]. In addition to requiring frequent
operationally-critical interactions with an external party, this operationally-critical interactions with an external party, this
makes the server operator dependent on the CA's willingness to issue makes the server operator dependent on the CA's willingness to issue
certificates with sufficiently short lifetimes. It also fails to certificates with sufficiently short lifetimes. It also fails to
address the issues with algorithm support. Nonetheless, existing address the issues with algorithm support. Nonetheless, existing
automated issuance APIs like ACME may be useful for provisioning automated issuance APIs like ACME may be useful for provisioning
credentials, within an operator network. credentials within an operator network.
3. Delegated Credentials 3. Delegated Credentials
While X.509 forbids end-entity certificates from being used as While X.509 forbids end-entity certificates from being used as
issuers for other certificates, it is perfectly fine to use them to issuers for other certificates, it is perfectly fine to use them to
issue other signed objects as long as the certificate contains the issue other signed objects as long as the certificate contains the
digitalSignature KeyUsage (RFC5280 section 4.2.1.3). We define a new digitalSignature KeyUsage (RFC5280 section 4.2.1.3). We define a new
signed object format that would encode only the semantics that are signed object format that would encode only the semantics that are
needed for this application. The credential has the following needed for this application. The credential has the following
structure: structure:
struct { struct {
uint32 valid_time; uint32 valid_time;
SignatureScheme expected_cert_verify_algorithm; SignatureScheme expected_cert_verify_algorithm;
ProtocolVersion expected_version;
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
} Credential; } Credential;
valid_time: Relative time in seconds from the beginning of the valid_time: Relative time in seconds from the beginning of the
delegation certificate's notBefore value after which the delegated delegation certificate's notBefore value after which the delegated
credential is no longer valid. credential is no longer valid.
expected_cert_verify_algorithm: The signature algorithm of the expected_cert_verify_algorithm: The signature algorithm of the
credential key pair, where the type SignatureScheme is as defined credential key pair, where the type SignatureScheme is as defined
in [RFC8446]. This is expected to be the same as in [RFC8446]. This is expected to be the same as
CertificateVerify.algorithm sent by the server. CertificateVerify.algorithm sent by the server.
expected_version: The version of TLS in which the credential will be
used, where the type ProtocolVersion is as defined in [RFC8446].
This is expected to match the protocol version that is negotiated
by the client and server.
ASN1_subjectPublicKeyInfo: The credential's public key, a DER- ASN1_subjectPublicKeyInfo: The credential's public key, a DER-
encoded [X690] SubjectPublicKeyInfo as defined in [RFC5280]. encoded [X690] SubjectPublicKeyInfo as defined in [RFC5280].
The delegated credential has the following structure: The delegated credential has the following structure:
struct { struct {
Credential cred; Credential cred;
SignatureScheme algorithm; SignatureScheme algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} DelegatedCredential; } DelegatedCredential;
algorithm: The signature algorithm used to verify algorithm: The signature algorithm used to verify
DelegatedCredential.signature. DelegatedCredential.signature.
signature: The signature over the credential with the end-entity signature: The delegation, a signature that binds the credential to
certificate's public key, using the scheme. the end-entity certificate's public key as specified below. The
signature scheme is specified by DelegatedCredential.algorithm.
The signature of the DelegatedCredential is computed over the The signature of the DelegatedCredential is computed over the
concatenation of: concatenation of:
1. A string that consists of octet 32 (0x20) repeated 64 times. 1. A string that consists of octet 32 (0x20) repeated 64 times.
2. The context string "TLS, server delegated credentials". 2. The context string "TLS, server delegated credentials".
3. A single 0 byte, which serves as the separator. 3. A single 0 byte, which serves as the separator.
4. The DER-encoded X.509 end-entity certificate used to sign the 4. The DER-encoded X.509 end-entity certificate used to sign the
DelegatedCredential. DelegatedCredential.
5. DelegatedCredential.algorithm. 5. DelegatedCredential.cred.
6. DelegatedCredential.scheme. 6. DelegatedCredential.algorithm.
The signature effectively binds the credential to the parameters of The signature effectively binds the credential to the parameters of
the handshake in which it is used. In particular, it ensures that the handshake in which it is used. In particular, it ensures that
credentials are only used with the certificate, protocol, and credentials are only used with the certificate and signature
signature algorithm chosen by the delegator. Minimizing their algorithm chosen by the delegator. Minimizing their semantics in
semantics in this way is intended to mitigate the risk of cross this way is intended to mitigate the risk of cross protocol attacks
protocol attacks involving delegated credentials. involving delegated credentials.
The code changes to create and verify delegated credentials would be The code changes required in order to create and verify delegated
localized to the TLS stack, which has the advantage of avoiding credentials, and the implementation complexity this entails, are
changes to security-critical and often delicate PKI code (though of localized to the TLS stack. This has the advantage of avoiding
course moves that complexity to the TLS stack). changes to security-critical and often delicate PKI code.
3.1. Client and Server behavior 3.1. Client and Server behavior
This document defines the following extension code point. This document defines the following extension code point.
enum { enum {
... ...
delegated_credential(TBD), delegated_credential(TBD),
(65535) (65535)
} ExtensionType; } ExtensionType;
skipping to change at page 9, line 9 skipping to change at page 8, line 50
ignore delegated credentials sent as extensions to any other ignore delegated credentials sent as extensions to any other
certificate. certificate.
The algorithm and expected_cert_verify_algorithm fields MUST be of a The algorithm and expected_cert_verify_algorithm fields MUST be of a
type advertised by the client in the "signature_algorithms" type advertised by the client in the "signature_algorithms"
extension. A delegated credential MUST NOT be negotiated otherwise, extension. A delegated credential MUST NOT be negotiated otherwise,
even if the client advertises support for delegated credentials. even if the client advertises support for delegated credentials.
On receiving a delegated credential and a certificate chain, the On receiving a delegated credential and a certificate chain, the
client validates the certificate chain and matches the end-entity client validates the certificate chain and matches the end-entity
certificate to the server's expected identity following its normal certificate to the server's expected identity in the usual way. It
procedures. It also takes the following steps: also takes the following steps:
1. Verify that the current time is within the validity interval of 1. Verify that the current time is within the validity interval of
the credential and that the credential's time to live is no more the credential and that the credential's time to live is no more
than 7 days. than 7 days. This is done by asserting that the current time is
no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time.
2. Verify that expected_cert_verify_algorithm matches the scheme 2. Verify that expected_cert_verify_algorithm matches the scheme
indicated in the server's CertificateVerify message. indicated in the server's CertificateVerify message.
3. Verify that expected_version matches the protocol version 3. Verify that the end-entity certificate satisfies the conditions
indicated in the server's "supported_versions" extension. in Section 3.2.
4. Verify that the end-entity certificate satisfies the conditions
specified in Section 3.2.
5. Use the public key in the server's end-entity certificate to 4. Use the public key in the server's end-entity certificate to
verify the signature of the credential using the algorithm verify the signature of the credential using the algorithm
indicated by DelegatedCredential.algorithm. indicated by DelegatedCredential.algorithm.
If one or more of these checks fail, then the delegated credential is If one or more of these checks fail, then the delegated credential is
deemed invalid. Clients that receive invalid delegated credentials deemed invalid. Clients that receive invalid delegated credentials
MUST terminate the connection with an "illegal_parameter" alert. If MUST terminate the connection with an "illegal_parameter" alert. If
successful, the client uses the public key in the credential to successful, the client uses the public key in the credential to
verify the signature in the server's CertificateVerify message. verify the signature in the server's CertificateVerify message.
3.2. Certificate Requirements 3.2. Certificate Requirements
skipping to change at page 10, line 17 skipping to change at page 10, line 13
TBD TBD
5. Security Considerations 5. Security Considerations
5.1. Security of delegated private key 5.1. Security of delegated private key
Delegated credentials limit the exposure of the TLS private key by Delegated credentials limit the exposure of the TLS private key by
limiting its validity. An attacker who compromises the private key limiting its validity. An attacker who compromises the private key
of a delegated credential can act as a man in the middle until the of a delegated credential can act as a man in the middle until the
delegate credential expires, however they cannot create new delegated delegate credential expires, however they cannot create new delegated
credentials. Thus delegated credentials should not be used to send a credentials. Thus, delegated credentials should not be used to send
delegation to an untrusted party, but is meant to be used between a delegation to an untrusted party, but is meant to be used between
parties that have some trust relationship with each other. The parties that have some trust relationship with each other. The
secrecy of the delegated private key is thus important and several secrecy of the delegated private key is thus important and several
access control mechanisms SHOULD be used to protect it such as file access control mechanisms SHOULD be used to protect it, including
system controls, physical security or hardware security modules. file system controls, physical security, or hardware security
modules.
5.2. Revocation of delegated credentials 5.2. Revocation of delegated credentials
Delegated credentials do not provide any additional form of early Delegated credentials do not provide any additional form of early
revocation. Since it is short lived, the expiry of the delegated revocation. Since it is short lived, the expiry of the delegated
credential would revoke the credential. Revocation of the long term credential would revoke the credential. Revocation of the long term
private key that signs the delegated credential also implicitly private key that signs the delegated credential also implicitly
revokes the delegated credential. revokes the delegated credential.
5.3. Privacy considerations 5.3. Privacy considerations
skipping to change at page 10, line 46 skipping to change at page 10, line 43
signed by a CA. A service could determine the client time and clock signed by a CA. A service could determine the client time and clock
skew by creating several delegated credentials with different expiry skew by creating several delegated credentials with different expiry
timestamps and observing whether the client would accept it. Client timestamps and observing whether the client would accept it. Client
time could be unique and thus privacy sensitive clients, such as time could be unique and thus privacy sensitive clients, such as
browsers in incognito mode, who do not trust the service might not browsers in incognito mode, who do not trust the service might not
want to advertise support for delegated credentials or limit the want to advertise support for delegated credentials or limit the
number of probes that a server can perform. number of probes that a server can perform.
6. Acknowledgements 6. Acknowledgements
Thanks to Christopher Patton, Kyle Nekritz, Anirudh Ramachandran, Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh
Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor for their Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson
discussions, ideas, and bugs they have found. Ladd for their discussions, ideas, and bugs they have found.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
skipping to change at page 11, line 29 skipping to change at page 11, line 26
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
7.2. Informative References 7.2. Informative References
[I-D.ietf-acme-acme] [I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", draft-ietf-acme-acme-14 (work in progress), (ACME)", draft-ietf-acme-acme-18 (work in progress),
August 2018. December 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[I-D.mglt-lurk-tls-requirements] [I-D.mglt-lurk-tls-requirements]
Migault, D. and K. Ma, "Authentication Model and Security Migault, D. and K. Ma, "Authentication Model and Security
Requirements for the TLS/DTLS Content Provider Edge Server Requirements for the TLS/DTLS Content Provider Edge Server
Split Use Case", draft-mglt-lurk-tls-requirements-00 (work Split Use Case", draft-mglt-lurk-tls-requirements-00 (work
in progress), January 2016. in progress), January 2016.
[RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M.
Thompson, "Internet X.509 Public Key Infrastructure (PKI) Thompson, "Internet X.509 Public Key Infrastructure (PKI)
Proxy Certificate Profile", RFC 3820, Proxy Certificate Profile", RFC 3820,
DOI 10.17487/RFC3820, June 2004, DOI 10.17487/RFC3820, June 2004, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3820>. editor.org/info/rfc3820>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6066>. editor.org/info/rfc6066>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6961>. editor.org/info/rfc6961>.
[XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the
Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC
Conference on Computer and Communications Security , 2015. Conference on Computer and Communications Security , 2015.
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
Mozilla Mozilla
 End of changes. 35 change blocks. 
64 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/