rfc9345.original   rfc9345.txt 
Network Working Group R. Barnes Internet Engineering Task Force (IETF) R. Barnes
Internet-Draft Cisco Request for Comments: 9345 Cisco
Intended status: Standards Track S. Iyengar Category: Standards Track S. Iyengar
Expires: 17 December 2022 Facebook ISSN: 2070-1721 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
Mozilla Windy Hill Systems, LLC
15 June 2022 July 2023
Delegated Credentials for (D)TLS Delegated Credentials for (D)TLS
draft-ietf-tls-subcerts-15
Abstract Abstract
The organizational separation between operators of TLS and DTLS The organizational separation between operators of TLS and DTLS
endpoints and the certification authority can create limitations. endpoints and the certification authority can create limitations.
For example, the lifetime of certificates, how they may be used, and For example, the lifetime of certificates, how they may be used, and
the algorithms they support are ultimately determined by the the algorithms they support are ultimately determined by the
certification authority. This document describes a mechanism to to Certification Authority (CA). This document describes a mechanism to
overcome some of these limitations by enabling operators to delegate overcome some of these limitations by enabling operators to delegate
their own credentials for use in TLS and DTLS without breaking their own credentials for use in TLS and DTLS without breaking
compatibility with peers that do not support this specification. compatibility with peers that do not support this specification.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/tls-subcerts (https://github.com/tlswg/tls-
subcerts).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 17 December 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9345.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Conventions and Terminology 2. Conventions and Terminology
2.1. Change Log
3. Solution Overview 3. Solution Overview
3.1. Rationale 3.1. Rationale
3.2. Related Work 3.2. Related Work
4. Delegated Credentials 4. Delegated Credentials
4.1. Client and Server Behavior 4.1. Client and Server Behavior
4.1.1. Server Authentication 4.1.1. Server Authentication
4.1.2. Client Authentication 4.1.2. Client Authentication
4.1.3. Validating a Delegated Credential 4.1.3. Validating a Delegated Credential
4.2. Certificate Requirements 4.2. Certificate Requirements
5. Operational Considerations 5. Operational Considerations
5.1. Client Clock Skew 5.1. Client Clock Skew
6. IANA Considerations 6. IANA Considerations
7. Security Considerations 7. Security Considerations
7.1. Security of Delegated Credential's Private Key 7.1. Security of Delegated Credential's Private Key
7.2. Re-use of Delegated Credentials in Multiple Contexts 7.2. Re-use of Delegated Credentials in Multiple Contexts
7.3. Revocation of Delegated Credentials 7.3. Revocation of Delegated Credentials
7.4. Interactions with Session Resumption 7.4. Interactions with Session Resumption
7.5. Privacy Considerations 7.5. Privacy Considerations
7.6. The Impact of Signature Forgery Attacks 7.6. The Impact of Signature Forgery Attacks
8. Acknowledgements 8. References
9. References 8.1. Normative References
9.1. Normative References 8.2. Informative References
9.2. Informative References
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
Appendix B. Example Certificate Appendix B. Example Certificate
Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
Server operators often deploy (D)TLS termination to act as the server Server operators often deploy (D)TLS termination to act as the server
for inbound TLS connections. These termination services can be in for inbound TLS connections. These termination services can be in
locations such as remote data centers or Content Delivery Networks locations such as remote data centers or Content Delivery Networks
(CDNs) where it may be difficult to detect compromises of private key (CDNs) where it may be difficult to detect compromises of private key
material corresponding to TLS certificates. Short-lived certificates material corresponding to TLS certificates. Short-lived certificates
may be used to limit the exposure of keys in these cases. may be used to limit the exposure of keys in these cases.
However, short-lived certificates need to be renewed more frequently However, short-lived certificates need to be renewed more frequently
than long-lived certificates. If an external Certification Authority than long-lived certificates. If an external Certification Authority
(CA) is unable to issue a certificate in time to replace a deployed (CA) is unable to issue a certificate in time to replace a deployed
certificate, the server would no longer be able to present a valid certificate, the server would no longer be able to present a valid
certificate to clients. With short-lived certificates, there is a certificate to clients. With short-lived certificates, there is a
smaller window of time to renew a certificates and therefore a higher smaller window of time to renew a certificate and therefore a higher
risk that an outage at a CA will negatively affect the uptime of the risk that an outage at a CA will negatively affect the uptime of the
TLS-fronted service. TLS-fronted service.
Typically, a (D)TLS server uses a certificate provided by some entity Typically, a (D)TLS server uses a certificate provided by some entity
other than the operator of the server (a CA) [RFC8446] [RFC5280]. other than the operator of the server (a CA) [RFC8446] [RFC5280].
This organizational separation makes the (D)TLS server operator This organizational separation makes the (D)TLS server operator
dependent on the CA for some aspects of its operations, for example: dependent on the CA for some aspects of its 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
has to interact with the CA. has to interact with the CA.
* The CA might only issue credentials containing certain types of * The CA might only issue credentials containing certain types of
public key, which can limit the set of (D)TLS signature schemes public keys, which can limit the set of (D)TLS signature schemes
usable by the server operator. usable by the server operator.
To reduce the dependency on external CAs, this document specifies a To reduce the dependency on external CAs, this document specifies a
limited delegation mechanism that allows a (D)TLS peer to issue its limited delegation mechanism that allows a (D)TLS peer to issue its
own credentials within the scope of a certificate issued by an own credentials within the scope of a certificate issued by an
external CA. These credentials only enable the recipient of the external CA. These credentials only enable the recipient of the
delegation to terminate connections for names that the CA has delegation to terminate connections for names that the CA has
authorized. Furthermore, this mechanism allows the server to use authorized. Furthermore, this mechanism allows the server to use
modern signature algorithms such as Ed25519 [RFC8032] even if their modern signature algorithms such as Ed25519 [RFC8032] even if their
CA does not support them. CA does not support them.
This document refers to the certificate issued by the CA as a This document refers 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".
Client Front-End Back-End
| |<--DC distribution->|
|----ClientHello--->| |
|<---ServerHello----| |
|<---Certificate----| |
|<---CertVerify-----| |
| ... | |
Legend:
Client: (D)TLS client
Front-End: (D)TLS server (could be a TLS-termination service like a CDN)
Back-End: Service with access to private key
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1. Change Log
RFC EDITOR PLEASE DELETE THIS SECTION.
(*) indicates changes to the wire protocol.
draft-11
* Editorial changes based on AD comments
* Add support for DTLS
* Address address ambiguity in cert expiry
draft-10
* Address superficial comments
* Add example certificate
draft-09
* Address case nits
* Fix section bullets in 4.1.3.
* Add operational considerations section for clock skew
* Add text around using an oracle to forge DCs in the future and
past
* Add text about certificate extension vs EKU
draft-08
* Include details about the impact of signature forgery attacks
* Copy edits
* Fix section about DC reuse
* Incorporate feedback from Jonathan Hammell and Kevin Jacobs on the
list
draft-07
* Minor text improvements
draft-06
* Modified IANA section, fixed nits
draft-05
* Removed support for PKCS 1.5 RSA signature algorithms.
* Additional security considerations.
draft-04
* Add support for client certificates.
draft-03
* Remove protocol version from the Credential structure. (*)
draft-02
* Change public key type. (*)
* Change DelegationUsage extension to be NULL and define its object
identifier.
* Drop support for TLS 1.2.
* Add the protocol version and credential signature algorithm to the
Credential structure. (*)
* Specify undefined behavior in a few cases: when the client
receives a DC without indicated support; when the client indicates
the extension in an non-valid protocol version; and when DCs are
sent as extensions to certificates other than the end-entity
certificate.
3. Solution Overview 3. Solution Overview
A delegated credential (DC) is a digitally signed data structure with A delegated credential (DC) is a digitally signed data structure with
two semantic fields: a validity interval and a public key (along with two semantic fields: a validity interval and a public key (along with
its associated signature algorithm). The signature on the delegated its associated signature algorithm). The signature on the delegated
credential indicates a delegation from the certificate that is issued credential indicates a delegation from the certificate that is issued
to the peer. The private key used to sign a credential corresponds to the peer. The private key used to sign a credential corresponds
to the public key of the peer's X.509 end-entity certificate to the public key of the peer's X.509 end-entity certificate
[RFC5280]. [RFC5280]. Figure 1 shows the intended deployment architecture.
Client Front-End Back-End
| |<--DC distribution->|
|----ClientHello--->| |
|<---ServerHello----| |
|<---Certificate----| |
|<---CertVerify-----| |
| ... | |
Legend:
Client: (D)TLS client
Front-End: (D)TLS server (could be a TLS-termination service like a CDN)
Back-End: Service with access to a private key
Figure 1: Delegated Credentials Deployment Architecture
A (D)TLS handshake that uses delegated credentials differs from a A (D)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 and the delegated
delegated credential. credential.
* The initiator uses information from the peer's certificate to * The initiator uses information from the peer's certificate to
verify the delegated credential and that the peer is asserting an verify the delegated credential and that the peer is asserting an
expected identity, determining an authentication result for the expected identity, determining an authentication result for the
peer. peer.
* Peers accepting the delegated credential use it as the certificate * Peers accepting the delegated credential use it as the certificate
key for the (D)TLS handshake. key for the (D)TLS handshake.
As detailed in Section 4, the delegated credential is As detailed in Section 4, the delegated credential is
skipping to change at line 294 skipping to change at line 200
validity period. In the absence of an application profile standard validity period. In the absence of an application profile standard
specifying otherwise, the maximum validity period is set to 7 days. specifying otherwise, the maximum validity period is set to 7 days.
Peers MUST NOT issue credentials with a validity period longer than Peers MUST NOT issue credentials with a validity period longer than
the maximum validity period or that extends beyond the validity the maximum validity period or that extends beyond the validity
period of the delegation certificate. This mechanism is described in period of the delegation certificate. This mechanism is described in
detail in Section 4.1. 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 reduce the risk of cross- ([RFC5280], Section 4.2.1.3). In order to reduce the risk of cross-
protocol attacks on certificates that are not intended to be used protocol attacks on certificates that are not intended to be used
with DC-capable TLS stacks, we define a new DelegationUsage extension with DC-capable TLS stacks, we define a new DelegationUsage extension
to X.509 that permits use of delegated credentials. (See to X.509 that permits use of delegated credentials. (See
Section 4.2.) Section 4.2.)
3.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:
skipping to change at line 328 skipping to change at line 234
* 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 end- to establish a binding between the proxy certificate and the end-
entity certificate. Since the certificate path building process entity 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 for use in the (D)TLS handshake ([RFC8446] section algorithm for use in the (D)TLS handshake ([RFC8446],
4.2.3). This prevents them from being used with other, perhaps Section 4.2.3). This prevents them from being used with other,
unintended, signature algorithms. The signature algorithm bound perhaps unintended, signature algorithms. The signature algorithm
to the delegated credential can be chosen independently of the set bound to the delegated credential can be chosen independently of
of signature algorithms supported by the end-entity certificate. the set of signature algorithms supported by the end-entity
certificate.
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] being one example). These mechanisms, however, mechanism, [KEYLESS] being one example). These mechanisms, however,
incur per-transaction latency, since the front-end server has to incur per-transaction latency, since the front-end server has to
interact with a back-end server that holds a private key. The interact with a back-end server that holds a private key. The
mechanism proposed in this document allows the delegation to be done mechanism proposed in this document allows the delegation to be done
off-line, with no per-transaction latency. The figure below compares offline, with no per-transaction latency. The figure below compares
the message flows for these two mechanisms with (D)TLS 1.3 [RFC8446] the message flows for these two mechanisms with (D)TLS 1.3 [RFC8446]
[I-D.ietf-tls-dtls13]. [RFC9147].
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-----| |
| ... | | | ... | |
skipping to change at line 370 skipping to change at line 277
| |<--DC distribution->| | |<--DC distribution->|
|----ClientHello--->| | |----ClientHello--->| |
|<---ServerHello----| | |<---ServerHello----| |
|<---Certificate----| | |<---Certificate----| |
|<---CertVerify-----| | |<---CertVerify-----| |
| ... | | | ... | |
Legend: Legend:
Client: (D)TLS client Client: (D)TLS client
Front-End: (D)TLS server (could be a TLS-termination service like a CDN) Front-End: (D)TLS server (could be a TLS-termination service like a CDN)
Back-End: Service with access to private key Back-End: Service with access to a private key
These two mechanisms can be complementary. A server could use These two mechanisms can be complementary. A server could use
delegated credentials for clients that support them, while using a delegated credentials for clients that support them, while using a
server-side mechanism to support legacy clients. Both mechanisms server-side mechanism to support legacy clients. Both mechanisms
require a trusted relationship between the Front-End and Back-End -- require a trusted relationship between the front-end and back-end --
the delegated credential can be used in place of a certificate the delegated credential can be used in place of a certificate
private key. private key.
Use of short-lived certificates with automated certificate issuance, The use of short-lived certificates with automated certificate
e.g., with Automated Certificate Management Environment (ACME) issuance, e.g., with the Automated Certificate Management Environment
[RFC8555], reduces the risk of key compromise, but has several (ACME) [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 (the CA). It also limits the types dependency on an external party (the CA). It also limits the types
of algorithms supported for (D)TLS authentication to those the CA is of algorithms supported for (D)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). (All digitalSignature KeyUsage ([RFC5280], Section 4.2.1.3). (All
certificates compatible with TLS 1.3 are required to contain the certificates compatible with TLS 1.3 are required to contain the
digitalSignature KeyUsage.) This document defines a new signed digitalSignature KeyUsage.) This document defines a new signed
object format that would encode only the semantics that are needed object format that encodes only the semantics that are needed for
for this application. The Credential has the following structure: this application. The Credential has the following structure:
struct { struct {
uint32 valid_time; uint32 valid_time;
SignatureScheme dc_cert_verify_algorithm; SignatureScheme dc_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 delegation valid_time: Time, in seconds relative to the delegation
certificate's notBefore value, after which the delegated certificate's notBefore value, after which the delegated
credential is no longer valid. By default, unless set to an credential is no longer valid. By default, unless set to an
alternative value by an application profile (see alternative value by an application profile (see Section 3),
Section Section 3), endpoints will reject delegated credentials endpoints will reject delegated credentials that expire more than
that expire more than 7 days from the current time (as described 7 days from the current time (as described in Section 4.1.3).
in Section 4.1.3).
dc_cert_verify_algorithm: The signature algorithm of the Credential dc_cert_verify_algorithm: The signature algorithm of the Credential
key pair, where the type SignatureScheme is as defined in key pair, where the type SignatureScheme is as defined in
[RFC8446]. This is expected to be the same as the sender's [RFC8446]. This is expected to be the same as the sender's
CertificateVerify.algorithm (as described in Section 4.1.3). Only CertificateVerify.algorithm (as described in Section 4.1.3).
signature algorithms allowed for use in CertificateVerify messages When using RSA, the public key MUST NOT use the rsaEncryption OID.
are allowed (as described in [RFC8446] Section 11). When using As a result, the following algorithms are not allowed for use with
RSA, the public key MUST NOT use the rsaEncryption OID. As a
result, the following algorithms are not allowed for use with
delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
rsa_pss_rsae_sha512. and 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 DelegatedCredential 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<1..2^16-1>;
} DelegatedCredential; } DelegatedCredential;
cred: The Credential structure as previously defined. cred: The Credential structure as previously defined.
algorithm: The signature algorithm used to create algorithm: The signature algorithm used to create
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.
skipping to change at line 496 skipping to change at line 400
} ExtensionType; } ExtensionType;
4.1.1. Server Authentication 4.1.1. Server Authentication
A client that is willing to use delegated credentials in a connection A client that is willing to use delegated credentials in a connection
SHALL send a "delegated_credential" extension in its ClientHello. SHALL send a "delegated_credential" extension in its ClientHello.
The body of the extension consists of a SignatureSchemeList (defined The body of the extension consists of a SignatureSchemeList (defined
in [RFC8446]): in [RFC8446]):
struct { struct {
SignatureScheme supported_signature_algorithm<2..2^16-2>; SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList; } SignatureSchemeList;
If the client receives a delegated credential without having If the client receives a delegated credential without having
indicated support in its ClientHello, then the client MUST abort the indicated support in its ClientHello, then the client MUST abort the
handshake with an "unexpected_message" alert. handshake 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. When a (D)TLS version negotiated is less a delegated credential. When a (D)TLS version negotiated is less
than 1.3, the server MUST ignore this extension. An example of when than 1.3, the server MUST ignore this extension. An example of when
a server could choose not to send a delegated credential is when the a server could choose not to send a delegated credential is when the
SignatureSchemes listed only contain signature schemes for which a SignatureSchemes listed only contain signature schemes for which a
corresponding delegated credential does not exist or are otherwise corresponding delegated credential does not exist or are otherwise
unsuitable for the connection. unsuitable for the connection.
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 MUST NOT
ignore delegated credentials sent as extensions to any other use delegated credentials sent as extensions to any other
certificate. certificate, and SHOULD ignore them, but MAY abort the handshake with
an "illegal_parameter" alert. If the server sends multiple delegated
credentials extensions in a single CertificateEntry, the client MUST
abort the handshake with an "illegal_parameter" alert.
The algorithm field MUST be of a type advertised by the client in the The algorithm field MUST be of a type advertised by the client in the
"signature_algorithms" extension of the ClientHello message and the "signature_algorithms" extension of the ClientHello message, and the
dc_cert_verify_algorithm field MUST be of a type advertised by the dc_cert_verify_algorithm field MUST be of a type advertised by the
client in the SignatureSchemeList and is considered not valid client in the SignatureSchemeList; otherwise, the credential is
otherwise. Clients that receive non-valid delegated credentials MUST considered not valid. Clients that receive non-valid delegated
terminate the connection with an "illegal_parameter" alert. credentials MUST terminate the connection with an "illegal_parameter"
alert.
4.1.2. Client Authentication 4.1.2. Client Authentication
A server that supports this specification SHALL send a A server that supports this specification SHALL send a
"delegated_credential" extension in the CertificateRequest message "delegated_credential" extension in the CertificateRequest message
when requesting client authentication. The body of the extension when requesting client authentication. The body of the extension
consists of a SignatureSchemeList. If the server receives a consists of a SignatureSchemeList. If the server receives a
delegated credential without having indicated support in its delegated credential without having indicated 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
a delegated credential. When a (D)TLS version negotiated is less a delegated credential. When a (D)TLS version negotiated is less
than 1.3, the client MUST ignore this extension. than 1.3, the client MUST ignore this extension.
The client MUST send the DC as an extension in the CertificateEntry The client MUST send the delegated credential as an extension in the
of its end-entity certificate; the server SHOULD ignore delegated CertificateEntry of its end-entity certificate; the server MUST NOT
credentials sent as extensions to any other certificate. use delegated credentials sent as extensions to any other
certificate, and SHOULD ignore them, but MAY abort the handshake with
an "illegal_parameter" alert. If the client sends multiple delegated
credentials extensions in a single CertificateEntry, the server MUST
abort the handshake with an "illegal_parameter" alert.
The algorithm field MUST be of a type advertised by the server in the The algorithm field MUST be of a type advertised by the server in the
"signature_algorithms" extension of the CertificateRequest message "signature_algorithms" extension of the CertificateRequest message,
and the dc_cert_verify_algorithm field MUST be of a type advertised and the dc_cert_verify_algorithm field MUST be of a type advertised
by the server in the SignatureSchemeList and is considered not valid by the server in the SignatureSchemeList; otherwise, the credential
otherwise. Servers that receive non-valid delegated credentials MUST is considered not valid. Servers that receive non-valid delegated
terminate the connection with an "illegal_parameter" alert. credentials MUST terminate the connection with an "illegal_parameter"
alert.
4.1.3. Validating a Delegated Credential 4.1.3. Validating a Delegated Credential
On receiving a delegated credential and certificate chain, the peer On receiving a delegated credential and 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 same way that it certificate to the peer's expected identity in the same way that it
is done when delegated credentials are not in use. It then performs is done when delegated credentials are not in use. It then performs
the following checks with expiry time set to the delegation the following checks with expiry time set to the delegation
certificate's notBefore value plus certificate's notBefore value plus
DelegatedCredential.cred.valid_time: DelegatedCredential.cred.valid_time:
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. This is done by asserting that the current time the credential. This is done by asserting that the current time
does not exceed the expiry time. (The start time of the does not exceed the expiry time. (The start time of the
credential is implicitly validated as part of certificate credential is implicitly validated as part of certificate
validation.) validation.)
2. Verify that the delegated credential's remaining validity period 2. Verify that the delegated credential's remaining validity period
is no more than the maximum validity period. This is done by is no more than the maximum validity period. This is done by
asserting that the expiry time does not exceed the current time asserting that the expiry time does not exceed the current time
plus the maximum validity period (7 days by default). plus the maximum validity period (7 days by default) and that the
expiry time is less than the certificate's expiry_time.
3. Verify that dc_cert_verify_algorithm matches the scheme indicated 3. Verify that dc_cert_verify_algorithm matches the scheme indicated
in the peer's CertificateVerify message and that the algorithm is in the peer's CertificateVerify message and that the algorithm is
allowed for use with delegated credentials. allowed for use with delegated credentials.
4. Verify that the end-entity certificate satisfies the conditions 4. Verify that the end-entity certificate satisfies the conditions
in Section 4.2. described in Section 4.2.
5. Use the public key in the peer's end-entity certificate to verify 5. 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 not valid. Clients and servers that receive non-valid deemed not valid. Clients and servers that receive non-valid
delegated credentials MUST terminate the connection with an delegated credentials MUST terminate the connection with an
"illegal_parameter" alert. "illegal_parameter" alert.
skipping to change at line 624 skipping to change at line 538
* 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 (D)TLS and PKI software stacks (EKU) to be compatible with deployed (D)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
The operational consideration documented in this section should be The operational considerations documented in this section should be
taken into consideration when using Delegated Certificates. taken into consideration when using delegated credentials.
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 of or behind the server's clock, then clients will
reject delegated credentials that are valid from the server's reject delegated credentials that are valid from the server's
perspective. Clock skew also affects the validity of the original perspective. Clock skew also affects the validity of the original
certificates. The lifetime of the delegated credential should be set certificates. The lifetime of the delegated credential should be set
taking clock skew into account. Clock skew may affect a delegated taking clock skew into account. Clock skew may affect a delegated
credential at the beginning and end of its validity periods, which credential at the beginning and end of its validity periods, which
should also be taken into account. should also be taken into account.
6. IANA Considerations 6. IANA Considerations
This document registers the "delegated_credential" extension in the This document registers the "delegated_credential" extension in the
"TLS ExtensionType Values" registry. The "delegated_credential" "TLS ExtensionType Values" registry. The "delegated_credential"
extension has been assigned a code point of 34. The IANA registry extension has been assigned the ExtensionType value 34. The IANA
lists this extension as "Recommended" (i.e., "Y") and indicates that registry lists this extension as "Recommended" (i.e., "Y") and
it may appear in the ClientHello (CH), CertificateRequest (CR), or indicates that it may appear in the ClientHello (CH),
Certificate (CT) messages in (D)TLS 1.3 [RFC8446] CertificateRequest (CR), or Certificate (CT) messages in (D)TLS 1.3
[I-D.ietf-tls-dtls13]. Additionally, the "DTLS-Only" column is [RFC8446] [RFC9147]. Additionally, the "DTLS-Only" column is
assigned the value "N". assigned the value "N".
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 has registered value 95 certificate extension in Appendix A. IANA has registered value 95
for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX
Module Identifier" (1.3.5.1.5.5.7.0) registry. An OID for the Module Identifier" (1.3.6.1.5.5.7.0) registry. An OID for the
DelegationUsage certificate extension is not needed as it is already DelegationUsage certificate extension is not needed, as it is already
assigned to the extension from Cloudflare's IANA Private Enterprise assigned to the extension from Cloudflare's IANA Private Enterprise
Number (PEN) arc. Number (PEN) arc.
7. Security Considerations 7. Security Considerations
The security consideration documented in this section should be taken The security considerations documented in this section should be
into consideration when using Delegated Certificates. taken into consideration when using delegated credentials.
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
(D)TLS connection by limiting its validity period. An attacker who (D)TLS connection by limiting its validity period. An attacker who
compromises the private key of a delegated credential cannot create compromises the private key of a delegated credential cannot create
new delegated credentials, but they can impersonate the compromised new delegated credentials, but they can impersonate the compromised
party in new TLS connections until the delegated credential expires. party in new TLS connections until the delegated credential expires.
Thus, delegated credentials should not be used to send a delegation Thus, delegated credentials should not be used to send a delegation
to an untrusted party, but are meant to be used between parties that to an untrusted party. Rather, they are meant to be used between
have some trust relationship with each other. The secrecy of the parties that have some trust relationship with each other. The
delegated credential's private key is thus important, and access secrecy of the delegated credential's private key is thus important,
control mechanisms SHOULD be used to protect it, including file and access control mechanisms SHOULD be used to protect it, including
system controls, physical security, or hardware security modules. file system controls, physical security, or hardware security
modules.
7.2. Re-use of Delegated Credentials in Multiple Contexts 7.2. Re-use of Delegated Credentials in Multiple Contexts
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 revokes the credential. Revocation of the long term credential revokes the credential. Revocation of the long-term
private key that signs the delegated credential (from the end-entity private key that signs the delegated credential (from the end-entity
certificate) also implicitly 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 peer decides to cache the certificate chain and re-validate it If a peer decides to cache the certificate chain and re-validate it
when resuming a connection, they SHOULD also cache the associated when resuming a connection, they SHOULD also cache the associated
delegated credential and re-validate it. Failing to do so may result delegated credential and re-validate it. Failing to do so may result
in resuming connections for which the DC has expired. in resuming connections for which the delegated credential has
expired.
7.5. Privacy Considerations 7.5. Privacy Considerations
Delegated credentials can be valid for 7 days (by default) and it is Delegated credentials can be valid for 7 days (by default), and it is
much easier for a service to create delegated credentials than a much easier for a service to create delegated credentials than a
certificate signed by a CA. A service could determine the client certificate signed by a CA. A service could determine the client
time and clock skew by creating several delegated credentials with time and clock skew by creating several delegated credentials with
different expiry timestamps and observing whether the client would different expiry timestamps and observing which credentials the
accept it. Client time could be unique and thus privacy-sensitive client accepts. Since client time can be unique to a particular
clients, such as browsers in incognito mode, who do not trust the client, privacy-sensitive clients who do not trust the service, such
service might not want to advertise support for delegated credentials as browsers in incognito mode, might not want to advertise support
or limit the number of probes that a server can perform. for delegated credentials, or might limit the number of probes that a
server can perform.
7.6. The Impact of Signature Forgery Attacks 7.6. The Impact of Signature Forgery Attacks
Delegated credentials are only used in (D)TLS 1.3 connections. Delegated credentials are only used in (D)TLS 1.3 connections.
However, the certificate that signs a delegated credential may be However, the certificate that signs a delegated credential may be
used in other contexts such as (D)TLS 1.2. Using a certificate in used in other contexts such as (D)TLS 1.2. Using a certificate in
multiple contexts opens up a potential cross-protocol attack against multiple contexts opens up a potential cross-protocol attack against
delegated credentials in (D)TLS 1.3. delegated credentials in (D)TLS 1.3.
When (D)TLS 1.2 servers support RSA key exchange, they may be When (D)TLS 1.2 servers support RSA key exchange, they may be
vulnerable to attacks that allow forging an RSA signature over an vulnerable to attacks that allow forging an RSA signature over an
arbitrary message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) arbitrary message [BLEI]. The TLS 1.2 specification describes a
describes a mitigation strategy requiring careful implementation of strategy for preventing these attacks that requires careful
timing resistant countermeasures for preventing these attacks. implementation of timing-resistant countermeasures. (See
Experience shows that in practice, server implementations may fail to Section 7.4.7.1 of [RFC5246].)
fully stop these attacks due to the complexity of this mitigation
Experience shows that, in practice, server implementations may fail
to fully stop these attacks due to the complexity of this mitigation
[ROBOT]. For (D)TLS 1.2 servers that support RSA key exchange using [ROBOT]. For (D)TLS 1.2 servers that support RSA key exchange using
a DC-enabled end-entity certificate, a hypothetical signature forgery a DC-enabled end-entity certificate, a hypothetical signature forgery
attack would allow forging a signature over a delegated credential. attack would allow forging a signature over a delegated credential.
The forged delegated credential could then be used by the attacker as The forged delegated credential could then be used by the attacker as
the equivalent of a on-path-attacker, valid for a maximum of 7 days the equivalent of an on-path attacker, valid for a maximum of 7 days
(if the default valid_time is used). (if the default valid_time is used).
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
serving non-DC (D)TLS traffic. Furthermore, server operators may use non-DC (D)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.
Note that if a signature can be forged over an arbitrary credential, Note that if a signature can be forged over an arbitrary credential,
the attacker can choose any value for the valid_time field. Repeated the attacker can choose any value for the valid_time field. Repeated
signature forgeries therefore allow the attacker to create multiple signature forgeries therefore allow the attacker to create multiple
delegated credentials that can cover the entire validity period of delegated credentials that can cover the entire validity period of
the certificate. Temporary exposure of the key or a signing oracle the certificate. Temporary exposure of the key or a signing oracle
may allow the attacker to impersonate a server for the lifetime of may allow the attacker to impersonate a server for the lifetime of
the certificate. the certificate.
8. Acknowledgements 8. References
Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh
Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson
Ladd, Robert Merget, Juraj Somorovsky, Nimrod Aviram for their
discussions, ideas, and bugs they have found.
9. References
9.1. Normative References
[I-D.ietf-tls-dtls13] 8.1. Normative References
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
dtls13-43>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <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/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[X.680] 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:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X.690] 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:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.690>.
9.2. Informative References 8.2. Informative References
[BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against [BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1", Protocols Based on RSA Encryption Standard PKCS #1",
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462,
pages: 1-12 , 1998. pages: 1-12, 1998,
<https://link.springer.com/chapter/10.1007/BFb0055716>.
[KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake [KEYLESS] Stebila, D. and N. Sullivan, "An Analysis of TLS Handshake
Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. Proxying", IEEE Trustcom/BigDataSE/ISPA 2015, 2015,
<https://ieeexplore.ieee.org/document/7345293>.
[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/rfc/rfc3820>. <https://www.rfc-editor.org/info/rfc3820>.
[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/rfc/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/rfc/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>. <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/rfc/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,
<https://www.usenix.org/conference/usenixsecurity18/
presentation/bock>.
[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,
<https://dl.acm.org/doi/10.1145/2810103.2813657>.
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 DelegatedCredentialExtn
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
skipping to change at line 887 skipping to change at line 803
IDENTIFIED BY id-pe-delegationUsage } IDENTIFIED BY id-pe-delegationUsage }
id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 }
DelegationUsage ::= NULL DelegationUsage ::= NULL
END END
Appendix B. Example Certificate Appendix B. Example Certificate
The following is an example of a delegation certificate which The following is an example of a delegation certificate that
satisfies the requirements described in Section 4.2 (i.e., uses the satisfies the requirements described in Section 4.2 (i.e., uses the
DelegationUsage extension and has the digitalSignature KeyUsage). DelegationUsage extension and has the digitalSignature KeyUsage).
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz
MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw
FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu
MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
skipping to change at line 923 skipping to change at line 839
X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6 X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6
bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw
0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA 0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA
AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X
/AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD /AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD
aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe
muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt
y5S4RfWHIIPjbw== y5S4RfWHIIPjbw==
-----END CERTIFICATE----- -----END CERTIFICATE-----
Acknowledgements
Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh
Ramachandran, Benjamin Kaduk, 奥 一穂 (Kazuho Oku), Daniel Kahn Gillmor,
Watson Ladd, Robert Merget, Juraj Somorovsky, and Nimrod Aviram for
their discussions, ideas, and bugs they have found.
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
Cisco Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
Subodh Iyengar Subodh Iyengar
Facebook Facebook
Email: subodh@fb.com Email: subodh@fb.com
Nick Sullivan Nick Sullivan
Cloudflare Cloudflare
Email: nick@cloudflare.com Email: nick@cloudflare.com
Eric Rescorla Eric Rescorla
Mozilla Windy Hill Systems, LLC
Email: ekr@rtfm.com Email: ekr@rtfm.com
 End of changes. 77 change blocks. 
260 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.48.