idnits 2.17.1 draft-ietf-tls-subcerts-07.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: ---------------------------------------------------------------------------- No issues found here. 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 (9 March 2020) is 1503 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: 10 September 2020 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 Mozilla 10 9 March 2020 12 Delegated Credentials for TLS 13 draft-ietf-tls-subcerts-07 15 Abstract 17 The organizational separation between the operator of a TLS endpoint 18 and the certification authority can create limitations. For example, 19 the lifetime of certificates, how they may be used, and the 20 algorithms they support are ultimately determined by the 21 certification authority. This document describes a mechanism by 22 which operators may delegate their own credentials for use in TLS, 23 without breaking compatibility with peers that do not support this 24 specification. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 10 September 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 61 2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Client and Server behavior . . . . . . . . . . . . . . . 8 67 4.1.1. Server authentication . . . . . . . . . . . . . . . . 9 68 4.1.2. Client authentication . . . . . . . . . . . . . . . . 9 69 4.1.3. Validating a Delegated Credential . . . . . . . . . . 10 70 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 11 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 6.1. Security of delegated private key . . . . . . . . . . . . 12 74 6.2. Re-use of delegated credentials in multiple 75 contexts . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.3. Revocation of delegated credentials . . . . . . . . . . . 12 77 6.4. Interactions with session resumption . . . . . . . . . . 12 78 6.5. Privacy considerations . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 8.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 Typically, a TLS server uses a certificate provided by some entity 89 other than the operator of the server (a "Certification Authority" or 90 CA) [RFC8446] [RFC5280]. This organizational separation makes the 91 TLS server operator dependent on the CA for some aspects of its 92 operations, for example: 94 * Whenever the server operator wants to deploy a new certificate, it 95 has to interact with the CA. 97 * The server operator can only use TLS authentication schemes for 98 which the CA will issue credentials. 100 These dependencies cause problems in practice. Server operators 101 often want to create short-lived certificates for servers in low- 102 trust zones such as Content Delivery Networks (CDNs) or remote data 103 centers. This allows server operators to limit the exposure of keys 104 in cases where they do not realize a compromise has occurred. 105 However, the risk inherent in cross-organizational transactions makes 106 it operationally infeasible to rely on an external CA for such short- 107 lived credentials. For instance, in the case of Online Certificate 108 Status Protocol (OCSP) stapling (i.e., using the Certificate Status 109 extension type ocsp [RFC8446]), a CA may fail to deliver OCSP stapled 110 response. While this will result in degraded performance, the 111 ramifications of failing to deliver short-lived certificates are even 112 worse: the service that depends on those certificates would go down 113 entirely. Thus, ensuring independence from CAs for short-lived 114 certificates is critical to the uptime of a service. 116 To remove these dependencies, this document proposes a limited 117 delegation mechanism that allows a TLS peer to issue its own 118 credentials within the scope of a certificate issued by an external 119 CA. Because the above problems do not relate to the CA's inherent 120 function of validating possession of names, it is safe to make such 121 delegations as long as they only enable the recipient of the 122 delegation to speak for names that the CA has authorized. For 123 clarity, we will refer to the certificate issued by the CA as a 124 "certificate", or "delegation certificate", and the one issued by the 125 operator as a "delegated credential" or "DC". 127 2. Conventions and Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2.1. Change Log 137 (*) indicates changes to the wire protocol. 139 draft-06 141 * Modified IANA section, fixed nits 143 draft-05 144 * Removed support for PKCS 1.5 RSA signature algorithms. 146 * Additional security considerations. 148 draft-04 150 * Add support for client certificates. 152 draft-03 154 * Remove protocol version from the Credential structure. (*) 156 draft-02 158 * Change public key type. (*) 160 * Change DelegationUsage extension to be NULL and define its object 161 identifier. 163 * Drop support for TLS 1.2. 165 * Add the protocol version and credential signature algorithm to the 166 Credential structure. (*) 168 * Specify undefined behavior in a few cases: when the client 169 receives a DC without indicated support; when the client indicates 170 the extension in an invalid protocol version; and when DCs are 171 sent as extensions to certificates other than the end-entity 172 certificate. 174 3. Solution Overview 176 A delegated credential is a digitally signed data structure with two 177 semantic fields: a validity interval and a public key (along with its 178 associated signature algorithm). The signature on the credential 179 indicates a delegation from the certificate that is issued to the 180 peer. The secret key used to sign a credential corresponds to the 181 public key of the peer's X.509 end-entity certificate [RFC5280]. 183 A TLS handshake that uses delegated credentials differs from a normal 184 handshake in a few important ways: 186 * The initiating peer provides an extension in its ClientHello or 187 CertificateRequest that indicates support for this mechanism. 189 * The peer sending the Certificate message provides both the 190 certificate chain terminating in its certificate as well as the 191 delegated credential. 193 * The authenticating intitiator uses information from the peer's 194 certificate to verify the delegated credential and that the peer 195 is asserting an expected identity. 197 * Peers accepting the delegated credential use it as the 198 certificate's working key for the TLS hadshake 200 As detailed in Section 4, the delegated credential is 201 cryptographically bound to the end-entity certificate with which the 202 credential may be used. This document specifies the use of delegated 203 credentials in TLS 1.3 or later; their use in prior versions of the 204 protocol is not allowed. 206 Delegated credentials allow a peer to terminate TLS connections on 207 behalf of the certificate owner. If a credential is stolen, there is 208 no mechanism for revoking it without revoking the certificate itself. 209 To limit exposure in case of delegated credential private key 210 compromise, delegated credentials have a maximum validity period. In 211 the absence of an application profile standard specifying otherwise, 212 the maximum validity period is set to 7 days. Peers MUST NOT issue 213 credentials with a validity period longer than the maximum validity 214 period. This mechanism is described in detail in Section 4.1. 216 It was noted in [XPROT] that certificates in use by servers that 217 support outdated protocols such as SSLv2 can be used to forge 218 signatures for certificates that contain the keyEncipherment KeyUsage 219 ([RFC5280] section 4.2.1.3). In order to prevent this type of cross- 220 protocol attack, we define a new DelegationUsage extension to X.509 221 that permits use of delegated credentials. (See Section 4.2.) 223 3.1. Rationale 225 Delegated credentials present a better alternative than other 226 delegation mechanisms like proxy certificates [RFC3820] for several 227 reasons: 229 * There is no change needed to certificate validation at the PKI 230 layer. 232 * X.509 semantics are very rich. This can cause unintended 233 consequences if a service owner creates a proxy certificate where 234 the properties differ from the leaf certificate. For this reason, 235 delegated credentials have very restricted semantics that should 236 not conflict with X.509 semantics. 238 * Proxy certificates rely on the certificate path building process 239 to establish a binding between the proxy certificate and the 240 server certificate. Since the certificate path building process 241 is not cryptographically protected, it is possible that a proxy 242 certificate could be bound to another certificate with the same 243 public key, with different X.509 parameters. Delegated 244 credentials, which rely on a cryptographic binding between the 245 entire certificate and the delegated credential, cannot. 247 * Each delegated credential is bound to a specific signature 248 algorithm that may be used to sign the TLS handshake ([RFC8446] 249 section 4.2.3). This prevents them from being used with other, 250 perhaps unintended signature algorithms. 252 3.2. Related Work 254 Many of the use cases for delegated credentials can also be addressed 255 using purely server-side mechanisms that do not require changes to 256 client behavior (e.g., a PKCS#11 interface or a remote signing 257 mechanism [KEYLESS]). These mechanisms, however, incur per- 258 transaction latency, since the front-end server has to interact with 259 a back-end server that holds a private key. The mechanism proposed 260 in this document allows the delegation to be done off-line, with no 261 per-transaction latency. The figure below compares the message flows 262 for these two mechanisms with TLS 1.3 [RFC8446]. 264 Remote key signing: 266 Client Front-End Back-End 267 |----ClientHello--->| | 268 |<---ServerHello----| | 269 |<---Certificate----| | 270 | |<---remote sign---->| 271 |<---CertVerify-----| | 272 | ... | | 274 Delegated credentials: 276 Client Front-End Back-End 277 | |<--DC distribution->| 278 |----ClientHello--->| | 279 |<---ServerHello----| | 280 |<---Certificate----| | 281 |<---CertVerify-----| | 282 | ... | | 284 These two mechanisms can be complementary. A server could use 285 credentials for clients that support them, while using [KEYLESS] to 286 support legacy clients. 288 It is possible to address the short-lived certificate concerns above 289 by automating certificate issuance, e.g., with Automated Certificate 290 Managmeent Encvironment (ACME) [RFC8555]. In addition to requiring 291 frequent operationally-critical interactions with an external party, 292 this makes the server operator dependent on the CA's willingness to 293 issue certificates with sufficiently short lifetimes. It also fails 294 to address the issues with algorithm support. Nonetheless, existing 295 automated issuance APIs like ACME may be useful for provisioning 296 credentials within an operator network. 298 4. Delegated Credentials 300 While X.509 forbids end-entity certificates from being used as 301 issuers for other certificates, it is perfectly fine to use them to 302 issue other signed objects as long as the certificate contains the 303 digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a 304 new signed object format that would encode only the semantics that 305 are needed for this application. The credential has the following 306 structure: 308 struct { 309 uint32 valid_time; 310 SignatureScheme expected_cert_verify_algorithm; 311 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 312 } Credential; 314 valid_time: Relative time in seconds from the beginning of the 315 delegation certificate's notBefore value after which the delegated 316 credential is no longer valid. 318 expected_cert_verify_algorithm: The signature algorithm of the 319 credential key pair, where the type SignatureScheme is as defined 320 in [RFC8446]. This is expected to be the same as 321 CertificateVerify.algorithm sent by the server. Only signature 322 algorithms allowed for use in CertificateVerify messages are 323 allowed. When using RSA, the public key MUST NOT use the 324 rsaEncryption OID, as a result, the following algorithms are not 325 allowed for use with delegated credentials: rsa_pss_rsae_sha256, 326 rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. 328 ASN1_subjectPublicKeyInfo: The credential's public key, a DER- 329 encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. 331 The delegated credential has the following structure: 333 struct { 334 Credential cred; 335 SignatureScheme algorithm; 336 opaque signature<0..2^16-1>; 337 } DelegatedCredential; 339 algorithm: The signature algorithm used to verify 340 DelegatedCredential.signature. 342 signature: The delegation, a signature that binds the credential to 343 the end-entity certificate's public key as specified below. The 344 signature scheme is specified by DelegatedCredential.algorithm. 346 The signature of the DelegatedCredential is computed over the 347 concatenation of: 349 1. A string that consists of octet 32 (0x20) repeated 64 times. 351 2. The context string "TLS, server delegated credentials" for 352 servers and "TLS, client delegated credentials" for clients. 354 3. A single 0 byte, which serves as the separator. 356 4. The DER-encoded X.509 end-entity certificate used to sign the 357 DelegatedCredential. 359 5. DelegatedCredential.cred. 361 6. DelegatedCredential.algorithm. 363 The signature effectively binds the credential to the parameters of 364 the handshake in which it is used. In particular, it ensures that 365 credentials are only used with the certificate and signature 366 algorithm chosen by the delegator. Minimizing their semantics in 367 this way is intended to mitigate the risk of cross protocol attacks 368 involving delegated credentials. 370 The code changes required in order to create and verify delegated 371 credentials, and the implementation complexity this entails, are 372 localized to the TLS stack. This has the advantage of avoiding 373 changes to security-critical and often delicate PKI code. 375 4.1. Client and Server behavior 377 This document defines the following TLS extension code point. 379 enum { 380 ... 381 delegated_credential(34), 382 (65535) 383 } ExtensionType; 385 4.1.1. Server authentication 387 A client which supports this specification SHALL send a 388 "delegated_credential" extension in its ClientHello. The body of the 389 extension consists of a SignatureSchemeList: 391 struct { 392 SignatureScheme supported_signature_algorithm<2..2^16-2>; 393 } SignatureSchemeList; 395 If the client receives a delegated credential without indicating 396 support, then the client MUST abort with an "unexpected_message" 397 alert. 399 If the extension is present, the server MAY send a delegated 400 credential; if the extension is not present, the server MUST NOT send 401 a delegated credential. The server MUST ignore the extension unless 402 TLS 1.3 or a later version is negotiated. 404 The server MUST send the delegated credential as an extension in the 405 CertificateEntry of its end-entity certificate; the client SHOULD 406 ignore delegated credentials sent as extensions to any other 407 certificate. 409 The expected_cert_verify_algorithm field MUST be of a type advertised 410 by the client in the SignatureSchemeList and is considered invalid 411 otherwise. Clients that receive invalid delegated credentials MUST 412 terminate the connection with an "illegal_parameter" alert. 414 4.1.2. Client authentication 416 A server that supports this specification SHALL send a 417 "delegated_credential" extension in the CertificateRequest message 418 when requesting client authentication. The body of the extension 419 consists of a SignatureSchemeList. If the server receives a 420 delegated credential without indicating support in its 421 CertificateRequest, then the server MUST abort with an 422 "unexpected_message" alert. 424 If the extension is present, the client MAY send a delegated 425 credential; if the extension is not present, the client MUST NOT send 426 a delegated credential. The client MUST ignore the extension unless 427 TLS 1.3 or a later version is negotiated. 429 The client MUST send the delegated credential as an extension in the 430 CertificateEntry of its end-entity certificate; the server SHOULD 431 ignore delegated credentials sent as extensions to any other 432 certificate. 434 The algorithm field MUST be of a type advertised by the server in the 435 "signature_algorithms" extension of the CertificateRequest message 436 and the expected_cert_verify_algorithm field MUST be of a type 437 advertised by the server in the SignatureSchemeList and considered 438 invalid otherwise. Servers that receive invalid delegated 439 credentials MUST terminate the connection with an "illegal_parameter" 440 alert. 442 4.1.3. Validating a Delegated Credential 444 On receiving a delegated credential and a certificate chain, the peer 445 validates the certificate chain and matches the end-entity 446 certificate to the peer's expected identity in the usual way. It 447 also takes the following steps: 449 1. Verify that the current time is within the validity interval of 450 the credential and that the credential's time to live is no more 451 than the maximum validity period. This is done by asserting that 452 the current time is no more than the delegation certificate's 453 notBefore value plus DelegatedCredential.cred.valid_time. 455 2. Verify that expected_cert_verify_algorithm matches the scheme 456 indicated in the peer's CertificateVerify message and that the 457 algorithm is allowed for use with delegated credentials. 459 3. Verify that the end-entity certificate satisfies the conditions 460 in Section 4.2. 462 4. Use the public key in the peer's end-entity certificate to verify 463 the signature of the credential using the algorithm indicated by 464 DelegatedCredential.algorithm. 466 If one or more of these checks fail, then the delegated credential is 467 deemed invalid. Clients and servers that receive invalid delegated 468 credentials MUST terminate the connection with an "illegal_parameter" 469 alert. If successful, the participant receiving the Certificate 470 message uses the public key in the credential to verify the signature 471 in the peer's CertificateVerify message. 473 4.2. Certificate Requirements 475 We define a new X.509 extension, DelegationUsage, to be used in the 476 certificate when the certificate permits the usage of delegated 477 credentials. What follows is the ASN.1 [X.680] for the 478 DelegationUsage certificate extension. 480 ext-delegationUsage EXTENSION ::= { 481 SYNTAX DelegationUsage IDENTIFIED BY id-ce-delegationUsage 482 } 484 DelegationUsage ::= NULL 486 id-ce-delegationUsage OBJECT IDENTIFIER ::= 487 { iso(1) identified-organization(3) dod(6) internet(1) 488 private(4) enterprise(1) id-cloudflare(44363) 44 } 490 The extension MUST be marked non-critical. (See Section 4.2 of 491 [RFC5280].) The client MUST NOT accept a delegated credential unless 492 the server's end-entity certificate satisfies the following criteria: 494 * It has the DelegationUsage extension. 496 * It has the digitalSignature KeyUsage (see the KeyUsage extension 497 defined in [RFC5280]). 499 5. IANA Considerations 501 This document registers the "delegated_credentials" extension in the 502 "TLS ExtensionType Values" registry. The "delegated_credentials" 503 extension has been assigned a code point of 34. The IANA registry 504 lists this extension as "Recommended" (i.e., "Y") and indicates that 505 it may appear in the ClientHello (CH), CertificateRequest (CR), or 506 Certificate (CT) messages in TLS 1.3 [RFC8446]. 508 This document also defines an ASN.1 module for the DelegationUsage 509 certificate extension in Appendix A. IANA is requested to register 510 an Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX 511 Module Identifier" arc. An OID for the DelegationUsage certificate 512 extension is not needed as it is already assigned to the extension 513 from Cloudflare's IANA Private Enterprise Number (PEN) arc. 515 6. Security Considerations 516 6.1. Security of delegated private key 518 Delegated credentials limit the exposure of the TLS private key by 519 limiting its validity. An attacker who compromises the private key 520 of a delegated credential can act as a man-in-the-middle until the 521 delegate credential expires, however they cannot create new delegated 522 credentials. Thus, delegated credentials should not be used to send 523 a delegation to an untrusted party, but is meant to be used between 524 parties that have some trust relationship with each other. The 525 secrecy of the delegated private key is thus important and several 526 access control mechanisms SHOULD be used to protect it, including 527 file system controls, physical security, or hardware security 528 modules. 530 6.2. Re-use of delegated credentials in multiple contexts 532 It is possible to use the same delegated credential for both client 533 and server authentication if the Certificate allows it. This is safe 534 because the context string used for delegated credentials is distinct 535 in both contexts. 537 6.3. Revocation of delegated credentials 539 Delegated credentials do not provide any additional form of early 540 revocation. Since it is short lived, the expiry of the delegated 541 credential would revoke the credential. Revocation of the long term 542 private key that signs the delegated credential also implicitly 543 revokes the delegated credential. 545 6.4. Interactions with session resumption 547 If a client decides to cache the certificate chain an re-validate it 548 when resuming a connection, the client SHOULD also cache the 549 associated delegated credential and re-validate it. 551 6.5. Privacy considerations 553 Delegated credentials can be valid for 7 days and it is much easier 554 for a service to create delegated credential than a certificate 555 signed by a CA. A service could determine the client time and clock 556 skew by creating several delegated credentials with different expiry 557 timestamps and observing whether the client would accept it. Client 558 time could be unique and thus privacy sensitive clients, such as 559 browsers in incognito mode, who do not trust the service might not 560 want to advertise support for delegated credentials or limit the 561 number of probes that a server can perform. 563 7. Acknowledgements 565 Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh 566 Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson 567 Ladd for their discussions, ideas, and bugs they have found. 569 8. References 571 8.1. Normative References 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 579 Housley, R., and W. Polk, "Internet X.509 Public Key 580 Infrastructure Certificate and Certificate Revocation List 581 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 582 . 584 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 585 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 586 May 2017, . 588 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 589 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 590 . 592 [X.680] ITU-T, "Information technology - Abstract Syntax Notation 593 One (ASN.1): Specification of basic notation", ISO/ 594 IEC 8824-1:2015, November 2015. 596 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 597 Specification of Basic Encoding Rules (BER), Canonical 598 Encoding Rules (CER) and Distinguished Encoding Rules 599 (DER)", ISO/IEC 8825-1:2015, November 2015. 601 8.2. Informative References 603 [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake 604 Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. 606 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 607 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 608 Proxy Certificate Profile", RFC 3820, 609 DOI 10.17487/RFC3820, June 2004, 610 . 612 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 613 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 614 DOI 10.17487/RFC5912, June 2010, 615 . 617 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 618 Kasten, "Automatic Certificate Management Environment 619 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 620 . 622 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 623 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 624 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 625 Conference on Computer and Communications Security , 2015. 627 Appendix A. ASN.1 Module 629 The following ASN.1 module provides the complete definition of the 630 DelegationUsage certificate extension. The ASN.1 module makes 631 imports from [RFC5912]. 633 DelegatedCredentialExtn 634 { iso(1) identified-organization(3) dod(6) internet(1) 635 security(5) mechanisms(5) pkix(7) id-mod(0) 636 id-mod-delegated-credential-extn(TBD) } 638 DEFINITIONS IMPLICIT TAGS ::= 639 BEGIN 641 -- EXPORT ALL 643 IMPORTS 645 EXTENSION 646 FROM PKIX-CommonTypes-2009 -- From RFC 5912 647 { iso(1) identified-organization(3) dod(6) internet(1) 648 security(5) mechanisms(5) pkix(7) id-mod(0) 649 id-mod-pkixCommon-02(57) } ; 651 -- OID 653 id-cloudflare OBJECT IDENTIFIER ::= 654 { iso(1) identified-organization(3) dod(6) internet(1) private(4) 655 enterprise(1) 44363 } 657 -- EXTENSION 659 ext-delegationUsage EXTENSION ::= 660 { SYNTAX DelegationUsage 661 IDENTIFIED BY id-ce-delegationUsage } 663 id-ce-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } 665 DelegationUsage ::= NULL 667 END 669 Authors' Addresses 671 Richard Barnes 672 Cisco 674 Email: rlb@ipv.sx 676 Subodh Iyengar 677 Facebook 679 Email: subodh@fb.com 680 Nick Sullivan 681 Cloudflare 683 Email: nick@cloudflare.com 685 Eric Rescorla 686 Mozilla 688 Email: ekr@rtfm.com