draft-ietf-tls-subcerts-09.txt   draft-ietf-tls-subcerts-10.txt 
Network Working Group R. Barnes Network Working Group R. Barnes
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track S. Iyengar Intended status: Standards Track S. Iyengar
Expires: 28 December 2020 Facebook Expires: 28 July 2021 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
Mozilla Mozilla
26 June 2020 24 January 2021
Delegated Credentials for TLS Delegated Credentials for TLS
draft-ietf-tls-subcerts-09 draft-ietf-tls-subcerts-10
Abstract Abstract
The organizational separation between the operator of a TLS endpoint The organizational separation between the operator of a TLS endpoint
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 peers that do not support this without breaking compatibility with peers that do not support this
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://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 28 December 2020. This Internet-Draft will expire on 28 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 7
4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 8 4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 8
4.1. Client and Server Behavior . . . . . . . . . . . . . . . 9 4.1. Client and Server Behavior . . . . . . . . . . . . . . . 10
4.1.1. Server Authentication . . . . . . . . . . . . . . . . 9 4.1.1. Server Authentication . . . . . . . . . . . . . . . . 10
4.1.2. Client Authentication . . . . . . . . . . . . . . . . 10 4.1.2. Client Authentication . . . . . . . . . . . . . . . . 10
4.1.3. Validating a Delegated Credential . . . . . . . . . . 11 4.1.3. Validating a Delegated Credential . . . . . . . . . . 11
4.2. Certificate Requirements . . . . . . . . . . . . . . . . 11 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . 12 5. Operational Considerations . . . . . . . . . . . . . . . . . 12
5.1. Client Clock Skew . . . . . . . . . . . . . . . . . . . . 12 5.1. Client Clock Skew . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Security of Delegated Credential's Private Key . . . . . 13 7.1. Security of Delegated Credential's Private Key . . . . . 13
7.2. Re-use of Delegated Credentials in Multiple 7.2. Re-use of Delegated Credentials in Multiple
Contexts . . . . . . . . . . . . . . . . . . . . . . . . 13 Contexts . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Revocation of Delegated Credentials . . . . . . . . . . . 13 7.3. Revocation of Delegated Credentials . . . . . . . . . . . 14
7.4. Interactions with Session Resumption . . . . . . . . . . 13 7.4. Interactions with Session Resumption . . . . . . . . . . 14
7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 14 7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 14
7.6. The Impact of Signature Forgery Attacks . . . . . . . . . 14 7.6. The Impact of Signature Forgery Attacks . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Example Certificate . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
operations, for example: operations, for example:
* Whenever the server operator wants to deploy a new certificate, it * Whenever the server operator wants to deploy a new certificate, it
skipping to change at page 3, line 37 skipping to change at page 3, line 37
certificate in time to replace a deployed certificate, the server certificate in time to replace a deployed certificate, the server
would no longer be able to present a valid certificate to clients. would no longer be able to present a valid certificate to clients.
With short-lived certificates, there is a smaller window of time to With short-lived certificates, there is a smaller window of time to
renew a certificates and therefore a higher risk that an outage at a renew a certificates and therefore a higher risk that an outage at a
CA will negatively affect the uptime of the service. CA will negatively affect the uptime of the service.
To reduce the dependency on external CAs, this document proposes a To reduce the dependency on external CAs, this document proposes a
limited delegation mechanism that allows a TLS peer to issue its own limited delegation mechanism that allows a TLS peer to issue its own
credentials within the scope of a certificate issued by an external credentials within the scope of a certificate issued by an external
CA. These credentials only enable the recipient of the delegation to CA. These credentials only enable the recipient of the delegation to
speak for names that the CA has authorized. For clarity, we will speak for names that the CA has authorized. Furthermore, this
refer to the certificate issued by the CA as a "certificate", or mechanism allows the server to use modern signature algorithms such
"delegation certificate", and the one issued by the operator as a as Ed25519 [RFC8032] even if their CA does not support them.
We will refer to the certificate issued by the CA as a "certificate",
or "delegation certificate", and the one issued by the operator as a
"delegated credential" or "DC". "delegated credential" or "DC".
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1. Change Log 2.1. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION.
(*) indicates changes to the wire protocol. (*) indicates changes to the wire protocol.
draft-10 * Address superficial comments * Add example certificate
draft-09 draft-09
* Address case nits * Address case nits
* Fix section bullets in 4.1.3. * Fix section bullets in 4.1.3.
* Add operational considerations section for clock skew * Add operational considerations section for clock skew
* Add text around using an oracle to forge DCs in the future and * Add text around using an oracle to forge DCs in the future and
past past
skipping to change at page 5, line 26 skipping to change at page 5, line 30
Credential structure. (*) Credential structure. (*)
* Specify undefined behavior in a few cases: when the client * Specify undefined behavior in a few cases: when the client
receives a DC without indicated support; when the client indicates receives a DC without indicated support; when the client indicates
the extension in an invalid protocol version; and when DCs are the extension in an invalid protocol version; and when DCs are
sent as extensions to certificates other than the end-entity sent as extensions to certificates other than the end-entity
certificate. certificate.
3. Solution Overview 3. Solution Overview
A delegated credential is a digitally signed data structure with two A delegated credential (DC) is a digitally signed data structure with
semantic fields: a validity interval and a public key (along with its two semantic fields: a validity interval and a public key (along with
associated signature algorithm). The signature on the credential its associated signature algorithm). The signature on the delegated
indicates a delegation from the certificate that is issued to the credential indicates a delegation from the certificate that is issued
peer. The private key used to sign a credential corresponds to the to the peer. The private key used to sign a credential corresponds
public key of the peer's X.509 end-entity certificate [RFC5280]. to the public key of the peer's X.509 end-entity certificate
[RFC5280].
A TLS handshake that uses delegated credentials differs from a A TLS handshake that uses delegated credentials differs from a
standard handshake in a few important ways: standard handshake in a few important ways:
* The initiating peer provides an extension in its ClientHello or * The initiating peer provides an extension in its ClientHello or
CertificateRequest that indicates support for this mechanism. CertificateRequest that indicates support for this mechanism.
* The peer sending the Certificate message provides both the * The peer sending the Certificate message provides both the
certificate chain terminating in its certificate as well as the certificate chain terminating in its certificate as well as the
delegated credential. delegated credential.
skipping to change at page 6, line 11 skipping to change at page 6, line 17
As detailed in Section 4, the delegated credential is As detailed in Section 4, the delegated credential is
cryptographically bound to the end-entity certificate with which the cryptographically bound to the end-entity certificate with which the
credential may be used. This document specifies the use of delegated 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 credentials in TLS 1.3 or later; their use in prior versions of the
protocol is not allowed. protocol is not allowed.
Delegated credentials allow a peer to terminate TLS connections on Delegated credentials allow a peer to terminate TLS connections on
behalf of the certificate owner. If a credential is stolen, there is behalf of the certificate owner. If a credential is stolen, there is
no mechanism for revoking it without revoking the certificate itself. no mechanism for revoking it without revoking the certificate itself.
To limit exposure in case of delegated credential private key To limit exposure in case of the compromise of a delegated
compromise, delegated credentials have a maximum validity period. In credential's private key, delegated credentials have a maximum
the absence of an application profile standard specifying otherwise, validity period. In the absence of an application profile standard
the maximum validity period is set to 7 days. Peers MUST NOT issue specifying otherwise, the maximum validity period is set to 7 days.
credentials with a validity period longer than the maximum validity Peers MUST NOT issue credentials with a validity period longer than
period. This mechanism is described in detail in Section 4.1. the maximum validity period. This mechanism is described in detail
in Section 4.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
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
that permits use of delegated credentials. (See Section 4.2.) that permits use of delegated credentials. (See Section 4.2.)
3.1. Rationale 3.1. Rationale
skipping to change at page 6, line 50 skipping to change at page 7, line 8
* Proxy certificates rely on the certificate path building process * 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.
* Each delegated credential is bound to a specific signature * Each delegated credential is bound to a specific signature
algorithm that may be used to sign the TLS handshake ([RFC8446] algorithm for use use in the TLS handshake ([RFC8446] section
section 4.2.3). This prevents them from being used with other, 4.2.3). This prevents them from being used with other, perhaps
perhaps unintended signature algorithms. unintended signature algorithms.
3.2. Related Work 3.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., a PKCS#11 interface or a remote signing client behavior (e.g., a PKCS#11 interface or a remote signing
mechanism [KEYLESS]). These mechanisms, however, incur per- mechanism [KEYLESS]). These mechanisms, however, incur per-
transaction latency, since the front-end server has to interact with transaction latency, since the front-end server has to interact with
a back-end server that holds a private key. The mechanism proposed 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 in this document allows the delegation to be done off-line, with no
skipping to change at page 7, line 29 skipping to change at page 7, line 34
Remote key signing: Remote key signing:
Client Front-End Back-End Client Front-End Back-End
|----ClientHello--->| | |----ClientHello--->| |
|<---ServerHello----| | |<---ServerHello----| |
|<---Certificate----| | |<---Certificate----| |
| |<---remote sign---->| | |<---remote sign---->|
|<---CertVerify-----| | |<---CertVerify-----| |
| ... | | | ... | |
Delegated credentials: Delegated Credential:
Client Front-End Back-End Client Front-End Back-End
| |<--DC distribution->| | |<--DC distribution->|
|----ClientHello--->| | |----ClientHello--->| |
|<---ServerHello----| | |<---ServerHello----| |
|<---Certificate----| | |<---Certificate----| |
|<---CertVerify-----| | |<---CertVerify-----| |
| ... | | | ... | |
These two mechanisms can be complementary. A server could use These two mechanisms can be complementary. A server could use
credentials for clients that support them, while using [KEYLESS] to delegated credentials for clients that support them, while using
support legacy clients. The private key for a delegated credential [KEYLESS] to support legacy clients. The private key for a delegated
can be used in place of a certificate private key, so it is important credential can be used in place of a certificate private key, so it
that the Front-End and Back-End are parties that have a trusted is important that the Front-End and Back-End are parties with a
relationship. trusted relationship.
Use of short-lived certificates with automated certificate issuance, Use of short-lived certificates with automated certificate issuance,
e.g., with Automated Certificate Managment Environment (ACME) e.g., with Automated Certificate Management Environment (ACME)
[RFC8555], reduces the risk of key compromise, but has several [RFC8555], reduces the risk of key compromise, but has several
limitations. Specifically, it introduces an operationally-critical limitations. Specifically, it introduces an operationally-critical
dependency on an external party. It also limits the types of dependency on an external party (the CA). It also limits the types
algorithms supported for TLS authentication to those the CA is of algorithms supported for TLS authentication to those the CA is
willing to issue a certificate for. Nonetheless, existing automated willing to issue a certificate for. Nonetheless, existing automated
issuance APIs like ACME may be useful for provisioning delegated issuance APIs like ACME may be useful for provisioning delegated
credentials. credentials.
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 valid to use them to issue issuers for other certificates, it is valid to use them to issue
other signed objects as long as the certificate contains the other signed objects as long as the certificate contains the
digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a digitalSignature KeyUsage ([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. The credential has the following are 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;
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
} Credential; } Credential;
valid_time: Time in seconds relative to the beginning of the valid_time: Time in seconds relative to 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. This MUST NOT exceed 7 days. credential is no longer valid. Endpoints will reject delegate
credentials with valid_times exceeding 7 days (as described in
Section 4.1).
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 the sender's
CertificateVerify.algorithm sent by the server. Only signature CertificateVerify.algorithm. Only signature algorithms allowed
algorithms allowed for use in CertificateVerify messages are for use in CertificateVerify messages are allowed. When using
allowed. When using RSA, the public key MUST NOT use the RSA, the public key MUST NOT use the rsaEncryption OID. As a
rsaEncryption OID, as a result, the following algorithms are not result, the following algorithms are not allowed for use with
allowed for use with delegated credentials: rsa_pss_rsae_sha256, delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. rsa_pss_rsae_sha512.
ASN1_subjectPublicKeyInfo: The credential's public key, a DER- ASN1_subjectPublicKeyInfo: The Credential's public key, a DER-
encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280].
The delegated credential has the following structure: The DelegatedCredential 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;
cred: The Credential structure as previously defined.
algorithm: The signature algorithm used to verify algorithm: The signature algorithm used to verify
DelegatedCredential.signature. DelegatedCredential.signature.
signature: The delegation, a signature that binds the credential to signature: The delegation, a signature that binds the credential to
the end-entity certificate's public key as specified below. The the end-entity certificate's public key as specified below. The
signature scheme is specified by DelegatedCredential.algorithm. 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" for 2. The context string "TLS, server delegated credentials" for server
servers and "TLS, client delegated credentials" for clients. authentication and "TLS, client delegated credentials" for client
authentication.
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.cred. 5. DelegatedCredential.cred.
6. DelegatedCredential.algorithm. 6. DelegatedCredential.algorithm.
The signature is computed by using the private key of the peer's end-
entity certificate, with the algorithm indicated by
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 and signature credentials are only used with the certificate and signature
algorithm chosen by the delegator. algorithm chosen by the delegator.
The code changes required in order to create and verify delegated The code changes required in order to create and verify delegated
credentials, and the implementation complexity this entails, are credentials, and the implementation complexity this entails, are
localized to the TLS stack. This has the advantage of avoiding localized to the TLS stack. This has the advantage of avoiding
changes to security-critical and often delicate PKI code. changes to security-critical and often delicate PKI code.
skipping to change at page 9, line 50 skipping to change at page 10, line 19
enum { enum {
... ...
delegated_credential(34), delegated_credential(34),
(65535) (65535)
} ExtensionType; } ExtensionType;
4.1.1. Server Authentication 4.1.1. Server Authentication
A client which supports this specification SHALL send a A client which supports this specification SHALL send a
"delegated_credential" extension in its ClientHello. The body of the "delegated_credential" extension in its ClientHello. The body of the
extension consists of a SignatureSchemeList: extension consists of a SignatureSchemeList (defined in [RFC8446]):
struct { struct {
SignatureScheme supported_signature_algorithm<2..2^16-2>; SignatureScheme supported_signature_algorithm<2..2^16-2>;
} SignatureSchemeList; } SignatureSchemeList;
If the client receives a delegated credential without indicating If the client receives a delegated credential without indicating
support, then the client MUST abort with an "unexpected_message" support, then the client MUST abort with an "unexpected_message"
alert. alert.
If the extension is present, the server MAY send a delegated If the extension is present, the server MAY send a delegated
skipping to change at page 11, line 14 skipping to change at page 11, line 30
credentials MUST terminate the connection with an "illegal_parameter" credentials MUST terminate the connection with an "illegal_parameter"
alert. alert.
4.1.3. Validating a Delegated Credential 4.1.3. Validating a Delegated Credential
On receiving a delegated credential and a certificate chain, the peer On receiving a delegated credential and a certificate chain, the peer
validates the certificate chain and matches the end-entity validates the certificate chain and matches the end-entity
certificate to the peer's expected identity. It also takes the certificate to the peer's expected identity. It also takes the
following steps: following steps:
1. Verify that the current time is within the validity interval of 1. Validate that DelegatedCredential.cred.valid_time is no more than
7 days.
2. Verify that the current time is within the validity interval of
the credential. This is done by asserting that the current time the credential. This is done by asserting that the current time
is no more than the delegation certificate's notBefore value plus is no more than the delegation certificate's notBefore value plus
DelegatedCredential.cred.valid_time. DelegatedCredential.cred.valid_time.
2. Verify that the credential's remaining validity time is no more 3. Verify that the delegated credential's remaining validity time is
than the maximum validity period. This is done by asserting that no more than the maximum validity period. This is done by
the current time is no more than the delegation certificate's asserting that the current time is no more than the delegation
notBefore value plus DelegatedCredential.cred.valid_time plus the certificate's notBefore value plus
maximum validity period. DelegatedCredential.cred.valid_time plus the maximum validity
period.
3. Verify that expected_cert_verify_algorithm matches the scheme 4. Verify that expected_cert_verify_algorithm matches the scheme
indicated in the peer's CertificateVerify message and that the indicated in the peer's CertificateVerify message and that the
algorithm is allowed for use with delegated credentials. algorithm is allowed for use with delegated credentials.
4. Verify that the end-entity certificate satisfies the conditions 5. Verify that the end-entity certificate satisfies the conditions
in Section 4.2. in Section 4.2.
5. Use the public key in the peer's end-entity certificate to verify 6. Use the public key in the peer's end-entity certificate to verify
the signature of the credential using the algorithm indicated by the signature of the credential using the algorithm indicated by
DelegatedCredential.algorithm. 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 and servers that receive invalid delegated deemed invalid. Clients and servers that receive invalid delegated
credentials MUST terminate the connection with an "illegal_parameter" credentials MUST terminate the connection with an "illegal_parameter"
alert. If successful, the participant receiving the Certificate alert.
message uses the public key in the credential to verify the signature
in the peer's CertificateVerify message. If successful, the participant receiving the Certificate message uses
the public key in DelegatedCredential.cred to verify the signature in
the peer's CertificateVerify message.
4.2. Certificate Requirements 4.2. 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. What follows is the ASN.1 [X.680] for the credentials. What follows is the ASN.1 [X.680] for the
DelegationUsage certificate extension. DelegationUsage certificate extension.
ext-delegationUsage EXTENSION ::= { ext-delegationUsage EXTENSION ::= {
SYNTAX DelegationUsage IDENTIFIED BY id-ce-delegationUsage SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage
} }
DelegationUsage ::= NULL DelegationUsage ::= NULL
id-ce-delegationUsage OBJECT IDENTIFIER ::= id-pe-delegationUsage OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) id-cloudflare(44363) 44 } private(4) enterprise(1) id-cloudflare(44363) 44 }
The extension MUST be marked non-critical. (See Section 4.2 of The extension MUST be marked non-critical. (See Section 4.2 of
[RFC5280].) The client MUST NOT accept a delegated credential unless [RFC5280].) The client MUST NOT accept a delegated credential unless
the server's end-entity certificate satisfies the following criteria: the server's end-entity certificate satisfies the following criteria:
* It has the DelegationUsage extension. * It has the DelegationUsage extension.
* It has the digitalSignature KeyUsage (see the KeyUsage extension * It has the digitalSignature KeyUsage (see the KeyUsage extension
skipping to change at page 12, line 29 skipping to change at page 13, line 4
* It has the DelegationUsage extension. * It has the DelegationUsage extension.
* It has the digitalSignature KeyUsage (see the KeyUsage extension * It has the digitalSignature KeyUsage (see the KeyUsage extension
defined in [RFC5280]). defined in [RFC5280]).
A new extension was chosen instead of adding a new Extended Key Usage A new extension was chosen instead of adding a new Extended Key Usage
(EKU) to be compatible with deployed TLS and PKI software stacks (EKU) to be compatible with deployed TLS and PKI software stacks
without requiring CAs to issue new intermediate certificates. without requiring CAs to issue new intermediate certificates.
5. Operational Considerations 5. Operational Considerations
5.1. Client Clock Skew 5.1. Client Clock Skew
One of the risks of deploying a short-lived credential system based One of the risks of deploying a short-lived credential system based
on absolute time is client clock skew. If a client's clock is on absolute time is client clock skew. If a client's clock is
sufficiently ahead or behind of the server's clock, then clients will sufficiently ahead or behind of the server's clock, then clients will
reject credentials that are valid from the server's perspective. reject delegated credentials that are valid from the server's
Clock skew also affects the validity of the original certificates. perspective. Clock skew also affects the validity of the original
The lifetime of the delegated credential should be set taking clock certificates. The lifetime of the delegated credential should be set
skew into account. Clock skew may affect a delegated credential at taking clock skew into account. Clock skew may affect a delegated
the beginning and end of its validity periods, which should also be credential at the beginning and end of its validity periods, which
taken into account. should also be taken into account.
6. IANA Considerations 6. IANA Considerations
This document registers the "delegated_credentials" extension in the This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry. The "delegated_credentials" "TLS ExtensionType Values" registry. The "delegated_credentials"
extension has been assigned a code point of 34. The IANA registry extension has been assigned a code point of 34. The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH), CertificateRequest (CR), or it may appear in the ClientHello (CH), CertificateRequest (CR), or
Certificate (CT) messages in TLS 1.3 [RFC8446]. Certificate (CT) messages in TLS 1.3 [RFC8446].
This document also defines an ASN.1 module for the DelegationUsage This document also defines an ASN.1 module for the DelegationUsage
certificate extension in Appendix A. IANA is requested to register certificate extension in Appendix A. IANA has registered value 95
an Object Identfier (OID) for the ASN.1 in "SMI Security for PKIX for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX
Module Identifier" arc. An OID for the DelegationUsage certificate Module Identifier" (1.3.5.1.5.5.7.0) registry. An OID for the
extension is not needed as it is already assigned to the extension DelegationUsage certificate extension is not needed as it is already
from Cloudflare's IANA Private Enterprise Number (PEN) arc. assigned to the extension from Cloudflare's IANA Private Enterprise
Number (PEN) arc.
7. Security Considerations 7. Security Considerations
7.1. Security of Delegated Credential's Private Key 7.1. Security of Delegated Credential's Private Key
Delegated credentials limit the exposure of the private key used in a Delegated credentials limit the exposure of the private key used in a
TLS connection by limiting its validity period. An attacker who TLS connection by limiting its validity period. An attacker who
compromises the private key of a delegated credential can act as a compromises the private key of a delegated credential can act as a
man-in-the-middle until the delegated credential expires. However, man-in-the-middle until the delegated credential expires. However,
they cannot create new delegated credentials. Thus, delegated they cannot create new delegated credentials. Thus, delegated
skipping to change at page 13, line 36 skipping to change at page 14, line 16
It is not possible to use the same delegated credential for both It is not possible to use the same delegated credential for both
client and server authentication because issuing parties compute the client and server authentication because issuing parties compute the
corresponding signature using a context string unique to the intended corresponding signature using a context string unique to the intended
role (client or server). role (client or server).
7.3. Revocation of Delegated Credentials 7.3. 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 revokes the credential. Revocation of the long term
private key that signs the delegated credential also implicitly private key that signs the delegated credential (from the end-entity
revokes the delegated credential. certificate) also implicitly revokes the delegated credential.
7.4. Interactions with Session Resumption 7.4. Interactions with Session Resumption
If a client decides to cache the certificate chain and re-validate it If a client decides to cache the certificate chain and re-validate it
when resuming a connection, the client SHOULD also cache the when resuming a connection, the client SHOULD also cache the
associated delegated credential and re-validate it. associated delegated credential and re-validate it.
7.5. Privacy Considerations 7.5. Privacy Considerations
Delegated credentials can be valid for 7 days and it is much easier Delegated credentials can be valid for 7 days and it is much easier
for a service to create delegated credential than a certificate for a service to create delegated credentials than a certificate
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.
7.6. The Impact of Signature Forgery Attacks 7.6. The Impact of Signature Forgery Attacks
When TLS 1.2 servers support RSA key exchange, they may be vulnerable When TLS 1.2 servers support RSA key exchange, they may be vulnerable
to attacks that allow forging an RSA signature over an arbitrary to attacks that allow forging an RSA signature over an arbitrary
message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a
mitigation strategy requiring careful implementation of timing mitigation strategy requiring careful implementation of timing
resistant countermeasures for preventing these attacks. Experience resistant countermeasures for preventing these attacks. Experience
shows that in practice, server implementations may fail to fully stop shows that in practice, server implementations may fail to fully stop
these attacks due to the complexity of this mitigation [ROBOT]. For these attacks due to the complexity of this mitigation [ROBOT]. For
TLS 1.2 servers that support RSA key exchange using a DC-enabled end- TLS 1.2 servers that support RSA key exchange using a DC-enabled end-
entity certificate, a hypothetical signature forgery attack would entity certificate, a hypothetical signature forgery attack would
allow forging a signature over a delegated credential. The forged allow forging a signature over a delegated credential. The forged
credential could then be used by the attacker as the equivalent of a delegated credential could then be used by the attacker as the
man-in-the-middle certificate, valid for 7 days. equivalent of a man-in-the-middle certificate, valid for a maximum of
7 days.
Server operators should therefore minimize the risk of using DC- Server operators should therefore minimize the risk of using DC-
enabled end-entity certificates where a signature forgery oracle may enabled end-entity certificates where a signature forgery oracle may
be present. If possible, server operators may choose to use DC- be present. If possible, server operators may choose to use DC-
enabled certificates only for signing credentials, and not for enabled certificates only for signing credentials, and not for
serving non-DC TLS traffic. Furthermore, server operators may use serving non-DC TLS traffic. Furthermore, server operators may use
elliptic curve certificates for DC-enabled traffic, while using RSA elliptic curve certificates for DC-enabled traffic, while using RSA
certificates without the DelegationUsage certificate extension for certificates without the DelegationUsage certificate extension for
non-DC traffic; this completely prevents such attacks. non-DC traffic; this completely prevents such attacks.
skipping to change at page 16, line 21 skipping to change at page 16, line 40
[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-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of [ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of
Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX
Security Symposium , 2018. Security Symposium , 2018.
[XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the
skipping to change at page 17, line 33 skipping to change at page 17, line 44
-- OID -- OID
id-cloudflare OBJECT IDENTIFIER ::= id-cloudflare OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) private(4) { iso(1) identified-organization(3) dod(6) internet(1) private(4)
enterprise(1) 44363 } enterprise(1) 44363 }
-- EXTENSION -- EXTENSION
ext-delegationUsage EXTENSION ::= ext-delegationUsage EXTENSION ::=
{ SYNTAX DelegationUsage { SYNTAX DelegationUsage
IDENTIFIED BY id-ce-delegationUsage } IDENTIFIED BY id-pe-delegationUsage }
id-ce-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 }
DelegationUsage ::= NULL DelegationUsage ::= NULL
END END
Appendix B. Example Certificate
The following certificate has the Delegated Credentials OID.
-----BEGIN CERTIFICATE-----
MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz
MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw
FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu
MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
d4azI83Bw0fcPgfoeiZpZZnwGuxjBjv++wzE0zAj8vNiUkKxOWSQiGNLn+xlWUpL
lw9djRN1rLmVmn2gb9GgdKOCA28wggNrMB8GA1UdIwQYMBaAFKOd5h/52jlPwG7o
kcuVpdox4gqfMB0GA1UdDgQWBBSfcb7fS3fUFAyB91fRcwoDPtgtJjAjBgNVHREE
HDAaggprYzJrZG0uY29tggwqLmtjMmtkbS5jb20wDgYDVR0PAQH/BAQDAgeAMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6gLKAqhiho
dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6gLKAqhiho
dHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwGA1UdIARF
MEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj
ZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcw
AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8v
Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2ZXJDQS5j
cnQwDAYDVR0TAQH/BAIwADAPBgkrBgEEAYLaSywEAgUAMIIBfgYKKwYBBAHWeQIE
AgSCAW4EggFqAWgAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAA
AWm5hYJ5AAAEAwBHMEUCICiGfq+hSThRL2m8H0awoDR8OpnEHNkF0nI6nL5yYL/j
AiEAxwebGs/T6Es0YarPzoQJrVZqk+sHH/t+jrSrKd5TDjcAdgCHdb/nWXz4jEOZ
X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6
bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw
0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA
AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X
/AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD
aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe
muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt
y5S4RfWHIIPjbw==
-----END CERTIFICATE-----
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
Cisco Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
Subodh Iyengar Subodh Iyengar
Facebook Facebook
 End of changes. 47 change blocks. 
92 lines changed or deleted 159 lines changed or added

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