idnits 2.17.1 draft-ietf-tls-subcerts-06.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 (5 February 2020) is 1535 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: 8 August 2020 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 Mozilla 10 5 February 2020 12 Delegated Credentials for TLS 13 draft-ietf-tls-subcerts-06 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 8 August 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 Network (CDNs) or remote data 103 centers. This allows server operators to limit the exposure of keys 104 in cases that they do not realize a compromise has occurred. The 105 risk inherent in cross-organizational transactions makes it 106 operationally infeasible to rely on an external CA for such short- 107 lived credentials. In Online Certificate Status Protocol (OCSP) 108 stapling (i.e., using the Certificate Status extension type ocsp 109 [RFC8446], if an operator chooses to talk frequently to the CA to 110 obtain stapled responses, then failure to fetch an OCSP stapled 111 response results only in degraded performance. On the other hand, 112 failure to fetch a potentially large number of short lived 113 certificates would result in the service not being available, which 114 creates greater operational risk. 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 algorithm and expected_cert_verify_algorithm fields MUST be of a 410 type advertised by the client in the SignatureSchemeList and are 411 considered invalid otherwise. Clients that receive invalid delegated 412 credentials MUST terminate the connection with an "illegal_parameter" 413 alert. 415 4.1.2. Client authentication 417 A server which supports this specification SHALL send an empty 418 "delegated_credential" extension in the CertificateRequest message 419 when requesting client authentication. 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 and expected_cert_verify_algorithm fields MUST be of a 435 type advertised by the server in the "signature_algorithms" extension 436 and are considered invalid otherwise. Servers that receive invalid 437 delegated credentials MUST terminate the connection with an 438 "illegal_parameter" alert. 440 4.1.3. Validating a Delegated Credential 442 On receiving a delegated credential and a certificate chain, the peer 443 validates the certificate chain and matches the end-entity 444 certificate to the peer's expected identity in the usual way. It 445 also takes the following steps: 447 1. Verify that the current time is within the validity interval of 448 the credential and that the credential's time to live is no more 449 than the maximum validity period. This is done by asserting that 450 the current time is no more than the delegation certificate's 451 notBefore value plus DelegatedCredential.cred.valid_time. 453 2. Verify that expected_cert_verify_algorithm matches the scheme 454 indicated in the peer's CertificateVerify message and that the 455 algorithm is allowed for use with delegated credentials. 457 3. Verify that the end-entity certificate satisfies the conditions 458 in Section 4.2. 460 4. Use the public key in the peer's end-entity certificate to verify 461 the signature of the credential using the algorithm indicated by 462 DelegatedCredential.algorithm. 464 If one or more of these checks fail, then the delegated credential is 465 deemed invalid. Clients and servers that receive invalid delegated 466 credentials MUST terminate the connection with an "illegal_parameter" 467 alert. If successful, the participant receiving the Certificate 468 message uses the public key in the credential to verify the signature 469 in the peer's CertificateVerify message. 471 4.2. Certificate Requirements 473 We define a new X.509 extension, DelegationUsage, to be used in the 474 certificate when the certificate permits the usage of delegated 475 credentials. What follows is the ASN.1 [X.680] for the 476 DelegationUsage certificate extension. 478 ext-delegationUsage EXTENSION ::= { 479 SYNTAX DelegationUsage IDENTIFIED BY id-ce-delegationUsage 480 } 482 DelegationUsage ::= NULL 484 id-ce-delegationUsage OBJECT IDENTIFIER ::= { 485 1 3 6 1 4 1 44363 44 486 } 488 The extension MUST be marked non-critical. (See Section 4.2 of 489 [RFC5280].) The client MUST NOT accept a delegated credential unless 490 the server's end-entity certificate satisfies the following criteria: 492 * It has the DelegationUsage extension. 494 * It has the digitalSignature KeyUsage (see the KeyUsage extension 495 defined in [RFC5280]). 497 5. IANA Considerations 499 This document registers the "delegated_credentials" extension in the 500 "TLS ExtensionType Values" registry. The "delegated_credentials" 501 extension has been assigned a code point of 34. The IANA registry 502 lists this extension as "Recommended" (i.e., "Y") and indicates that 503 it may appear in the ClientHello (CH), CertificateRequest (CR), or 504 Certificate (CT) messages in TLS 1.3 [RFC8446]. 506 This document also defines an ASN.1 module for the DelegationUsage 507 certificate extension in Appendix A. IANA is requested to register 508 an Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX 509 Module Identifier" arc. An OID for the DelegationUsage certificate 510 extension is not needed as it is already assigned to the extension 511 from Cloudflare's IANA Private Enterprise Number (PEN) arc. 513 6. Security Considerations 514 6.1. Security of delegated private key 516 Delegated credentials limit the exposure of the TLS private key by 517 limiting its validity. An attacker who compromises the private key 518 of a delegated credential can act as a man-in-the-middle until the 519 delegate credential expires, however they cannot create new delegated 520 credentials. Thus, delegated credentials should not be used to send 521 a delegation to an untrusted party, but is meant to be used between 522 parties that have some trust relationship with each other. The 523 secrecy of the delegated private key is thus important and several 524 access control mechanisms SHOULD be used to protect it, including 525 file system controls, physical security, or hardware security 526 modules. 528 6.2. Re-use of delegated credentials in multiple contexts 530 It is possible to use the same delegated credential for both client 531 and server authentication if the Certificate allows it. This is safe 532 because the context string used for delegated credentials is distinct 533 in both contexts. 535 6.3. Revocation of delegated credentials 537 Delegated credentials do not provide any additional form of early 538 revocation. Since it is short lived, the expiry of the delegated 539 credential would revoke the credential. Revocation of the long term 540 private key that signs the delegated credential also implicitly 541 revokes the delegated credential. 543 6.4. Interactions with session resumption 545 If a client decides to cache the certificate chain an re-validate it 546 when resuming a connection, the client SHOULD also cache the 547 associated delegated credential and re-validate it. 549 6.5. Privacy considerations 551 Delegated credentials can be valid for 7 days and it is much easier 552 for a service to create delegated credential than a certificate 553 signed by a CA. A service could determine the client time and clock 554 skew by creating several delegated credentials with different expiry 555 timestamps and observing whether the client would accept it. Client 556 time could be unique and thus privacy sensitive clients, such as 557 browsers in incognito mode, who do not trust the service might not 558 want to advertise support for delegated credentials or limit the 559 number of probes that a server can perform. 561 7. Acknowledgements 563 Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh 564 Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson 565 Ladd for their discussions, ideas, and bugs they have found. 567 8. References 569 8.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 577 Housley, R., and W. Polk, "Internet X.509 Public Key 578 Infrastructure Certificate and Certificate Revocation List 579 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 580 . 582 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 583 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 584 May 2017, . 586 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 587 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 588 . 590 [X.680] ITU-T, "Information technology - Abstract Syntax Notation 591 One (ASN.1): Specification of basic notation", ISO/ 592 IEC 8824-1:2015, November 2015. 594 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 595 Specification of Basic Encoding Rules (BER), Canonical 596 Encoding Rules (CER) and Distinguished Encoding Rules 597 (DER)", ISO/IEC 8825-1:2015, November 2015. 599 8.2. Informative References 601 [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake 602 Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. 604 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 605 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 606 Proxy Certificate Profile", RFC 3820, 607 DOI 10.17487/RFC3820, June 2004, 608 . 610 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 611 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 612 DOI 10.17487/RFC5912, June 2010, 613 . 615 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 616 Kasten, "Automatic Certificate Management Environment 617 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 618 . 620 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 621 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 622 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 623 Conference on Computer and Communications Security , 2015. 625 Appendix A. ASN.1 Module 627 The following ASN.1 module provides the complete definition of the 628 DelegationUsage certificate extension. The ASN.1 module makes 629 imports from [RFC5912]. 631 DelegatedCredentialExtn { iso(1) identified-organization(3) dod(6) 632 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod- 633 delegated-credential-extn(TBD) } 635 DEFINITIONS IMPLICIT TAGS ::= 637 BEGIN 639 - EXPORT ALL 641 IMPORTS 643 EXTENSION FROM PKIX-CommonTypes-2009 - From RFC 5912 { iso(1) 644 identified-organization(3) dod(6) internet(1) security(5) 645 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; 647 - OIDS 649 id-cloudflare OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 44363 } 651 - EXTENSION 653 ext-delegationUsage EXTENSION ::= { SYNTAX DelegationUsage IDENTIFIED 654 BY id-ce-delegationUsage } 656 id-ce-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } 657 DelegationUsage ::= NULL 659 END 661 Authors' Addresses 663 Richard Barnes 664 Cisco 666 Email: rlb@ipv.sx 668 Subodh Iyengar 669 Facebook 671 Email: subodh@fb.com 673 Nick Sullivan 674 Cloudflare 676 Email: nick@cloudflare.com 678 Eric Rescorla 679 Mozilla 681 Email: ekr@rtfm.com