draft-ietf-tls-subcerts-00.txt   draft-ietf-tls-subcerts-01.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: May 3, 2018 Facebook Expires: January 3, 2019 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
October 30, 2017 July 02, 2018
Delegated Credentials for TLS Delegated Credentials for TLS
draft-ietf-tls-subcerts-00 draft-ietf-tls-subcerts-01
Abstract Abstract
The organizational separation between the operator of a TLS server The organizational separation between the operator of a TLS server
and the certificate authority that provides it credentials can cause and the certificate authority that provides it credentials can cause
problems, for example when it comes to reducing the lifetime of problems, for example when it comes to reducing the lifetime of
certificates or supporting new cryptographic algorithms. This certificates or supporting new cryptographic algorithms. This
document describes a mechanism to allow TLS server operators to document describes a mechanism to allow TLS server operators to
create their own credential delegations without breaking create their own credential delegations without breaking
compatibility with clients that do not support this specification. compatibility with clients that do not support this 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 May 3, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5
3. Client and Server behavior . . . . . . . . . . . . . . . . . 6 3. Client and Server behavior . . . . . . . . . . . . . . . . . 6
4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 7 4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 7
4.1. Certificate Requirements . . . . . . . . . . . . . . . . 8 4.1. Certificate Requirements . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Security of delegated private key . . . . . . . . . . . . 9 6.1. Security of delegated private key . . . . . . . . . . . . 9
6.2. Revocation of delegated credentials . . . . . . . . . . . 9 6.2. Revocation of delegated credentials . . . . . . . . . . . 9
6.3. Privacy considerations . . . . . . . . . . . . . . . . . 9 6.3. Privacy considerations . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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) [RFC5246] [RFC5280]. This organizational separation makes the CA) [RFC5246] [RFC5280]. This organizational separation makes the
skipping to change at page 3, line 4 skipping to change at page 3, line 4
o The server operator can only use TLS authentication schemes for o The server operator can only use TLS authentication schemes for
which the CA will issue credentials. which the CA will issue credentials.
These dependencies cause problems in practice. Server operators These dependencies cause problems in practice. Server operators
often want to create short-lived certificates for servers in low- often want to create short-lived certificates for servers in low-
trust zones such as CDNs or remote data centers. This allows server 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 operators to limit the exposure of keys in cases that they do not
realize a compromise has occurred. The risk inherent in cross- realize a compromise has occurred. The risk inherent in cross-
organizational transactions makes it operationally infeasible to rely organizational transactions makes it operationally infeasible to rely
on an external CA for such short-lived credentials. In contrast to on an external CA for such short-lived credentials. In OCSP
OCSP stapling, in which an operator could choose to talk to the CA stapling, if an operator chooses to talk frequently to the CA to
frequently to obtain stapled responses, failure to fetch an OCSP obtain stapled responses, then failure to fetch an OCSP stapled
stapled response results only in degraded performance, however response results only in degraded performance. On the other hand,
failure to fetch a potentially large number of short lived failure to fetch a potentially large number of short lived
certificates would result in the service not being available which certificates would result in the service not being available which
creates greater operational risk. creates greater operational risk.
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 CAs external CA. Because the above problems do not relate to the CAs
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" and the one issued by the operator as a "Delegated "certificate" and the one issued by the operator as a "delegated
credential". credential".
2. Solution Overview 2. Solution Overview
A Delegated credential is a digitally signed data structure with the A delegated credential is a digitally signed data structure with the
following semantic fields: following semantic fields:
o A validity interval o A validity interval
o A public key (with its associated algorithm) o A public key (with its associated algorithm)
The signature on the credential indicates a delegation from the The signature on the credential indicates a delegation from the
certificate which is issued to the TLS server operator. The key pair certificate that is issued to the TLS server operator. The secret
used to sign a credential is presumed to be one whose public key is key used to sign a credential is presumed to be one whose
contained in an X.509 certificate that associates one or more names corresponding public key is contained in an X.509 certificate that
to the credential. associates one or more names to the credential.
A TLS handshake that uses credentials differs from a normal handshake A TLS handshake that uses credentials differs from a normal handshake
in a few important ways: in a few important ways:
o The client provides an extension in its ClientHello that indicates o The client provides an extension in its ClientHello that indicates
support for this mechanism. support for this mechanism.
o The server provides both the certificate chain terminating in its o The server provides both the certificate chain terminating in its
certificate as well as the credential. certificate as well as the 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 signature on the credential and verify that the server is the signature on the credential and verify that the server is
asserting an expected identity. asserting an 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.
Delegated credentials can be used either in TLS 1.3 or TLS 1.2. Delegated credentials can be used either in TLS 1.3 or TLS 1.2.
Differences between the use of Delegated credentials in the protocols Differences between the use of delegated credentials in the protocols
are explicitly stated. are explicitly stated.
It was noted in [XPROT] that certificates in use by servers that It was noted in [XPROT] that certificates in use by servers that
support outdated protocols such as SSLv2 can be used to forge support outdated protocols such as SSLv2 can be used to forge
signatures for certificates that contain the keyEncipherment KeyUsage signatures for certificates that contain the keyEncipherment KeyUsage
([RFC5280] section 4.2.1.3) In order to prevent this type of cross- ([RFC5280] section 4.2.1.3) In order to prevent this type of cross-
protocol attack, we define a new DelegationUsage extension to X.509 protocol attack, we define a new DelegationUsage extension to X.509
which permits use of delegated credentials. Clients MUST NOT accept that permits use of delegated credentials. Clients MUST NOT accept
delegated credentials associated with certificates without this delegated credentials associated with certificates without this
extension. extension.
Credentials allow the server to terminate TLS connections on behalf Credentials allow the server to terminate TLS connections on behalf
of the certificate owner. If a credential is stolen, there is no of the certificate owner. If a credential is stolen, there is no
mechanism for revoking it without revoking the certificate itself. mechanism for revoking it without revoking the certificate itself.
To limit the exposure of a delegation credential compromise, servers To limit the exposure of a delegation credential compromise, servers
MUST NOT issue credentials with a validity period longer than 7 days. MUST NOT issue credentials with a validity period longer than 7 days.
Clients MUST NOT accept credentials with longer validity periods. Clients MUST NOT accept credentials with longer validity periods.
2.1. Rationale 2.1. Rationale
Delegated credentials present a better alternative from 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 cert where the consequences if a service owner creates a proxy cert where the
properties differ from the leaf certificate. properties differ from the leaf certificate.
o Delegated credentials have very restricted semantics which should o Delegated credentials have very restricted semantics which 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 cert path building process is not server certificate. Since the cert path building process is not
cryptographically protected, it is possible that a proxy 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 Delegated credentials allow signed messages to be bound to o Delegated credentials are bound to specific versions of TLS. This
specific versions of TLS. This prevents them from being used for prevents them from being used for other protocols if a service
other protocols if a service owner allows multiple versions of owner allows multiple versions of TLS.
TLS.
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
skipping to change at page 5, line 35 skipping to change at page 5, line 34
|----ClientHello--->| | |----ClientHello--->| |
|<---ServerHello----| | |<---ServerHello----| |
|<---Certificate----| | |<---Certificate----| |
| |<-------LURK------->| | |<-------LURK------->|
|<---CertVerify-----| | |<---CertVerify-----| |
| ... | | | ... | |
Delegated credentials: Delegated credentials:
Client Front-End Back-End Client Front-End Back-End
| |<---Cred Provision--| | |<--Cred Provision-->|
|----ClientHello--->| | |----ClientHello--->| |
|<---ServerHello----| | |<---ServerHello----| |
|<---Certificate----| | |<---Certificate----| |
|<---CertVerify-----| | |<---CertVerify-----| |
These two classes of mechanism can be complementary. A server could These two mechanisms can be complementary. A server could use
use credentials for clients that support them, while using LURK to credentials for clients that support them, while using LURK to
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
skipping to change at page 6, line 27 skipping to change at page 6, line 27
A client which supports this document SHALL send an empty A client which supports this document SHALL send an empty
"delegated_credential" extension in its ClientHello. "delegated_credential" extension in its ClientHello.
If the extension is present, the server MAY send a If the extension is present, the server MAY send a
DelegatedCredential extension. If the extension is not present, the DelegatedCredential extension. If the extension is not present, the
server MUST NOT send a credential. A credential MUST NOT be provided server MUST NOT send a credential. A credential MUST NOT be provided
unless a Certificate message is also sent. unless a Certificate message is also sent.
When negotiating TLS 1.3, and using Delegated credentials, the server When negotiating TLS 1.3, and using Delegated credentials, the server
MUST send the DelegatedCredential as an extension in the MUST send the DelegatedCredential as an extension in the
CertificateEntry of its end entity certificate. When negotiating TLS CertificateEntry of its end-entity certificate. When negotiating TLS
1.2, the DelegatedCredential MUST be sent as an extension in the 1.2, the DelegatedCredential MUST be sent as an extension in the
ServerHello. ServerHello.
The DelegatedCredential contains a signature from the public key in The DelegatedCredential contains a signature from the public key in
the end-entity certificate using a signature algorithm advertised by the end-entity certificate using a signature algorithm advertised by
the client in the "signature_algorithms" extension. Additionally, the client in the "signature_algorithms" extension. Additionally,
the credential's public key MUST be of a type that enables at least the credential's public key MUST be of a type that enables at least
one of the supported signature algorithms. A Delegated credential one of the supported signature algorithms. A delegated credential
MUST NOT be negotiated by the server if its signature is not MUST NOT be negotiated by the server if its signature is not
compatible with any of the supported signature algorithms or the compatible with any of the supported signature algorithms or the
credential's public key is not usable with the supported signature credential's public key is not usable with the supported signature
algorithms of the client, even if the client advertises support for algorithms of the client, even if the client advertises support for
delegated credentials. delegated credentials.
On receiving a credential and a certificate chain, the client On receiving a credential and a certificate chain, the client
validates the certificate chain and matches the end-entity 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 following its normal
procedures. It then takes the following additional steps: procedures. It then takes the following steps:
o Verify that the current time is within the validity interval of o Verify that the current time is within the validity interval of
the credential. the credential and that the credential's time to live is no more
than 7 days.
o Verify that the certificate has the DelegationUsage extension,
which permits the use of Delegated credentials.
o Use the public key in the server's end-entity certificate to o Use the public key in the server's end-entity certificate to
verify the signature on the credential. verify the signature on the credential.
o Use the public key in the credential to verify a signature If one or more of these checks fail, then the delegated credential is
provided in the handshake. That is the CertificateVerify message deemed invalid. Clients that receive invalid delegated credentials
in TLS 1.3 or ServerKeyExchange in 1.2. MUST terminate the connection with an "illegal_parameter" alert. If
successful, the client uses the public key in the credential to
o Verify that the certificate has the correct extensions that allow verify a signature provided in the handshake: in particular, the
the use of Delegated credentials. CertificateVerify message in TLS 1.3 and the ServerKeyExchange in
1.2.
Clients that receive Delegated credentials that are valid for more
than 7 days MUST terminate the connection with an "illegal_parameter"
alert.
4. Delegated Credentials 4. 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 key usage (RFC5280 section 4.2.1.3). We define a digitalSignature key usage (RFC5280 section 4.2.1.3). We define a
new signed object format that would encode only the semantics that new signed object format that would encode only the semantics that
are needed for this application. are needed for this application.
struct { struct {
uint32 validTime; uint32 valid_time;
opaque publicKey<0..2^16-1>; opaque public_key<0..2^16-1>;
} DelegatedCredentialParams; } Credential;
struct { struct {
DelegatedCredentialParams cred; Credential cred;
SignatureScheme scheme; SignatureScheme scheme;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} DelegatedCredential; } DelegatedCredential;
validTime: Relative time in seconds from the beginning of the valid_time: Relative time in seconds from the beginning of the
certificate's notBefore value after which the Delegated Credential certificate's notBefore value after which the delegated credential
is no longer valid. is no longer valid.
publicKey: The Delegated Credential's public key which is an encoded public_key: The delegated credential's public key, which is an
SubjectPublicKeyInfo [RFC5280]. encoded SubjectPublicKeyInfo [RFC5280].
scheme: The Signature algorithm and scheme used to sign the scheme: The signature algorithm used to sign the delegated
Delegated credential. credential.
signature: The signature over the credential with the end-entity signature: The signature over the credential with the end-entity
certificate's public key, using the scheme. certificate's public key, using the scheme.
The DelegatedCredential structure is similar to the CertificateVerify The DelegatedCredential structure is similar to the CertificateVerify
structure in TLS 1.3. Since the SignatureScheme defined in TLS 1.3, structure in TLS 1.3. Since the SignatureScheme is defined in TLS
TLS 1.2 clients should translate the scheme into an appropriate group 1.3, TLS 1.2 clients should translate the scheme into an appropriate
and signature algorithm to perform validation. group and signature algorithm to perform validation.
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. Big endian serialized 2 bytes ProtocolVersion of the negotiated 4. Big endian serialized 2 bytes ProtocolVersion of the negotiated
TLS version, defined by TLS. TLS version, defined by TLS.
5. DER encoded X.509 certificate used to sign the 5. DER encoded X.509 certificate used to sign the
DelegatedCredential. DelegatedCredential.
6. Big endian serialized 2 byte SignatureScheme scheme. 6. Big endian serialized 2 byte SignatureScheme scheme.
7. The DelegatedCredentialParams structure. 7. The Credential structure.
This signature has a few desirable properties: This signature has a few desirable properties:
o It is bound to the certificate that signed it. o It is bound to the certificate that signed it.
o It is bound to the protocol version that is negotiated. This is o It is bound to the protocol version that is negotiated. This is
intended to avoid cross-protocol attacks with signing oracles. intended to avoid cross-protocol attacks with signing oracles.
The code changes to create and verify Delegated credentials would be The code changes to create and verify delegated credentials would be
localized to the TLS stack, which has the advantage of avoiding localized to the TLS stack, which has the advantage of avoiding
changes to security-critical and often delicate PKI code (though of changes to security-critical and often delicate PKI code (though of
course moves that complexity to the TLS stack). course moves that complexity to the TLS stack).
4.1. Certificate Requirements 4.1. Certificate Requirements
We define a new X.509 extension, DelegationUsage to be used in the We define a new X.509 extension, DelegationUsage to be used in the
certificate when the certificate permits the usage of Delegated certificate when the certificate permits the usage of delegated
Credentials. When this extension is not present the client MUST not credentials. When this extension is not present the client MUST not
accept a Delegated Credential even if it is negotiated by the server. accept a delegated credential even if it is negotiated by the server.
When it is present, the client MUST follow the validation procedure. When it is present, the client MUST follow the validation procedure.
id-ce-delegationUsage OBJECT IDENTIFIER ::= { TBD } id-ce-delegationUsage OBJECT IDENTIFIER ::= { TBD }
DelegationUsage ::= BIT STRING { allowed (0) } DelegationUsage ::= BIT STRING { allowed (0) }
Conforming CAs MUST mark this extension as non-critical. This allows
Conforming CAs MUST mark this extension as non-critical. This would the certificate to be used by service owners for clients that do not
allow the certificate to be used by service owners for clients that support certificate delegation as well and not need to obtain two
do not support certificate delegation as well and not need to obtain certificates.
two certificates.
5. IANA Considerations 5. IANA Considerations
TBD TBD
6. Security Considerations 6. Security Considerations
6.1. Security of delegated private key 6.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
skipping to change at page 10, line 11 skipping to change at page 10, line 17
Thanks to Kyle Nekritz, Anirudh Ramachandran, Benjamin Kaduk, Kazuho Thanks to Kyle Nekritz, Anirudh Ramachandran, Benjamin Kaduk, Kazuho
Oku, Daniel Kahn Gillmor for their discussions, ideas, and bugs Oku, Daniel Kahn Gillmor for their discussions, ideas, and bugs
they've found. they've found.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[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>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-acme-acme] [I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Certificate Management Environment (ACME)", draft-ietf- Kasten, "Automatic Certificate Management Environment
acme-acme-08 (work in progress), October 2017. (ACME)", draft-ietf-acme-acme-12 (work in progress), April
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-21 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
July 2017. 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>.
[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. 39 change blocks. 
76 lines changed or deleted 76 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/