draft-ietf-tls-subcerts-06.txt   draft-ietf-tls-subcerts-07.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: 8 August 2020 Facebook Expires: 10 September 2020 Facebook
N. Sullivan N. Sullivan
Cloudflare Cloudflare
E. Rescorla E. Rescorla
Mozilla Mozilla
5 February 2020 9 March 2020
Delegated Credentials for TLS Delegated Credentials for TLS
draft-ietf-tls-subcerts-06 draft-ietf-tls-subcerts-07
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 8 August 2020. This Internet-Draft will expire on 10 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 10 skipping to change at page 3, line 10
operations, for example: operations, for example:
* Whenever the server operator wants to deploy a new certificate, it * Whenever the server operator wants to deploy a new certificate, it
has to interact with the CA. has to interact with the CA.
* 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 Networks (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 where they do not realize a compromise has occurred.
risk inherent in cross-organizational transactions makes it However, the risk inherent in cross-organizational transactions makes
operationally infeasible to rely on an external CA for such short- it operationally infeasible to rely on an external CA for such short-
lived credentials. In Online Certificate Status Protocol (OCSP) lived credentials. For instance, in the case of Online Certificate
stapling (i.e., using the Certificate Status extension type ocsp Status Protocol (OCSP) stapling (i.e., using the Certificate Status
[RFC8446], if an operator chooses to talk frequently to the CA to extension type ocsp [RFC8446]), a CA may fail to deliver OCSP stapled
obtain stapled responses, then failure to fetch an OCSP stapled response. While this will result in degraded performance, the
response results only in degraded performance. On the other hand, ramifications of failing to deliver short-lived certificates are even
failure to fetch a potentially large number of short lived worse: the service that depends on those certificates would go down
certificates would result in the service not being available, which entirely. Thus, ensuring independence from CAs for short-lived
creates greater operational risk. certificates is critical to the uptime of a service.
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
skipping to change at page 9, line 35 skipping to change at page 9, line 35
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 expected_cert_verify_algorithm field MUST be of a type advertised
type advertised by the client in the SignatureSchemeList and are by the client in the SignatureSchemeList and is considered invalid
considered invalid otherwise. Clients that receive invalid delegated otherwise. Clients that receive invalid delegated credentials MUST
credentials MUST terminate the connection with an "illegal_parameter" terminate the connection with an "illegal_parameter" alert.
alert.
4.1.2. Client authentication 4.1.2. Client authentication
A server which supports this specification SHALL send an empty 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. If the server receives a when requesting client authentication. The body of the extension
consists of a SignatureSchemeList. 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
a delegated credential. The client MUST ignore the extension unless a delegated credential. The client MUST ignore the extension unless
TLS 1.3 or a later version is negotiated. TLS 1.3 or a later version is negotiated.
The client MUST send the delegated credential as an extension in the The client MUST send the delegated credential as an extension in the
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 field MUST be of a type advertised by the server in the
type advertised by the server in the "signature_algorithms" extension "signature_algorithms" extension of the CertificateRequest message
and are considered invalid otherwise. Servers that receive invalid and the expected_cert_verify_algorithm field MUST be of a type
delegated credentials MUST terminate the connection with an advertised by the server in the SignatureSchemeList and considered
"illegal_parameter" alert. invalid otherwise. Servers that receive invalid delegated
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 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
skipping to change at page 11, line 18 skipping to change at page 11, line 18
certificate when the certificate permits the usage of delegated certificate when the certificate permits the usage of delegated
credentials. What follows is the ASN.1 [X.680] for the credentials. What follows is the ASN.1 [X.680] for the
DelegationUsage certificate extension. DelegationUsage certificate extension.
ext-delegationUsage EXTENSION ::= { ext-delegationUsage EXTENSION ::= {
SYNTAX DelegationUsage IDENTIFIED BY id-ce-delegationUsage SYNTAX DelegationUsage IDENTIFIED BY id-ce-delegationUsage
} }
DelegationUsage ::= NULL DelegationUsage ::= NULL
id-ce-delegationUsage OBJECT IDENTIFIER ::= { id-ce-delegationUsage OBJECT IDENTIFIER ::=
1 3 6 1 4 1 44363 44 { iso(1) identified-organization(3) dod(6) internet(1)
} private(4) enterprise(1) id-cloudflare(44363) 44 }
The extension MUST be marked non-critical. (See Section 4.2 of The extension MUST be marked non-critical. (See Section 4.2 of
[RFC5280].) The client MUST NOT accept a delegated credential unless [RFC5280].) The client MUST NOT accept a delegated credential unless
the server's end-entity certificate satisfies the following criteria: the server's end-entity certificate satisfies the following criteria:
* It has the DelegationUsage extension. * It has the DelegationUsage extension.
* It has the digitalSignature KeyUsage (see the KeyUsage extension * It has the digitalSignature KeyUsage (see the KeyUsage extension
defined in [RFC5280]). defined in [RFC5280]).
skipping to change at page 14, line 26 skipping to change at page 15, line 5
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 { iso(1) identified-organization(3) dod(6) DelegatedCredentialExtn
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod- { iso(1) identified-organization(3) dod(6) internet(1)
delegated-credential-extn(TBD) } security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-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
identified-organization(3) dod(6) internet(1) security(5) FROM PKIX-CommonTypes-2009 -- From RFC 5912
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
- OIDS -- OID
id-cloudflare OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 44363 } id-cloudflare OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) private(4)
enterprise(1) 44363 }
- EXTENSION -- EXTENSION
ext-delegationUsage EXTENSION ::= { SYNTAX DelegationUsage IDENTIFIED ext-delegationUsage EXTENSION ::=
BY id-ce-delegationUsage } { SYNTAX DelegationUsage
IDENTIFIED BY id-ce-delegationUsage }
id-ce-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } id-ce-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 }
DelegationUsage ::= NULL DelegationUsage ::= NULL
END END
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
Cisco Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
 End of changes. 20 change blocks. 
44 lines changed or deleted 52 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/