draft-ietf-tls-subcerts-05.txt   draft-ietf-tls-subcerts-06.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: May 6, 2020 Facebook Expires: 8 August 2020 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
Mozilla Mozilla
November 03, 2019 5 February 2020
Delegated Credentials for TLS Delegated Credentials for TLS
draft-ietf-tls-subcerts-05 draft-ietf-tls-subcerts-06
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 1, line 42 skipping to change at page 1, line 42
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 May 6, 2020. This Internet-Draft will expire on 8 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 7 3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Client and Server behavior . . . . . . . . . . . . . . . 8 4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Server authentication . . . . . . . . . . . . . . . . 8 4.1. Client and Server behavior . . . . . . . . . . . . . . . 8
3.1.2. Client authentication . . . . . . . . . . . . . . . . 9 4.1.1. Server authentication . . . . . . . . . . . . . . . . 9
3.1.3. Validating a Delegated Credential . . . . . . . . . . 9 4.1.2. Client authentication . . . . . . . . . . . . . . . . 9
3.2. Certificate Requirements . . . . . . . . . . . . . . . . 10 4.1.3. Validating a Delegated Credential . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Security of delegated private key . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.2. Re-use of delegated credentials in multiple contexts . . 11 6.1. Security of delegated private key . . . . . . . . . . . . 12
5.3. Revocation of delegated credentials . . . . . . . . . . . 11 6.2. Re-use of delegated credentials in multiple
5.4. Interactions with session resumption . . . . . . . . . . 12 contexts . . . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Privacy considerations . . . . . . . . . . . . . . . . . 12 6.3. Revocation of delegated credentials . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Interactions with session resumption . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Privacy considerations . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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:
o Whenever the server operator wants to deploy a new certificate, it * Whenever the server operator wants to deploy a new certificate, it
has to interact with the CA. has to interact with the CA.
o The server operator can only use TLS authentication schemes for * 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 Content Delivery Network (CDNs) or remote data trust zones such as Content Delivery Network (CDNs) or remote data
centers. This allows server operators to limit the exposure of keys centers. This allows server operators to limit the exposure of keys
in cases that they do not realize a compromise has occurred. The in cases that they do not realize a compromise has occurred. The
risk inherent in cross-organizational transactions makes it risk inherent in cross-organizational transactions makes it
operationally infeasible to rely on an external CA for such short- operationally infeasible to rely on an external CA for such short-
lived credentials. In Online Certiicate Status Protocol (OCSP) lived credentials. In Online Certificate Status Protocol (OCSP)
stapling (i.e., using the Certificate Status extension types ocsp stapling (i.e., using the Certificate Status extension type ocsp
[RFC6066] or ocsp_multi [RFC6961]), if an operator chooses to talk [RFC8446], if an operator chooses to talk frequently to the CA to
frequently to the CA to obtain stapled responses, then failure to obtain stapled responses, then failure to fetch an OCSP stapled
fetch an OCSP stapled response results only in degraded performance. response results only in degraded performance. On the other hand,
On the other hand, failure to fetch a potentially large number of failure to fetch a potentially large number of short lived
short lived certificates would result in the service not being certificates would result in the service not being available, which
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 peer to issue its own 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. Because the above problems do not relate to the CA's inherent CA. Because the above problems do not relate to the CA's inherent
function of validating possession of names, it is safe to make such function of validating possession of names, it is safe to make such
delegations as long as they only enable the recipient of the delegations as long as they only enable the recipient of the
delegation to speak for names that the CA has authorized. For 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" or "DC". operator as a "delegated credential" or "DC".
1.1. Change Log 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Change Log
(*) indicates changes to the wire protocol. (*) indicates changes to the wire protocol.
draft-05 draft-06
o Removed support for PKCS 1.5 RSA signature algorithms. * Modified IANA section, fixed nits
o Additional security considerations. draft-05
* Removed support for PKCS 1.5 RSA signature algorithms.
* Additional security considerations.
draft-04 draft-04
o Add support for client certificates. * Add support for client certificates.
draft-03 draft-03
o Remove protocol version from the Credential structure. (*) * Remove protocol version from the Credential structure. (*)
o Change public key type. (*)
o Change DelegationUsage extension to be NULL and define its object draft-02
* Change public key type. (*)
* Change DelegationUsage extension to be NULL and define its object
identifier. identifier.
o Drop support for TLS 1.2. * Drop support for TLS 1.2.
o Add the protocol version and credential signature algorithm to the * Add the protocol version and credential signature algorithm to the
Credential structure. (*) Credential structure. (*)
o 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.
2. Solution Overview 3. Solution Overview
A delegated credential is a digitally signed data structure with two A delegated credential is a digitally signed data structure with two
semantic fields: a validity interval and a public key (along with its semantic fields: a validity interval and a public key (along with its
associated signature algorithm). The signature on the credential associated signature algorithm). The signature on the credential
indicates a delegation from the certificate that is issued to the indicates a delegation from the certificate that is issued to the
peer. The secret key used to sign a credential corresponds to the peer. The secret key used to sign a credential corresponds to the
public key of the peer's X.509 end-entity certificate [RFC5280]. public key of the peer's X.509 end-entity certificate [RFC5280].
A TLS handshake that uses delegated credentials differs from a normal A TLS handshake that uses delegated credentials differs from a normal
handshake in a few important ways: handshake in a few important ways:
o 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.
o 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.
o The authenticating intitiator uses information from the peer's * The authenticating intitiator uses information from the peer's
certificate to verify the delegated credential and that the peer certificate to verify the delegated credential and that the peer
is asserting an expected identity. is asserting an expected identity.
o Peers accepting the delegated credential use it as the * Peers accepting the delegated credential use it as the
certificate's working key for the TLS hadshake certificate's working key for the TLS hadshake
As detailed in Section 3, 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 a delegated credential is compromised, To limit exposure in case of delegated credential private key
peers may not issue credentials with a validity period longer than 7 compromise, delegated credentials have a maximum validity period. In
days. This mechanism is described in detail in Section 3.1. the absence of an application profile standard specifying otherwise,
the maximum validity period is set to 7 days. Peers MUST NOT issue
credentials with a validity period longer than 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 3.2.) that permits use of delegated credentials. (See Section 4.2.)
2.1. Rationale 3.1. Rationale
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 * There is no change needed to certificate validation at the PKI
layer. layer.
o X.509 semantics are very rich. This can cause unintended * 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 that 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 * 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 signature * Each delegated credential is bound to a specific signature
algorithm that may be used to sign the TLS handshake ([RFC8446] algorithm that may be used to sign the TLS handshake ([RFC8446]
section 4.2.3). This prevents them from being used with other, section 4.2.3). This prevents them from being used with other,
perhaps unintended signature algorithms. perhaps unintended signature algorithms.
2.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
per-transaction latency. The figure below compares the message flows per-transaction latency. The figure below compares the message flows
for these two mechanisms with TLS 1.3 [RFC8446]. for these two mechanisms with TLS 1.3 [RFC8446].
skipping to change at page 7, line 5 skipping to change at page 7, line 15
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 Automated Certificate by automating certificate issuance, e.g., with Automated Certificate
Managmeent Encvironment (ACME) [RFC8555]. In addition to requiring Managmeent Encvironment (ACME) [RFC8555]. In addition to requiring
frequent operationally-critical interactions with an external party, frequent operationally-critical interactions with an external party,
this makes the server operator dependent on the CA's willingness to this makes the server operator dependent on the CA's willingness to
issue certificates with sufficiently short lifetimes. It also fails issue certificates with sufficiently short lifetimes. It also fails
to address the issues with algorithm support. Nonetheless, existing to 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 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 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 {
skipping to change at page 7, line 36 skipping to change at page 7, line 46
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. Only signature CertificateVerify.algorithm sent by the server. Only signature
algorithms allowed for use in CertificateVerify messages are algorithms allowed for use in CertificateVerify messages are
allowed. When using RSA, the public key MUST NOT use the allowed. When using RSA, the public key MUST NOT use the
rsaEncryption OID, as a result, the following algorithms are not rsaEncryption OID, as a result, the following algorithms are not
allowed for use with delegated credentials: rsa_pss_rsae_sha256, allowed for use with delegated credentials: rsa_pss_rsae_sha256,
rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.
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 [X.690] 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
skipping to change at page 8, line 34 skipping to change at page 8, line 47
credentials are only used with the certificate and signature credentials are only used with the certificate and signature
algorithm chosen by the delegator. Minimizing their semantics in algorithm chosen by the delegator. Minimizing their semantics in
this way is intended to mitigate the risk of cross protocol attacks this way is intended to mitigate the risk of cross protocol attacks
involving delegated credentials. involving delegated credentials.
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.
3.1. Client and Server behavior 4.1. Client and Server behavior
This document defines the following TLS extension code point. This document defines the following TLS extension code point.
enum { enum {
... ...
delegated_credential(TBD), delegated_credential(34),
(65535) (65535)
} ExtensionType; } ExtensionType;
3.1.1. Server authentication 4.1.1. Server authentication
A client which supports this specification SHALL send an empty A client which supports this specification SHALL send a
"delegated_credential" extension in its ClientHello. If the client "delegated_credential" extension in its ClientHello. The body of the
receives a delegated credential without indicating support, then the extension consists of a SignatureSchemeList:
client MUST abort with an "unexpected_message" alert.
struct {
SignatureScheme supported_signature_algorithm<2..2^16-2>;
} SignatureSchemeList;
If the client receives a delegated credential without indicating
support, then the client MUST abort with an "unexpected_message"
alert.
If the extension is present, the server MAY send a delegated If the extension is present, the server MAY send a delegated
credential; if the extension is not present, the server MUST NOT send credential; if the extension is not present, the server MUST NOT send
a delegated credential. The server MUST ignore the extension unless a delegated credential. The server MUST ignore the extension unless
TLS 1.3 or a later version is negotiated. TLS 1.3 or a later version is negotiated.
The server MUST send the delegated credential as an extension in the The server MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the client SHOULD CertificateEntry of its end-entity certificate; the client SHOULD
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" extension type advertised by the client in the SignatureSchemeList and are
and are considered invalid otherwise. Clients that receive invalid considered invalid otherwise. Clients that receive invalid delegated
delegated credentials MUST terminate the connection with an credentials MUST terminate the connection with an "illegal_parameter"
"illegal_parameter" alert. alert.
3.1.2. Client authentication 4.1.2. Client authentication
A server which supports this specification SHALL send an empty A server which supports this specification SHALL send an empty
"delegated_credential" extension in the CertificateRequest message "delegated_credential" extension in the CertificateRequest message
when requesting client authentication. If the server receives a when requesting client authentication. If the server receives a
delegated credential without indicating support in its delegated credential without indicating support in its
CertificateRequest, then the server MUST abort with an CertificateRequest, then the server MUST abort with an
"unexpected_message" alert. "unexpected_message" alert.
If the extension is present, the client MAY send a delegated If the extension is present, the client MAY send a delegated
credential; if the extension is not present, the client MUST NOT send credential; if the extension is not present, the client MUST NOT send
skipping to change at page 9, line 43 skipping to change at page 10, line 18
CertificateEntry of its end-entity certificate; the server SHOULD CertificateEntry of its end-entity certificate; the server SHOULD
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 server in the "signature_algorithms" extension type advertised by the server in the "signature_algorithms" extension
and are considered invalid otherwise. Servers that receive invalid and are considered invalid otherwise. Servers that receive invalid
delegated credentials MUST terminate the connection with an delegated credentials MUST terminate the connection with an
"illegal_parameter" alert. "illegal_parameter" alert.
3.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 in the usual way. It certificate to the peer's expected identity in the usual way. 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. This is done by asserting that the current time is than the maximum validity period. This is done by asserting that
no more than the delegation certificate's notBefore value plus the current time is no more than the delegation certificate's
DelegatedCredential.cred.valid_time. 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 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.
3. Verify that the end-entity certificate satisfies the conditions 3. Verify that the end-entity certificate satisfies the conditions
in Section 3.2. in Section 4.2.
4. Use the public key in the peer's end-entity certificate to verify 4. 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. If successful, the participant receiving the Certificate
message uses the public key in the credential to verify the signature message uses the public key in the credential to verify the signature
in the peer's CertificateVerify message. in the peer's CertificateVerify message.
3.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 [X680] 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-ce-delegationUsage
} }
DelegationUsage ::= NULL DelegationUsage ::= NULL
id-ce-delegationUsage OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 44363 44 } id-ce-delegationUsage OBJECT IDENTIFIER ::= {
1 3 6 1 4 1 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:
o It has the DelegationUsage extension. * It has the DelegationUsage extension.
o It has the digitalSignature KeyUsage (see the KeyUsage extension * It has the digitalSignature KeyUsage (see the KeyUsage extension
defined in [RFC5280]). defined in [RFC5280]).
4. IANA Considerations 5. 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 TBD. 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 is requested to register
an Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX an Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX
Module Identifier" arc. An OID for the DelegationUsage certificate Module Identifier" arc. An OID for the DelegationUsage certificate
extension is not needed as it is already assigned to the extension extension is not needed as it is already assigned to the extension
from Cloudflare's IANA Private Enterprise Number (PEN) arc. from Cloudflare's IANA Private Enterprise Number (PEN) arc.
5. Security Considerations 6. Security Considerations
6.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 credentials. Thus, delegated credentials should not be used to send
a 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, including access control mechanisms SHOULD be used to protect it, including
file system controls, physical security, or hardware security file system controls, physical security, or hardware security
modules. modules.
5.2. Re-use of delegated credentials in multiple contexts 6.2. Re-use of delegated credentials in multiple contexts
It is possible to use the same delegated credential for both client It is possible to use the same delegated credential for both client
and server authentication if the Certificate allows it. This is safe and server authentication if the Certificate allows it. This is safe
because the context string used for delegated credentials is distinct because the context string used for delegated credentials is distinct
in both contexts. in both contexts.
5.3. Revocation of delegated credentials 6.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 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.4. Interactions with session resumption 6.4. Interactions with session resumption
If a client decides to cache the certificate chain an re-validate it If a client decides to cache the certificate chain an 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.
5.5. Privacy considerations 6.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 credential 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.
6. Acknowledgements 7. Acknowledgements
Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh
Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson
Ladd for their discussions, ideas, and bugs they have found. Ladd for their discussions, ideas, and bugs they have found.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
DOI 10.17487/RFC5912, June 2010, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
<https://www.rfc-editor.org/info/rfc5912>.
[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,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[X680] ITU-T, "Information technology - Abstract Syntax Notation [X.680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ISO/ One (ASN.1): Specification of basic notation", ISO/
IEC 8824-1:2015, November 2015. IEC 8824-1:2015, November 2015.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X.690] 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:2015, November 2015. (DER)", ISO/IEC 8825-1:2015, November 2015.
7.2. Informative References 8.2. Informative References
[KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake
Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015.
[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-editor.org/info/rfc3820>. <https://www.rfc-editor.org/info/rfc3820>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Extensions: Extension Definitions", RFC 6066, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>.
[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>.
[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.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
The following ASN.1 module provides the complete definition of the The following ASN.1 module provides the complete definition of the
DelegationUsage certificate extension. The ASN.1 module makes DelegationUsage certificate extension. The ASN.1 module makes
imports from [RFC5912]. imports from [RFC5912].
DelegatedCredentialExtn { joint-iso-itu-t(2) country(16) us(840) DelegatedCredentialExtn { iso(1) identified-organization(3) dod(6)
organization(1) gov(101) dod(2) infosec(1) modules(0) id-mod- internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-
delegate-credential-extn(TBD) } delegated-credential-extn(TBD) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
- EXPORT ALL - EXPORT ALL
IMPORTS IMPORTS
EXTENSION FROM PKIX-CommonTypes-2009 - From RFC 5912 { iso(1) EXTENSION FROM PKIX-CommonTypes-2009 - From RFC 5912 { iso(1)
identified-organization(3) dod(6) internet(1) security(5) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ;
 End of changes. 69 change blocks. 
132 lines changed or deleted 158 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/