idnits 2.17.1 draft-ietf-tls-subcerts-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 924 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 May 2022) is 710 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Iyengar 5 Expires: 18 November 2022 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 Mozilla 10 17 May 2022 12 Delegated Credentials for (D)TLS 13 draft-ietf-tls-subcerts-14 15 Abstract 17 The organizational separation between operators of TLS and DTLS 18 endpoints and the certification authority can create limitations. 19 For example, the lifetime of certificates, how they may be used, and 20 the algorithms they support are ultimately determined by the 21 certification authority. This document describes a mechanism to to 22 overcome some of these limitations by enabling operators to delegate 23 their own credentials for use in TLS and DTLS without breaking 24 compatibility with peers that do not support this specification. 26 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/tlswg/tls-subcerts (https://github.com/tlswg/tls- 32 subcerts). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 18 November 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction 68 2. Conventions and Terminology 69 2.1. Change Log 70 3. Solution Overview 71 3.1. Rationale 72 3.2. Related Work 73 4. Delegated Credentials 74 4.1. Client and Server Behavior 75 4.1.1. Server Authentication 76 4.1.2. Client Authentication 77 4.1.3. Validating a Delegated Credential 78 4.2. Certificate Requirements 79 5. Operational Considerations 80 5.1. Client Clock Skew 81 6. IANA Considerations 82 7. Security Considerations 83 7.1. Security of Delegated Credential's Private Key 84 7.2. Re-use of Delegated Credentials in Multiple Contexts 85 7.3. Revocation of Delegated Credentials 86 7.4. Interactions with Session Resumption 87 7.5. Privacy Considerations 88 7.6. The Impact of Signature Forgery Attacks 89 8. Acknowledgements 90 9. References 91 9.1. Normative References 92 9.2. Informative References 93 Appendix A. ASN.1 Module 94 Appendix B. Example Certificate 95 Authors' Addresses 97 1. Introduction 99 Server operators often deploy (D)TLS termination services in 100 locations such as remote data centers or Content Delivery Networks 101 (CDNs) where it may be difficult to detect compromises of private key 102 material corresponding to TLS certificates. Short-lived certificates 103 may be used to limit the exposure of keys in these cases. 105 However, short-lived certificates need to be renewed more frequently 106 than long-lived certificates. If an external Certification Authority 107 (CA) is unable to issue a certificate in time to replace a deployed 108 certificate, the server would no longer be able to present a valid 109 certificate to clients. With short-lived certificates, there is a 110 smaller window of time to renew a certificates and therefore a higher 111 risk that an outage at a CA will negatively affect the uptime of the 112 TLS-fronted service. 114 Typically, a (D)TLS server uses a certificate provided by some entity 115 other than the operator of the server (a CA) [RFC8446] [RFC5280]. 116 This organizational separation makes the (D)TLS server operator 117 dependent on the CA for some aspects of its operations, for example: 119 * Whenever the server operator wants to deploy a new certificate, it 120 has to interact with the CA. 122 * The CA might only issue credentials containing certain types of 123 public key, which can limit the set of (D)TLS signature schemes 124 usable by the server operator. 126 To reduce the dependency on external CAs, this document specifies a 127 limited delegation mechanism that allows a (D)TLS peer to issue its 128 own credentials within the scope of a certificate issued by an 129 external CA. These credentials only enable the recipient of the 130 delegation to speak for names that the CA has authorized. 131 Furthermore, this mechanism allows the server to use modern signature 132 algorithms such as Ed25519 [RFC8032] even if their CA does not 133 support them. 135 This document refers to the certificate issued by the CA as a 136 "certificate", or "delegation certificate", and the one issued by the 137 operator as a "delegated credential" or "DC". 139 2. Conventions and Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2.1. Change Log 149 RFC EDITOR PLEASE DELETE THIS SECTION. 151 (*) indicates changes to the wire protocol. 153 draft-11 155 * Editorial changes based on AD comments 157 * Add support for DTLS 159 * Address address ambiguity in cert expiry 161 draft-10 163 * Address superficial comments 165 * Add example certificate 167 draft-09 169 * Address case nits 171 * Fix section bullets in 4.1.3. 173 * Add operational considerations section for clock skew 175 * Add text around using an oracle to forge DCs in the future and 176 past 178 * Add text about certificate extension vs EKU 180 draft-08 182 * Include details about the impact of signature forgery attacks 184 * Copy edits 186 * Fix section about DC reuse 188 * Incorporate feedback from Jonathan Hammell and Kevin Jacobs on the 189 list 191 draft-07 193 * Minor text improvements 195 draft-06 197 * Modified IANA section, fixed nits 199 draft-05 201 * Removed support for PKCS 1.5 RSA signature algorithms. 203 * Additional security considerations. 205 draft-04 207 * Add support for client certificates. 209 draft-03 211 * Remove protocol version from the Credential structure. (*) 213 draft-02 215 * Change public key type. (*) 217 * Change DelegationUsage extension to be NULL and define its object 218 identifier. 220 * Drop support for TLS 1.2. 222 * Add the protocol version and credential signature algorithm to the 223 Credential structure. (*) 225 * Specify undefined behavior in a few cases: when the client 226 receives a DC without indicated support; when the client indicates 227 the extension in an invalid protocol version; and when DCs are 228 sent as extensions to certificates other than the end-entity 229 certificate. 231 3. Solution Overview 233 A delegated credential (DC) is a digitally signed data structure with 234 two semantic fields: a validity interval and a public key (along with 235 its associated signature algorithm). The signature on the delegated 236 credential indicates a delegation from the certificate that is issued 237 to the peer. The private key used to sign a credential corresponds 238 to the public key of the peer's X.509 end-entity certificate 239 [RFC5280]. 241 A (D)TLS handshake that uses delegated credentials differs from a 242 standard handshake in a few important ways: 244 * The initiating peer provides an extension in its ClientHello or 245 CertificateRequest that indicates support for this mechanism. 247 * The peer sending the Certificate message provides both the 248 certificate chain terminating in its certificate as well as the 249 delegated credential. 251 * The initiator uses information from the peer's certificate to 252 verify the delegated credential and that the peer is asserting an 253 expected identity, determining an authentication result for the 254 peer. 256 * Peers accepting the delegated credential use it as the certificate 257 key for the (D)TLS handshake. 259 As detailed in Section 4, the delegated credential is 260 cryptographically bound to the end-entity certificate with which the 261 credential may be used. This document specifies the use of delegated 262 credentials in (D)TLS 1.3 or later; their use in prior versions of 263 the protocol is not allowed. 265 Delegated credentials allow a peer to terminate (D)TLS connections on 266 behalf of the certificate owner. If a credential is stolen, there is 267 no mechanism for revoking it without revoking the certificate itself. 268 To limit exposure in case of the compromise of a delegated 269 credential's private key, delegated credentials have a maximum 270 validity period. In the absence of an application profile standard 271 specifying otherwise, the maximum validity period is set to 7 days. 272 Peers MUST NOT issue credentials with a validity period longer than 273 the maximum validity period or that extends beyond the validity 274 period of the delegation certificate. This mechanism is described in 275 detail in Section 4.1. 277 It was noted in [XPROT] that certificates in use by servers that 278 support outdated protocols such as SSLv2 can be used to forge 279 signatures for certificates that contain the keyEncipherment KeyUsage 280 ([RFC5280] section 4.2.1.3). In order to reduce the risk of cross- 281 protocol attacks on certificates that are not intended to be used 282 with DC-capable TLS stacks, we define a new DelegationUsage extension 283 to X.509 that permits use of delegated credentials. (See 284 Section 4.2.) 286 3.1. Rationale 288 Delegated credentials present a better alternative than other 289 delegation mechanisms like proxy certificates [RFC3820] for several 290 reasons: 292 * There is no change needed to certificate validation at the PKI 293 layer. 295 * X.509 semantics are very rich. This can cause unintended 296 consequences if a service owner creates a proxy certificate where 297 the properties differ from the leaf certificate. Proxy 298 certificates can be useful in controlled environments, but remain 299 a risk in scenarios where the additional flexibility they provide 300 is not necessary. For this reason, delegated credentials have 301 very restricted semantics that should not conflict with X.509 302 semantics. 304 * Proxy certificates rely on the certificate path building process 305 to establish a binding between the proxy certificate and the end- 306 entity certificate. Since the certificate path building process 307 is not cryptographically protected, it is possible that a proxy 308 certificate could be bound to another certificate with the same 309 public key, with different X.509 parameters. Delegated 310 credentials, which rely on a cryptographic binding between the 311 entire certificate and the delegated credential, cannot. 313 * Each delegated credential is bound to a specific signature 314 algorithm for use in the (D)TLS handshake ([RFC8446] section 315 4.2.3). This prevents them from being used with other, perhaps 316 unintended, signature algorithms. The signature algorithm bound 317 to the delegated credential can be chosen independently of the set 318 of signature algorithms supported by the end-entity certificate. 320 3.2. Related Work 322 Many of the use cases for delegated credentials can also be addressed 323 using purely server-side mechanisms that do not require changes to 324 client behavior (e.g., a PKCS#11 interface or a remote signing 325 mechanism, [KEYLESS] being one example). These mechanisms, however, 326 incur per-transaction latency, since the front-end server has to 327 interact with a back-end server that holds a private key. The 328 mechanism proposed in this document allows the delegation to be done 329 off-line, with no per-transaction latency. The figure below compares 330 the message flows for these two mechanisms with (D)TLS 1.3 [RFC8446] 331 [I-D.ietf-tls-dtls13]. 333 Remote key signing: 335 Client Front-End Back-End 336 |----ClientHello--->| | 337 |<---ServerHello----| | 338 |<---Certificate----| | 339 | |<---remote sign---->| 340 |<---CertVerify-----| | 341 | ... | | 343 Delegated Credential: 345 Client Front-End Back-End 346 | |<--DC distribution->| 347 |----ClientHello--->| | 348 |<---ServerHello----| | 349 |<---Certificate----| | 350 |<---CertVerify-----| | 351 | ... | | 353 These two mechanisms can be complementary. A server could use 354 delegated credentials for clients that support them, while using a 355 server-side mechanism to support legacy clients. Both mechanisms 356 require a trusted relationship between the Front-End and Back-End -- 357 the delegated credential can be used in place of a certificate 358 private key. 360 Use of short-lived certificates with automated certificate issuance, 361 e.g., with Automated Certificate Management Environment (ACME) 362 [RFC8555], reduces the risk of key compromise, but has several 363 limitations. Specifically, it introduces an operationally-critical 364 dependency on an external party (the CA). It also limits the types 365 of algorithms supported for (D)TLS authentication to those the CA is 366 willing to issue a certificate for. Nonetheless, existing automated 367 issuance APIs like ACME may be useful for provisioning delegated 368 credentials. 370 4. Delegated Credentials 372 While X.509 forbids end-entity certificates from being used as 373 issuers for other certificates, it is valid to use them to issue 374 other signed objects as long as the certificate contains the 375 digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). (All 376 certificates compatible with TLS 1.3 are required to contain the 377 digitalSignature KeyUsage.) We define a new signed object format 378 that would encode only the semantics that are needed for this 379 application. The Credential has the following structure: 381 struct { 382 uint32 valid_time; 383 SignatureScheme dc_cert_verify_algorithm; 384 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 385 } Credential; 387 valid_time: Time, in seconds relative to the delegation 388 certificate's notBefore value, after which the delegated 389 credential is no longer valid. Endpoints will reject delegated 390 credentials that expire more than 7 days from the current time (as 391 described in Section 4.1) based on the default (see Section 3. 393 dc_cert_verify_algorithm: The signature algorithm of the Credential 394 key pair, where the type SignatureScheme is as defined in 395 [RFC8446]. This is expected to be the same as the sender's 396 CertificateVerify.algorithm (as described in Section 4.1.3). Only 397 signature algorithms allowed for use in CertificateVerify messages 398 are allowed. When using RSA, the public key MUST NOT use the 399 rsaEncryption OID. As a result, the following algorithms are not 400 allowed for use with delegated credentials: rsa_pss_rsae_sha256, 401 rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. 403 ASN1_subjectPublicKeyInfo: The Credential's public key, a DER- 404 encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. 406 The DelegatedCredential has the following structure: 408 struct { 409 Credential cred; 410 SignatureScheme algorithm; 411 opaque signature<0..2^16-1>; 412 } DelegatedCredential; 414 cred: The Credential structure as previously defined. 416 algorithm: The signature algorithm used to create 417 DelegatedCredential.signature. 419 signature: The delegation, a signature that binds the credential to 420 the end-entity certificate's public key as specified below. The 421 signature scheme is specified by DelegatedCredential.algorithm. 423 The signature of the DelegatedCredential is computed over the 424 concatenation of: 426 1. An octet stream that consists of octet 32 (0x20) repeated 64 427 times. 429 2. The non-null terminated context string "TLS, server delegated 430 credentials" for server authentication and "TLS, client delegated 431 credentials" for client authentication. 433 3. A single octet 0x00, which serves as the separator. 435 4. The DER-encoded X.509 end-entity certificate used to sign the 436 DelegatedCredential. 438 5. DelegatedCredential.cred. 440 6. DelegatedCredential.algorithm. 442 The signature is computed by using the private key of the peer's end- 443 entity certificate, with the algorithm indicated by 444 DelegatedCredential.algorithm. 446 The signature effectively binds the credential to the parameters of 447 the handshake in which it is used. In particular, it ensures that 448 credentials are only used with the certificate and signature 449 algorithm chosen by the delegator. 451 The code changes required in order to create and verify delegated 452 credentials, and the implementation complexity this entails, are 453 localized to the (D)TLS stack. This has the advantage of avoiding 454 changes to the often-delicate security-critical PKI code. 456 4.1. Client and Server Behavior 458 This document defines the following (D)TLS extension code point. 460 enum { 461 ... 462 delegated_credential(34), 463 (65535) 464 } ExtensionType; 466 4.1.1. Server Authentication 468 A client that is willing to use delegated credentials in a connection 469 SHALL send a "delegated_credential" extension in its ClientHello. 470 The body of the extension consists of a SignatureSchemeList (defined 471 in [RFC8446]): 473 struct { 474 SignatureScheme supported_signature_algorithm<2..2^16-2>; 475 } SignatureSchemeList; 477 If the client receives a delegated credential without having 478 indicated support in its ClientHello, then the client MUST abort the 479 handshake with an "unexpected_message" alert. 481 If the extension is present, the server MAY send a delegated 482 credential; if the extension is not present, the server MUST NOT send 483 a delegated credential. When a (D)TLS version negotiated is less 484 than 1.3, the server MUST ignore this extension. An example of when 485 a server could choose not to send a delegated credential is when the 486 SignatureSchemes listed only contain signature schemes for which a 487 corresponding delegated credential does not exist or are otherwise 488 unsuitable for the connection. 490 The server MUST send the delegated credential as an extension in the 491 CertificateEntry of its end-entity certificate; the client SHOULD 492 ignore delegated credentials sent as extensions to any other 493 certificate. 495 The algorithm field MUST be of a type advertised by the client in the 496 "signature_algorithms" extension of the ClientHello message and the 497 dc_cert_verify_algorithm field MUST be of a type advertised by the 498 client in the SignatureSchemeList and is considered invalid 499 otherwise. Clients that receive invalid delegated credentials MUST 500 terminate the connection with an "illegal_parameter" alert. 502 4.1.2. Client Authentication 504 A server that supports this specification SHALL send a 505 "delegated_credential" extension in the CertificateRequest message 506 when requesting client authentication. The body of the extension 507 consists of a SignatureSchemeList. If the server receives a 508 delegated credential without having indicated support in its 509 CertificateRequest, then the server MUST abort with an 510 "unexpected_message" alert. 512 If the extension is present, the client MAY send a delegated 513 credential; if the extension is not present, the client MUST NOT send 514 a delegated credential. When a (D)TLS version negotiated is less 515 than 1.3, the client MUST ignore this extension. 517 The client MUST send the DC as an extension in the CertificateEntry 518 of its end-entity certificate; the server SHOULD ignore delegated 519 credentials sent as extensions to any other certificate. 521 The algorithm field MUST be of a type advertised by the server in the 522 "signature_algorithms" extension of the CertificateRequest message 523 and the dc_cert_verify_algorithm field MUST be of a type advertised 524 by the server in the SignatureSchemeList and is considered invalid 525 otherwise. Servers that receive invalid delegated credentials MUST 526 terminate the connection with an "illegal_parameter" alert. 528 4.1.3. Validating a Delegated Credential 530 On receiving a delegated credential and certificate chain, the peer 531 validates the certificate chain and matches the end-entity 532 certificate to the peer's expected identity in the same way that it 533 is done when delegated credentials are not in use. It then performs 534 the following checks with expiry time set to the delegation 535 certificate's notBefore value plus 536 DelegatedCredential.cred.valid_time: 538 1. Verify that the current time is within the validity interval of 539 the credential. This is done by asserting that the current time 540 does not exceed the expiry time. (The start time of the 541 credential is implicitly validated as part of certificate 542 validation.) 544 2. Verify that the delegated credential's remaining validity period 545 is no more than the maximum validity period. This is done by 546 asserting that the expiry time does not exceed the current time 547 plus the maximum validity period (7 days by default). 549 3. Verify that dc_cert_verify_algorithm matches the scheme indicated 550 in the peer's CertificateVerify message and that the algorithm is 551 allowed for use with delegated credentials. 553 4. Verify that the end-entity certificate satisfies the conditions 554 in Section 4.2. 556 5. Use the public key in the peer's end-entity certificate to verify 557 the signature of the credential using the algorithm indicated by 558 DelegatedCredential.algorithm. 560 If one or more of these checks fail, then the delegated credential is 561 deemed invalid. Clients and servers that receive invalid delegated 562 credentials MUST terminate the connection with an "illegal_parameter" 563 alert. 565 If successful, the participant receiving the Certificate message uses 566 the public key in DelegatedCredential.cred to verify the signature in 567 the peer's CertificateVerify message. 569 4.2. Certificate Requirements 571 This documnt defines a new X.509 extension, DelegationUsage, to be 572 used in the certificate when the certificate permits the usage of 573 delegated credentials. What follows is the ASN.1 [X.680] for the 574 DelegationUsage certificate extension. 576 ext-delegationUsage EXTENSION ::= { 577 SYNTAX DelegationUsage IDENTIFIED BY id-pe-delegationUsage 578 } 580 DelegationUsage ::= NULL 582 id-pe-delegationUsage OBJECT IDENTIFIER ::= 583 { iso(1) identified-organization(3) dod(6) internet(1) 584 private(4) enterprise(1) id-cloudflare(44363) 44 } 586 The extension MUST be marked non-critical. (See Section 4.2 of 587 [RFC5280].) An endpoint MUST NOT accept a delegated credential 588 unless the peer's end-entity certificate satisfies the following 589 criteria: 591 * It has the DelegationUsage extension. 593 * It has the digitalSignature KeyUsage (see the KeyUsage extension 594 defined in [RFC5280]). 596 A new extension was chosen instead of adding a new Extended Key Usage 597 (EKU) to be compatible with deployed (D)TLS and PKI software stacks 598 without requiring CAs to issue new intermediate certificates. 600 5. Operational Considerations 602 The operational consideration documented in this section should be 603 taken into consideration when using Delegated Certificates. 605 5.1. Client Clock Skew 607 One of the risks of deploying a short-lived credential system based 608 on absolute time is client clock skew. If a client's clock is 609 sufficiently ahead or behind of the server's clock, then clients will 610 reject delegated credentials that are valid from the server's 611 perspective. Clock skew also affects the validity of the original 612 certificates. The lifetime of the delegated credential should be set 613 taking clock skew into account. Clock skew may affect a delegated 614 credential at the beginning and end of its validity periods, which 615 should also be taken into account. 617 6. IANA Considerations 619 This document registers the "delegated_credential" extension in the 620 "TLS ExtensionType Values" registry. The "delegated_credential" 621 extension has been assigned a code point of 34. The IANA registry 622 lists this extension as "Recommended" (i.e., "Y") and indicates that 623 it may appear in the ClientHello (CH), CertificateRequest (CR), or 624 Certificate (CT) messages in (D)TLS 1.3 [RFC8446] 625 [I-D.ietf-tls-dtls13]. Additionally, the "DTLS-Only" column is 626 assigned the value "N". 628 This document also defines an ASN.1 module for the DelegationUsage 629 certificate extension in Appendix A. IANA has registered value 95 630 for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX 631 Module Identifier" (1.3.5.1.5.5.7.0) registry. An OID for the 632 DelegationUsage certificate extension is not needed as it is already 633 assigned to the extension from Cloudflare's IANA Private Enterprise 634 Number (PEN) arc. 636 7. Security Considerations 638 The security consideration documented in this section should be taken 639 into consideration when using Delegated Certificates. 641 7.1. Security of Delegated Credential's Private Key 643 Delegated credentials limit the exposure of the private key used in a 644 (D)TLS connection by limiting its validity period. An attacker who 645 compromises the private key of a delegated credential can impersonate 646 the compromised party in new TLS connections until the delegated 647 credential expires. 649 However, they cannot create new delegated credentials. Thus, 650 delegated credentials should not be used to send a delegation to an 651 untrusted party, but are meant to be used between parties that have 652 some trust relationship with each other. The secrecy of the 653 delegated credential's private key is thus important and access 654 control mechanisms SHOULD be used to protect it, including file 655 system controls, physical security, or hardware security modules. 657 7.2. Re-use of Delegated Credentials in Multiple Contexts 659 It is not possible to use the same delegated credential for both 660 client and server authentication because issuing parties compute the 661 corresponding signature using a context string unique to the intended 662 role (client or server). 664 7.3. Revocation of Delegated Credentials 666 Delegated credentials do not provide any additional form of early 667 revocation. Since it is short lived, the expiry of the delegated 668 credential revokes the credential. Revocation of the long term 669 private key that signs the delegated credential (from the end-entity 670 certificate) also implicitly revokes the delegated credential. 672 7.4. Interactions with Session Resumption 674 If a peer decides to cache the certificate chain and re-validate it 675 when resuming a connection, they SHOULD also cache the associated 676 delegated credential and re-validate it. Failing to do so may result 677 in resuming connections for which the DC has expired. 679 7.5. Privacy Considerations 681 Delegated credentials can be valid for 7 days (by default) and it is 682 much easier for a service to create delegated credentials than a 683 certificate signed by a CA. A service could determine the client 684 time and clock skew by creating several delegated credentials with 685 different expiry timestamps and observing whether the client would 686 accept it. Client time could be unique and thus privacy sensitive 687 clients, such as browsers in incognito mode, who do not trust the 688 service might not want to advertise support for delegated credentials 689 or limit the number of probes that a server can perform. 691 7.6. The Impact of Signature Forgery Attacks 693 Delegated credentials are only used in (D)TLS 1.3 connections. 694 However, the certificate that signs a delegated credential may be 695 used in other contexts such as (D)TLS 1.2. Using a certificate in 696 multiple contexts opens up a potential cross-protocol attack against 697 delegated credentials in (D)TLS 1.3. 699 When (D)TLS 1.2 servers support RSA key exchange, they may be 700 vulnerable to attacks that allow forging an RSA signature over an 701 arbitrary message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) 702 describes a mitigation strategy requiring careful implementation of 703 timing resistant countermeasures for preventing these attacks. 704 Experience shows that in practice, server implementations may fail to 705 fully stop these attacks due to the complexity of this mitigation 706 [ROBOT]. For (D)TLS 1.2 servers that support RSA key exchange using 707 a DC-enabled end-entity certificate, a hypothetical signature forgery 708 attack would allow forging a signature over a delegated credential. 709 The forged delegated credential could then be used by the attacker as 710 the equivalent of a man-in-the-middle certificate, valid for a 711 maximum of 7 days (if the default valid_time is used). 713 Server operators should therefore minimize the risk of using DC- 714 enabled end-entity certificates where a signature forgery oracle may 715 be present. If possible, server operators may choose to use DC- 716 enabled certificates only for signing credentials, and not for 717 serving non-DC (D)TLS traffic. Furthermore, server operators may use 718 elliptic curve certificates for DC-enabled traffic, while using RSA 719 certificates without the DelegationUsage certificate extension for 720 non-DC traffic; this completely prevents such attacks. 722 Note that if a signature can be forged over an arbitrary credential, 723 the attacker can choose any value for the valid_time field. Repeated 724 signature forgeries therefore allow the attacker to create multiple 725 delegated credentials that can cover the entire validity period of 726 the certificate. Temporary exposure of the key or a signing oracle 727 may allow the attacker to impersonate a server for the lifetime of 728 the certificate. 730 8. Acknowledgements 732 Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh 733 Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson 734 Ladd, Robert Merget, Juraj Somorovsky, Nimrod Aviram for their 735 discussions, ideas, and bugs they have found. 737 9. References 739 9.1. Normative References 741 [I-D.ietf-tls-dtls13] 742 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 743 Datagram Transport Layer Security (DTLS) Protocol Version 744 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 745 dtls13-43, 30 April 2021, 746 . 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 755 Housley, R., and W. Polk, "Internet X.509 Public Key 756 Infrastructure Certificate and Certificate Revocation List 757 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 758 . 760 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 761 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 762 May 2017, . 764 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 765 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 766 . 768 [X.680] ITU-T, "Information technology - Abstract Syntax Notation 769 One (ASN.1): Specification of basic notation", ISO/ 770 IEC 8824-1:2015, November 2015. 772 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 773 Specification of Basic Encoding Rules (BER), Canonical 774 Encoding Rules (CER) and Distinguished Encoding Rules 775 (DER)", ISO/IEC 8825-1:2015, November 2015. 777 9.2. Informative References 779 [BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against 780 Protocols Based on RSA Encryption Standard PKCS #1", 781 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, 782 pages: 1-12 , 1998. 784 [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake 785 Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. 787 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 788 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 789 Proxy Certificate Profile", RFC 3820, 790 DOI 10.17487/RFC3820, June 2004, 791 . 793 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 794 (TLS) Protocol Version 1.2", RFC 5246, 795 DOI 10.17487/RFC5246, August 2008, 796 . 798 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 799 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 800 DOI 10.17487/RFC5912, June 2010, 801 . 803 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 804 Signature Algorithm (EdDSA)", RFC 8032, 805 DOI 10.17487/RFC8032, January 2017, 806 . 808 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 809 Kasten, "Automatic Certificate Management Environment 810 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 811 . 813 [ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of 814 Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX 815 Security Symposium , 2018. 817 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 818 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 819 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 820 Conference on Computer and Communications Security , 2015. 822 Appendix A. ASN.1 Module 824 The following ASN.1 module provides the complete definition of the 825 DelegationUsage certificate extension. The ASN.1 module makes 826 imports from [RFC5912]. 828 DelegatedCredentialExtn 829 { iso(1) identified-organization(3) dod(6) internet(1) 830 security(5) mechanisms(5) pkix(7) id-mod(0) 831 id-mod-delegated-credential-extn(95) } 833 DEFINITIONS IMPLICIT TAGS ::= 834 BEGIN 836 -- EXPORT ALL 838 IMPORTS 840 EXTENSION 841 FROM PKIX-CommonTypes-2009 -- From RFC 5912 842 { iso(1) identified-organization(3) dod(6) internet(1) 843 security(5) mechanisms(5) pkix(7) id-mod(0) 844 id-mod-pkixCommon-02(57) } ; 846 -- OID 848 id-cloudflare OBJECT IDENTIFIER ::= 849 { iso(1) identified-organization(3) dod(6) internet(1) private(4) 850 enterprise(1) 44363 } 852 -- EXTENSION 854 ext-delegationUsage EXTENSION ::= 855 { SYNTAX DelegationUsage 856 IDENTIFIED BY id-pe-delegationUsage } 858 id-pe-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } 860 DelegationUsage ::= NULL 862 END 864 Appendix B. Example Certificate 866 The following certificate has the Delegated Credentials OID. 868 -----BEGIN CERTIFICATE----- 869 MIIFRjCCBMugAwIBAgIQDGevB+lY0o/OecHFSJ6YnTAKBggqhkjOPQQDAzBMMQsw 870 CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp 871 Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xOTAzMjYwMDAwMDBaFw0yMTAz 872 MzAxMjAwMDBaMGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw 873 FAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMu 874 MRMwEQYDVQQDEwprYzJrZG0uY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE 875 d4azI83Bw0fcPgfoeiZpZZnwGuxjBjv++wzE0zAj8vNiUkKxOWSQiGNLn+xlWUpL 876 lw9djRN1rLmVmn2gb9GgdKOCA28wggNrMB8GA1UdIwQYMBaAFKOd5h/52jlPwG7o 877 kcuVpdox4gqfMB0GA1UdDgQWBBSfcb7fS3fUFAyB91fRcwoDPtgtJjAjBgNVHREE 878 HDAaggprYzJrZG0uY29tggwqLmtjMmtkbS5jb20wDgYDVR0PAQH/BAQDAgeAMB0G 879 A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBpBgNVHR8EYjBgMC6gLKAqhiho 880 dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMC6gLKAqhiho 881 dHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1lY2MtZzEuY3JsMEwGA1UdIARF 882 MEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj 883 ZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcw 884 AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8v 885 Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRFQ0NTZWN1cmVTZXJ2ZXJDQS5j 886 cnQwDAYDVR0TAQH/BAIwADAPBgkrBgEEAYLaSywEAgUAMIIBfgYKKwYBBAHWeQIE 887 AgSCAW4EggFqAWgAdgC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAA 888 AWm5hYJ5AAAEAwBHMEUCICiGfq+hSThRL2m8H0awoDR8OpnEHNkF0nI6nL5yYL/j 889 AiEAxwebGs/T6Es0YarPzoQJrVZqk+sHH/t+jrSrKd5TDjcAdgCHdb/nWXz4jEOZ 890 X73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAWm5hYNgAAAEAwBHMEUCIQD9OWA8KGL6 891 bxDKfgIleHJWB0iWieRs88VgJyfAg/aFDgIgQ/OsdSF9XOy1foqge0DTDM2FExuw 892 0JR0AGZWXoNtJzMAdgBElGUusO7Or8RAB9io/ijA2uaCvtjLMbU/0zOWtbaBqAAA 893 AWm5hYHgAAAEAwBHMEUCIQC4vua1n3BqthEqpA/VBTcsNwMtAwpCuac2IhJ9wx6X 894 /AIgb+o00k28JQo9TMpP4vzJ3BD3HXWSNc2Zizbq7mkUQYMwCgYIKoZIzj0EAwMD 895 aQAwZgIxAJsX7d0SuA8ddf/m7IWfNfs3MQfJyGkEezMJX1t6sRso5z50SS12LpXe 896 muGa1FE2ZgIxAL+CDUF5pz7mhrAEIjQ1MqlpF9tH40dJGvYZZQ3W23cMzSkDfvlt 897 y5S4RfWHIIPjbw== 898 -----END CERTIFICATE----- 900 Authors' Addresses 902 Richard Barnes 903 Cisco 904 Email: rlb@ipv.sx 906 Subodh Iyengar 907 Facebook 908 Email: subodh@fb.com 910 Nick Sullivan 911 Cloudflare 912 Email: nick@cloudflare.com 914 Eric Rescorla 915 Mozilla 916 Email: ekr@rtfm.com