value includes the content type and padding added in TLS 1.3 (that is, the complete length of TLSInnerPlaintext).  Padding added as part of encryption, such as that added by a block cipher, is not included <del> in this count. </del>  An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3 MUST NOT send records larger than the protocol-defined limit, unless explicitly allowed by a future TLS version or extension. <del> The size limit expressed in the "record_size_limit" extension doesn't account for expansion due to compression or record protection.  It is expected that a constrained device will disable compression and know - and account for - the maximum expansion possible due to record protection based on the cipher suites it offers or selects.  Note that up to 256 octets of padding and padding length can be added to block ciphers. </del> The record size limit only applies to records sent toward the endpoint that advertises the limit.  An endpoint MAY send records that are larger than the limit it advertises as its own limit. In TLS 1.3, the server sends the "record_size_limit" extension in the EncryptedExtensions message.  5. The "record_size_limit" extension replaces the "max_fragment_length"

The idea of this change is to try to constrain how much padding a sender can add. This is done by calculating the size of a record with maximum plaintext and minimum padding. No other record can exceed this size, though smaller packets can pad to reach this size. I was going to include a formula, then realized that the simple answer is best: pad to the record size limit, then pad to get to a multiple of the block size as normal. Most implementations will be OK because they don't bother with the first step.

value includes the content type and padding added in TLS 1.3 (that is, the complete length of TLSInnerPlaintext).  Padding added as part of encryption, such as that added by a block cipher, is not included  <ins> in this count (see expansion). </ins> An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3 MUST NOT send records larger than the protocol-defined limit, unless explicitly allowed by a future TLS version or extension.  The record size limit only applies to records sent toward the endpoint that advertises the limit.  An endpoint MAY send records that are larger than the limit it advertises as its own limit. In TLS 1.3, the server sends the "record_size_limit" extension in the EncryptedExtensions message. <ins> 4.1. The size limit expressed in the "record_size_limit" extension doesn't account for expansion due to compression or record protection.  It is expected that a constrained device will disable compression to avoid unpredictable increases in record size.  Stream ciphers and existing AEAD ciphers don't permit variable amounts of expansion, but block ciphers do permit variable expansion. In TLS 1.2, block ciphers allow between 1 and 256 octets of padding. When a limit lower than the protocol-defined limit is advertised, a second limit applies to the length of records that use block ciphers. An endpoint MUST NOT add padding to records that would cause the protected record to exceed the size of a protected record that contains the maximum amount of plaintext and the minimum permitted amount of padding. For example, TLS_RSA_WITH_AES_128_CBC_SHA has 16 octet blocks and a 20 octet MAC.  Given a record size limit of 256, a record of that length would require a minimum of 11 octets of padding (for RFC5246 where the MAC is covered by encryption); or 15 octets if the "encrypt_then_mac" extension RFC7366 is negotiated.  With this limit, a record with 250 octets of plaintext could be padded to the same length by including at most 17 octets of padding; or 21 octets with "encrypt_then_mac". An implementation that always adds the minimum amount of padding will always comply with this requirement. </ins> 5. The "record_size_limit" extension replaces the "max_fragment_length"


This extension replaces "max_fragment_length" RFC6066, which this document deprecates.  This extension is valid in all versions of TLS.  2. The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this records.  This admits the possibility that the extension might not be negotiated when a connection is renegotiated or resumed.  4.1. The size limit expressed in the "record_size_limit" extension doesn't

Add an applicability statement. This only addresses buffer space issues, not processing or bandwidth constraints. I didn't observe (in the introduction) that this can negatively affect bandwidth, that's later. Hannes also observed that we don't really talk about the path MTU. I made it clear that these are separate and independent limitations. For NAME
Thanks for providing this text. While I had been hoping for more clarifications about the interactions between the MTU information entering the stack from below and the RSL parameter passed to the stack from the application side I think it is a good start.
Oh, also, I have moved the intro text down a paragraph. I think that it is better to talk about the properties of this extension rather than focus more on what MFL does or doesn't do.

This extension replaces "max_fragment_length" RFC6066, which this document deprecates.  This extension is valid in all versions of TLS. <ins> A smaller protected record size is just one of many problems that a constrained implementation might need to address.  The "record_size_limit" extension only addresses the memory allocation problem, it does not address limits of code size, or processing and bandwidth capacity. </ins> 2. The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this records.  This admits the possibility that the extension might not be negotiated when a connection is renegotiated or resumed. <ins> The record size limit can interact with the maximum transmission unit (MTU) in DTLS, but it is a separate and independent constraint on record size.  In particular, it is not appropriate to use the record size limit in place of path MTU detection.  The record size limit is a fixed property of an endpoint that is set during the handshake and fixed thereafter.  In comparison, the MTU is determined by the network path and can change dynamically over time. </ins> 4.1. The size limit expressed in the "record_size_limit" extension doesn't


the allowance for expansion to 256 octets.  Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations.  The "max_fragment_length" extension RFC6066 was designed to enable constrained clients to negotiate a lower record size.  However, "max_fragment_length" suffers from several design problems (see mfl- The "max_fragment_length" extension is also ill-suited to cases where the capabilities of client and server are asymmetric.  Constraints on <del> record size are often receiver constraints.  In particular, an Authentication Encryption with Additional Data (AEAD) ciphers (see RFC5116) API requires that an entire record be present to decrypt and authenticate it.  Some implementations choose not to implement an AEAD interface in this way to avoid this problem, but that exposes them to risks that an AEAD is intended to protect against. </del>  In comparison, an implementation might be able to send data incrementally.  Encryption does not have the same atomicity

This is a good part of what motivates the existence of the mechanism.
The text changes look good to me. I only had a minor remark regarding another sentence.

the allowance for expansion to 256 octets.  Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations. <ins> An Authentication Encryption with Additional Data (AEAD) ciphers (see RFC5116) API requires that an entire record be present to decrypt and authenticate it.  Similarly, other ciphers cannot produce authenticated data until the entire record is present.  Thus, incremental processing of records minimally exposes endpoints to the risk of forged data. </ins> The "max_fragment_length" extension RFC6066 was designed to enable constrained clients to negotiate a lower record size.  However, "max_fragment_length" suffers from several design problems (see mfl- The "max_fragment_length" extension is also ill-suited to cases where the capabilities of client and server are asymmetric.  Constraints on  <ins> record size are often receiver constraints. </ins> In comparison, an implementation might be able to send data incrementally.  Encryption does not have the same atomicity


This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that <del> is, the complete length of TLSInnerPlaintext).  Padding added as part of encryption, such as that added by a block cipher, is not included in this count (see expansion). </del>  An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3

This isn't as easy as in TLS 1.3, which has a clearly defined structure for what is fed into the AEAD. I've done my best. NAME this is the only change from your email that you might disagree with. Can you have a look please?

This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that  <ins> is, the complete length of TLSInnerPlaintext).  In TLS 1.2 and earlier, the limit covers all input to compression and encryption, that is the data that ultimately produces TLSCiphertext.fragment. Padding added as part of encryption, such as that added by a block cipher, is not included in this count (see expansion). </ins> An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3


protocol permits. For large data transfers, small record sizes can materially affect <del> performance TARREAU.  Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed. </del>  This would not be an issue if a codepoint were available or could be added for fragments of 2^14 octets.  However, RFC 6066 requires that

And simply explain what the costs of smaller records actually are.
Great summary. Thanks for adding the text. One minor question: My reading of the referenced email discussion is that the computational overhead is not just a matter of cryptographic processing but also the processing related to multiplexing, TCP-related processing and other implementation details (e.g., threading). Is this also your understanding of what the folks in the email thread were referring to?
My understanding is that the performance costs are largely due to context switching. That might be worse because of multiplexing. Willy did a separate talk on the costs of doing crypto at high data rates that I wish that I could reference. He had some great numbers about what it took just to move data from the kernel to user space and that was a significant impact on overall throughput.

protocol permits. For large data transfers, small record sizes can materially affect  <ins> performance.  Every record incurs additional costs, both in the additional octets for record headers and for expansion due to encryption.  Processing more records also adds computational overheads that can be amortized more effectively for larger record sizes.  Consequently, clients that are capable of receiving large records could be unwilling to risk reducing performance by offering the extension, especially if the extension is rarely needed. </ins> This would not be an issue if a codepoint were available or could be added for fragments of 2^14 octets.  However, RFC 6066 requires that


RecordSizeLimit: The value of RecordSizeLimit is the maximum size of record in octets <del> that the endpoint is willing to receive.  When the "record_size_limit" extension is negotiated, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer.  Unprotected messages - handshake messages in particular - are not subject to this limit. </del>  This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that

NAME requests: I believe we should re-word the text in the draft in such a way that it does not say record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. but instead says what you explained below. In essence, the RecordSizeLimit value can then be used by the TLS stack to determine the size of the fragments. "below" being that when writing, the limit determines when to create new records. It shouldn't prohibit writes that exceed the limit.

RecordSizeLimit: The value of RecordSizeLimit is the maximum size of record in octets  <ins> that the endpoint is willing to receive.  This value is used to limit the size of records that are created when encoding application data and handshake message into records. When the "record_size_limit" extension is negotiated, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. Unprotected messages - handshake messages in particular - are not subject to this limit. </ins> This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that


endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the <del> certification authority.  This document describes a mechanism to to </del>  overcome some of these limitations by enabling operators to delegate their own credentials for use in (D)TLS without breaking compatibility with peers that do not support this specification.

Need to address and directorate reviews.
Correction ARTART editorial are addressed via and .
and .
Also noted in ARTART review. Reviewer: Christian Amsüss Review result: Ready with Nits Thanks for this well-written document ART topics: The document does not touch on any of the typical ART review issues; times are relative in well understood units, and versioning, formal language (ASN.1, which is outside of my experience to check) and encoding infrastructure (struct) follows TLS practices. General comments: The introduction of this mechanism gives the impression of a band-aid applied to a PKI ecosystem that has accumulated many limitations as outlined in section The present solution appears good, but if there is ongoing work on the underlying issues (even experimentally), I'd appreciate a careful reference to it. Section 7.6 hints at the front end querying the back-end for creation of new DCs -- other than that, DC distribution (neither push- nor pull-based) is discussed. If there are any mechanisms brewing, I'd appreciate a reference as well. Please check: The IANA considerations list "delegated_credential" for CH, CR and CT messages. I did not find a reference in the text for Ct, only for CH and CR. Editorial comments: (p5) "result for the peer.." -- extraneous period. (p9, p15, p16) The "7 days" are introduced as the default for a profilable prarameter, but later used without further comment.
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-subcerts-?? Reviewer: Elwyn Davies Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Just a few editrial level nits. Major issues: None Minor issues: None. Nits/editorial comments: Abstract: The exact form of the abbreviation (D)TLS is not in the set of well-known abbreviations. I assume it is supposed to mean DTLS or TLS - This ought to be expanded on first use. Abstract: s/mechanism to to/mechanism to/ s1, para 2: CA is used before its expansion in para 3. s1, next to last para: "this document proposes" Hopefully when it becomes an RFC it will do more than propose. Suggest "this document introduces". s1, next to last para: "to speak for names" sounds a bit anthropomorphic to me, but I can't think of a simple alternative word. s1, last para: s/We will refer/This document refers/ [Not an academic paper!] s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ s4, definition of expectedcertverify_algorithm: " Only signature algorithms allowed for use in CertificateVerify message are allowed." Does this need a reference to the place where the list of such algorithms is recorded? s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated credentials sent as extensions to any other certificate." I would have though this ought to be a MUST. There is an equivalent in s4.1.2. I am not sure what the client/server might do if it doesn't ignore the DC. s4.1.3, para 1: s/same way that is done/same way that it is done/ s4.2, para 1: s/We define/This docuent defines/ sS/s5.1: RFC conventions prefer not to have sections empty of text: Add something like: "The following operational consideration should be taken into consideration when using Delegated Certificates:"

endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the  <ins> certification authority.  This document describes a mechanism to </ins> overcome some of these limitations by enabling operators to delegate their own credentials for use in (D)TLS without breaking compatibility with peers that do not support this specification.


notBefore value, after which the delegated credential is no longer valid.  Endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in client- <del> and-server-behavior). </del>  The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be 7.5. <del> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credentials than a certificate signed by a CA.  A service could determine the client time and clock skew by creating several delegated credentials with different expiry timestamps and observing whether the client would accept it.  Client time could be unique and thus privacy sensitive clients, such as browsers in incognito mode, who do not trust the service might not want to advertise support for delegated credentials or limit the number of probes that a server can perform. </del>  7.6. allow forging a signature over a delegated credential.  The forged delegated credential could then be used by the attacker as the equivalent of a man-in-the-middle certificate, valid for a maximum of <del> 7 days. </del>  Server operators should therefore minimize the risk of using DC- enabled end-entity certificates where a signature forgery oracle may

Addresses GENART "default" comment.
Need to address and directorate reviews.
Correction ARTART editorial are addressed via and .
and .
Looks good Reviewer: Christian Amsüss Review result: Ready with Nits Thanks for this well-written document ART topics: The document does not touch on any of the typical ART review issues; times are relative in well understood units, and versioning, formal language (ASN.1, which is outside of my experience to check) and encoding infrastructure (struct) follows TLS practices. General comments: The introduction of this mechanism gives the impression of a band-aid applied to a PKI ecosystem that has accumulated many limitations as outlined in section The present solution appears good, but if there is ongoing work on the underlying issues (even experimentally), I'd appreciate a careful reference to it. Section 7.6 hints at the front end querying the back-end for creation of new DCs -- other than that, DC distribution (neither push- nor pull-based) is discussed. If there are any mechanisms brewing, I'd appreciate a reference as well. Please check: The IANA considerations list "delegated_credential" for CH, CR and CT messages. I did not find a reference in the text for Ct, only for CH and CR. Editorial comments: (p5) "result for the peer.." -- extraneous period. (p9, p15, p16) The "7 days" are introduced as the default for a profilable prarameter, but later used without further comment.
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-subcerts-?? Reviewer: Elwyn Davies Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Just a few editrial level nits. Major issues: None Minor issues: None. Nits/editorial comments: Abstract: The exact form of the abbreviation (D)TLS is not in the set of well-known abbreviations. I assume it is supposed to mean DTLS or TLS - This ought to be expanded on first use. Abstract: s/mechanism to to/mechanism to/ s1, para 2: CA is used before its expansion in para 3. s1, next to last para: "this document proposes" Hopefully when it becomes an RFC it will do more than propose. Suggest "this document introduces". s1, next to last para: "to speak for names" sounds a bit anthropomorphic to me, but I can't think of a simple alternative word. s1, last para: s/We will refer/This document refers/ [Not an academic paper!] s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ s4, definition of expectedcertverify_algorithm: " Only signature algorithms allowed for use in CertificateVerify message are allowed." Does this need a reference to the place where the list of such algorithms is recorded? s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated credentials sent as extensions to any other certificate." I would have though this ought to be a MUST. There is an equivalent in s4.1.2. I am not sure what the client/server might do if it doesn't ignore the DC. s4.1.3, para 1: s/same way that is done/same way that it is done/ s4.2, para 1: s/We define/This docuent defines/ sS/s5.1: RFC conventions prefer not to have sections empty of text: Add something like: "The following operational consideration should be taken into consideration when using Delegated Certificates:"

notBefore value, after which the delegated credential is no longer valid.  Endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in client-  <ins> and-server-behavior) based on the default (see solution-overview. </ins> The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be 7.5.  <ins> Delegated credentials can be valid for 7 days (by default) and it is much easier for a service to create delegated credentials than a certificate signed by a CA.  A service could determine the client time and clock skew by creating several delegated credentials with different expiry timestamps and observing whether the client would accept it.  Client time could be unique and thus privacy sensitive clients, such as browsers in incognito mode, who do not trust the service might not want to advertise support for delegated credentials or limit the number of probes that a server can perform. </ins> 7.6. allow forging a signature over a delegated credential.  The forged delegated credential could then be used by the attacker as the equivalent of a man-in-the-middle certificate, valid for a maximum of  <ins> 7 days (if the default valid_time is used). </ins> Server operators should therefore minimize the risk of using DC- enabled end-entity certificates where a signature forgery oracle may


Abstract <del> The organizational separation between the operator of a (D)TLS endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority.  This document describes a mechanism to </del>  overcome some of these limitations by enabling operators to delegate <del> their own credentials for use in (D)TLS without breaking </del>  compatibility with peers that do not support this specification. 1. may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently <del> than long-lived certificates.  If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the TLS-fronted service. </del>  Typically, a (D)TLS server uses a certificate provided by some entity <del> other than the operator of the server (a "Certification Authority" or CA) RFC8446 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </del>  Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. public key, which can limit the set of (D)TLS signature schemes usable by the server operator. <del> To reduce the dependency on external CAs, this document proposes a </del>  limited delegation mechanism that allows a (D)TLS peer to issue its own credentials within the scope of a certificate issued by an external CA.  These credentials only enable the recipient of the algorithms such as Ed25519 RFC8032 even if their CA does not support them. <del> We will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". </del>  2. the properties differ from the leaf certificate.  Proxy certificates can be useful in controlled environments, but remain a risk in scenarios where the additional flexibility they provide <del> are not necessary.  For this reason, delegated credentials have </del>  very restricted semantics that should not conflict with X.509 semantics. On receiving a delegated credential and certificate chain, the peer validates the certificate chain and matches the end-entity <del> certificate to the peer's expected identity in the same way that is done when delegated credentials are not in use.  It then performs the following checks with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time: </del>  Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time 4.2. <del> We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials.  What follows is the ASN.1 X.680 for the DelegationUsage certificate extension. </del>  The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  An endpoint MUST NOT accept a delegated credential unless 5.  5.1. One of the risks of deploying a short-lived credential system based 7.  7.1. Delegated credentials limit the exposure of the private key used in a

Need to address and directorate reviews.
Correction ARTART editorial are addressed via and .
and .
Looks good Reviewer: Christian Amsüss Review result: Ready with Nits Thanks for this well-written document ART topics: The document does not touch on any of the typical ART review issues; times are relative in well understood units, and versioning, formal language (ASN.1, which is outside of my experience to check) and encoding infrastructure (struct) follows TLS practices. General comments: The introduction of this mechanism gives the impression of a band-aid applied to a PKI ecosystem that has accumulated many limitations as outlined in section The present solution appears good, but if there is ongoing work on the underlying issues (even experimentally), I'd appreciate a careful reference to it. Section 7.6 hints at the front end querying the back-end for creation of new DCs -- other than that, DC distribution (neither push- nor pull-based) is discussed. If there are any mechanisms brewing, I'd appreciate a reference as well. Please check: The IANA considerations list "delegated_credential" for CH, CR and CT messages. I did not find a reference in the text for Ct, only for CH and CR. Editorial comments: (p5) "result for the peer.." -- extraneous period. (p9, p15, p16) The "7 days" are introduced as the default for a profilable prarameter, but later used without further comment.
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-subcerts-?? Reviewer: Elwyn Davies Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Just a few editrial level nits. Major issues: None Minor issues: None. Nits/editorial comments: Abstract: The exact form of the abbreviation (D)TLS is not in the set of well-known abbreviations. I assume it is supposed to mean DTLS or TLS - This ought to be expanded on first use. Abstract: s/mechanism to to/mechanism to/ s1, para 2: CA is used before its expansion in para 3. s1, next to last para: "this document proposes" Hopefully when it becomes an RFC it will do more than propose. Suggest "this document introduces". s1, next to last para: "to speak for names" sounds a bit anthropomorphic to me, but I can't think of a simple alternative word. s1, last para: s/We will refer/This document refers/ [Not an academic paper!] s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ s4, definition of expectedcertverify_algorithm: " Only signature algorithms allowed for use in CertificateVerify message are allowed." Does this need a reference to the place where the list of such algorithms is recorded? s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated credentials sent as extensions to any other certificate." I would have though this ought to be a MUST. There is an equivalent in s4.1.2. I am not sure what the client/server might do if it doesn't ignore the DC. s4.1.3, para 1: s/same way that is done/same way that it is done/ s4.2, para 1: s/We define/This docuent defines/ sS/s5.1: RFC conventions prefer not to have sections empty of text: Add something like: "The following operational consideration should be taken into consideration when using Delegated Certificates:"

Abstract  <ins> The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority.  This document describes a mechanism to to </ins> overcome some of these limitations by enabling operators to delegate  <ins> their own credentials for use in TLS and DTLS without breaking </ins> compatibility with peers that do not support this specification. 1. may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently  <ins> than long-lived certificates.  If an external Certification Authority (CA) is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients.  With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the TLS-fronted service. </ins> Typically, a (D)TLS server uses a certificate provided by some entity  <ins> other than the operator of the server (a CA) RFC8446 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </ins> Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. public key, which can limit the set of (D)TLS signature schemes usable by the server operator.  <ins> To reduce the dependency on external CAs, this document specifies a </ins> limited delegation mechanism that allows a (D)TLS peer to issue its own credentials within the scope of a certificate issued by an external CA.  These credentials only enable the recipient of the algorithms such as Ed25519 RFC8032 even if their CA does not support them.  <ins> This document refers to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". </ins> 2. the properties differ from the leaf certificate.  Proxy certificates can be useful in controlled environments, but remain a risk in scenarios where the additional flexibility they provide  <ins> is not necessary.  For this reason, delegated credentials have </ins> very restricted semantics that should not conflict with X.509 semantics. On receiving a delegated credential and certificate chain, the peer validates the certificate chain and matches the end-entity  <ins> certificate to the peer's expected identity in the same way that it is done when delegated credentials are not in use.  It then performs the following checks with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time: </ins> Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time 4.2.  <ins> This documnt defines a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials.  What follows is the ASN.1 X.680 for the DelegationUsage certificate extension. </ins> The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  An endpoint MUST NOT accept a delegated credential unless 5. <ins> The operational consideration documented in this section should be taken into consideration when using Delegated Certificates. </ins> 5.1. One of the risks of deploying a short-lived credential system based 7. <ins> The security consideration documented in this section should be taken into consideration when using Delegated Certificates. </ins> 7.1. Delegated credentials limit the exposure of the private key used in a


The Credential structure as previously defined. <del> The signature algorithm used to verify </del>  DelegatedCredential.signature. The delegation, a signature that binds the credential to the end- The signature of the DelegatedCredential is computed over the concatenation of: <del> A string that consists of octet 32 (0x20) repeated 64 times. </del>  <del> The context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication. </del>  <del> A single 0 byte, which serves as the separator. </del>  The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. 4.1.1. <del> A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello.  The body of the extension consists of a SignatureSchemeList (defined in RFC8446): </del>  If the client receives a delegated credential without having indicated support in its ClientHello, then the client MUST abort the If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send <del> a delegated credential.  The server MUST ignore the extension unless (D)TLS 1.3 or a later version is negotiated.  An example of when a server could choose not to send a delegated credential is when the </del>  SignatureSchemes listed only contain signature schemes for which a corresponding delegated credential does not exist or are otherwise unsuitable for the connection. The algorithm field MUST be of a type advertised by the client in the "signature_algorithms" extension of the ClientHello message and the <del> expected_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and is considered invalid </del>  otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. If the extension is present, the client MAY send a delegated credential; if the extension is not present, the client MUST NOT send <del> a delegated credential.  The client MUST ignore the extension unless (D)TLS 1.3 or a later version is negotiated. </del>  <del> The client MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the server SHOULD ignore delegated credentials sent as extensions to any other certificate. </del>  The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message <del> and the expected_cert_verify_algorithm field MUST be of a type advertised by the server in the SignatureSchemeList and is considered invalid otherwise.  Servers that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </del>  4.1.3. asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days by default). <del> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials. </del>  Verify that the end-entity certificate satisfies the conditions in certificate-requirements.

Paul provided an AD review that can be found .
Addressed via . As this document already saw an AD review by Ben Kaduk, I will not further hold up this document. Ben's write up can be found at: URL Please treat the below as you would treat any other comments. Test vectors available but still not included - did these get verified ? Can these be included? expectedcertverifyalgorithm - why is this not called dccertverifyalgorithm or dcverifyalgorithm ? As in, why is there an "expected" prefix? We talk about signaturealgorithms and not expectedsignaturealgorithms ? algorithm: The signature algorithm used to verify DelegatedCredential.signature. This reads weird. If the signature algorithm is "used", it was to create the signature. The verification is in the future though. Perhaps say "The signature algorithm used to create the DelegatedCredential.signature" A string that consists of octet 32 (0x20) repeated 64 times. Why is there a 64 spaces prefix ? Should it say a non-null terminated string? Or perhaps "octet stream" instead of "string" ? The context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication. Same here, non-null terminated string? A single 0 byte, which serves as the separator. a few lines up it used hex notation for 0x20 and named it octet. Should this be called a single octet of value 0x00 ? A client which supports this specification SHALL send a "delegatedcredential" extension in its ClientHello. This oddly means that a client that supports this cannot really choose to not use it. Normally, this is more written as "A client that is willing to use DC includes a "delegatedcredential" extension in its ClientHello" If the client receives a delegated credential without having indicated support in its ClientHello According to the above, this "SHALL" not happen because to recognise the extension it needs to support it and if it supports it, it SHALL send it :) The server MUST ignore the extension unless (D)TLS 1.3 or a later version is negotiated. That is oddly phrased as a MUST with an exception (which is really a SHOULD) Perhaps: "When a (D)TLS version negotiated is less than 1.3, the server MUST ignore this extension" The client MUST ignore the extension unless (D)TLS 1.3 or a later version is negotiated. Same here. The server MUST send the delegated credential Should that be "delegatedcredential", eg underscore instead of space? Or use DC ? the server SHOULD ignore delegated credentials sent as extensions to any other certificate. Why is the case a "SHOULD ignore" where all the other cases of unexpected DC uses "MUST " ? I'm a little confused by Section 7.4. Interactions with Session Resumption. The session resumption uses a seperate continue mechanism that omits needing to re-authenticate the peer. It has its own session ticket lifetimes to keep its state. Why is that mechanism on its own not enough? If the server still has the session state why would a valid DC be a requirement to use an existing ticket? Or phrased differently, one could say that a session resumption ticket lifetime should never fall outside the DC validity period (if that is what you want to enforce, but I'm not sure that is what you want or should do). NITS: Please fix nits as per genart review: URL Paul

The Credential structure as previously defined.  <ins> The signature algorithm used to create </ins> DelegatedCredential.signature. The delegation, a signature that binds the credential to the end- The signature of the DelegatedCredential is computed over the concatenation of:  <ins> An octet stream that consists of octet 32 (0x20) repeated 64 times. </ins>  <ins> The non-null terminated context string "TLS, server delegated credentials" for server authentication and "TLS, client delegated credentials" for client authentication. </ins>  <ins> A single octet 0x00, which serves as the separator. </ins> The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. 4.1.1.  <ins> A client that is willing to use delegated credentials in a connection SHALL send a "delegated_credential" extension in its ClientHello. The body of the extension consists of a SignatureSchemeList (defined in RFC8446): </ins> If the client receives a delegated credential without having indicated support in its ClientHello, then the client MUST abort the If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send  <ins> a delegated credential.  When a (D)TLS version negotiated is less than 1.3, the server MUST ignore this extension.  An example of when a server could choose not to send a delegated credential is when the </ins> SignatureSchemes listed only contain signature schemes for which a corresponding delegated credential does not exist or are otherwise unsuitable for the connection. The algorithm field MUST be of a type advertised by the client in the "signature_algorithms" extension of the ClientHello message and the  <ins> dc_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and is considered invalid </ins> otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. If the extension is present, the client MAY send a delegated credential; if the extension is not present, the client MUST NOT send  <ins> a delegated credential.  When a (D)TLS version negotiated is less than 1.3, the client MUST ignore this extension. </ins>  <ins> The client MUST send the DC as an extension in the CertificateEntry of its end-entity certificate; the server SHOULD ignore delegated credentials sent as extensions to any other certificate. </ins> The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message  <ins> and the dc_cert_verify_algorithm field MUST be of a type advertised by the server in the SignatureSchemeList and is considered invalid otherwise.  Servers that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </ins> 4.1.3. asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days by default).  <ins> Verify that dc_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials. </ins> Verify that the end-entity certificate satisfies the conditions in certificate-requirements.


Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or <del> CA) RFC5246 RFC5280.  This organizational separation makes the TLS </del>  server operator dependent on the CA for some aspects of its operations, for example: draft-02 <del> Change public key type (*) </del>  <del> Change DelegationUsage extension to be NULL. </del>  Drop support for TLS 1.2. is no longer valid. The signature algorithm of the credential key pair, where the type <del> SignatureScheme is as defined in the TLS 1.3 standard.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </del>  The version of TLS in which the credential will be used, where the <del> type ProtocolVersion is as defined in TLS 1.3.  This is expected </del>  to match the protocol version that is negotiated by the client and server.

The suggested OID for the DelegationUsage extension will be 1.3.6.1.4.1.44363.44.

Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or  <ins> CA) RFC8446 RFC5280.  This organizational separation makes the TLS </ins> server operator dependent on the CA for some aspects of its operations, for example: draft-02  <ins> Change public key type. (*) </ins>  <ins> Change DelegationUsage extension to be NULL and define its object identifier. </ins> Drop support for TLS 1.2. is no longer valid. The signature algorithm of the credential key pair, where the type  <ins> SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </ins> The version of TLS in which the credential will be used, where the  <ins> type ProtocolVersion is as defined in RFC8446.  This is expected </ins> to match the protocol version that is negotiated by the client and server.


Abstract The organizational separation between the operator of a TLS server <del> and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms.  This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking </del>  compatibility with clients that do not support this specification. 1. "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential".  2. A delegated credential is a digitally signed data structure with two <del> semantic fields: a validity interval, and a public key (with its associated algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential is presumed to be one whose corresponding public key is contained in an X.509 certificate that associates one or more names to the credential. </del>  A TLS handshake that uses credentials differs from a normal handshake in a few important ways: support for this mechanism. The server provides both the certificate chain terminating in its <del> certificate as well as the credential. </del>  The client uses information in the server's certificate to verify <del> the signature on the credential and verify that the server is asserting an expected identity. </del>  The client uses the public key in the credential as the server's working key for the TLS handshake. <del> This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </del>  It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509 <del> that permits use of delegated credentials.  Clients MUST NOT accept delegated credentials associated with certificates without this extension. Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself.  To limit the exposure of a delegation credential compromise, servers MUST NOT issue credentials with a validity period longer than 7 days.  Clients MUST NOT accept credentials with longer validity periods. </del>  2.1. layer. X.509 semantics are very rich.  This can cause unintended <del> consequences if a service owner creates a proxy cert where the properties differ from the leaf certificate.  For this reason, </del>  delegated credentials have very restricted semantics which should not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the <del> server certificate.  Since the cert path building process is not cryptographically protected, it is possible that a proxy </del>  certificate could be bound to another certificate with the same public key, with different X.509 parameters.  Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. <del> Delegated credentials are bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </del>  2.2. 3. <del> This document defines the following extension code point. A client which supports this document SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential extension; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.3 or later is negotiated. The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate. The delegated credential contains a signature from the public key in the end-entity certificate using a signature algorithm advertised by the client in the "signature_algorithms" extension.  Additionally, the credential's public key MUST be of a type that enables at least one of the supported signature algorithms.  A delegated credential MUST NOT be negotiated by the server if its signature is not compatible with any of the supported signature algorithms or the credential's public key is not usable with the supported signature algorithms of the client, even if the client advertises support for delegated credentials. The SignatureScheme the server selects in the "signature_algorithms" extension MUST be that of the credential public key.  On receiving a credential and a certificate chain, the client validates the certificate chain and matches the end-entity certificate to the server's expected identity following its normal procedures.  It then takes the following steps: Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more than 7 days. Verify that the end-entity certificate satisfies the conditions specified in Section certificate-requirements. Use the public key in the server's end-entity certificate to verify the signature of the credential. If one or more of these checks fail, then the delegated credential is deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to verify the signature in the serer's CertificateVerify message. 4. </del> While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the <del> digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </del>  structure: Relative time in seconds from the beginning of the delegation is no longer valid. The signature algorithm of the credential key pair, where the type <del> SignatureScheme is as defined in the TLS 1.3 standard. </del>  The version of TLS in which the credential will be used, where the <del> type ProtocolVersion is as defined in TLS 1.3. </del>  <del> The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280. </del>  The delegated credential has the following structure: <del> The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard. </del>  The signature over the credential with the end-entity certificate's public key, using the scheme. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. <del> DelegatedCredential.cred. </del>  DelegatedCredential.scheme. the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their <del> semantics in this way is intended to mitigate thee risk of cross </del>  protocol attacks involving delegated credentials. The code changes to create and verify delegated credentials would be changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack). <del> 4.1. </del>  We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials. <del> The client MUST NOT accept a delegated credential unless the server's end-entity certificate satisfies the following criteria: </del>  It has the DelegationUsage extension. <del> It has the digitalSignature key usage enabled (see the Keyusage type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. The extension MAY be marked crititcal.  (See Section 4.2 of RFC5280.) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an "illegal_parameter" alert. </del>  <del> 5. </del>  TBD <del> 6. 6.1. Marking the delegation certificate's DelegationUsage extension non- critical allows the certificate to be used for clients that do not support delegated credentials.  However, it may be desirable to ensure that the delegation certificate is only used in handshakes in which a delegated credential negotiated.  It suffices to mark the extension crticial and set the strict boolean to true: if the client does not support delegated credentials, then it will abort the handshake if the certificate has the DelegationUsage extension (as per Section 4.2 of RFC5280); if the client indicates support, but the server does not offer a delegated credential, then the client will abort the handshake (as per certificate-requirements). </del>  <del> 6.2. </del>  Delegated credentials limit the exposure of the TLS private key by limiting its validity.  An attacker who compromises the private key access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. <del> 6.3. </del>  Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated credential would revoke the credential.  Revocation of the long term <del> private key that signs the delegated credential also implictly </del>  revokes the delegated credential. <del> 6.4. </del>  Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate

Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me

Abstract The organizational separation between the operator of a TLS server  <ins> and the certificate authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certificate authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking </ins> compatibility with clients that do not support this specification. 1. "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential". <ins> 1.1. (*) indicates changes to the wire protocol. draft-02 Change DelegationUsage extension to be NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. (*) Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate. </ins> 2. A delegated credential is a digitally signed data structure with two  <ins> semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential corresponds to the public key of the X.509 end-entity certificate. </ins> A TLS handshake that uses credentials differs from a normal handshake in a few important ways: support for this mechanism. The server provides both the certificate chain terminating in its  <ins> certificate as well as the delegated credential. </ins> The client uses information in the server's certificate to verify  <ins> the delegated credential and that the server is asserting an expected identity. </ins> The client uses the public key in the credential as the server's working key for the TLS handshake.  <ins> As detailed in delegated-credentials, the delegated credential is cryptographically bound to the end-entity certificate and the protocol in which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there is no mechanism for revoking it without revoking the certificate itself.  To limit exposure in case a delegated credential is compromised, servers may not issue credentials with a validity period longer than 7 days.  This mechanism is described in detail in client- and-server-behavior. </ins> It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509  <ins> that permits use of delegated credentials.  (See certificate- requirements.) </ins> 2.1. layer. X.509 semantics are very rich.  This can cause unintended  <ins> consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate.  For this reason, </ins> delegated credentials have very restricted semantics which should not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the  <ins> server certificate.  Since the certificate path building process is not cryptographically protected, it is possible that a proxy </ins> certificate could be bound to another certificate with the same public key, with different X.509 parameters.  Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot.  <ins> Each delegated credential is bound to a specific version of TLS and signature algorithm.  This prevents them from being used for other protocols or with other signature algorithms than service owner allows. </ins> 2.2. 3.  While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the  <ins> digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation is no longer valid. The signature algorithm of the credential key pair, where the type  <ins> SignatureScheme is as defined in the TLS 1.3 standard.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </ins> The version of TLS in which the credential will be used, where the  <ins> type ProtocolVersion is as defined in TLS 1.3.  This is expected to match the protocol version that is negotiated by the client and server. </ins>  <ins> The credential's public key, a DER-encoded SubjectPublicKeyInfo as defined in RFC5280. </ins> The delegated credential has the following structure:  <ins> The signature algorithm used to verify DelegatedCredential.signature. </ins> The signature over the credential with the end-entity certificate's public key, using the scheme. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.  <ins> DelegatedCredential.algorithm. </ins> DelegatedCredential.scheme. the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their  <ins> semantics in this way is intended to mitigate the risk of cross </ins> protocol attacks involving delegated credentials. The code changes to create and verify delegated credentials would be changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack).  <ins> 3.1. This document defines the following extension code point. A client which supports this specification SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.3 or a later version is negotiated. The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a type advertised by the client in the "signature_algorithms" extension.  A delegated credential MUST NOT be negotiated otherwise, even if the client advertises support for delegated credentials. On receiving a delegated credential and a certificate chain, the client validates the certificate chain and matches the end-entity certificate to the server's expected identity following its normal procedures.  It also takes the following steps: Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more than 7 days. Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. Verify that expected_version matches the protocol version indicated in the server's "supported_versions" extension. Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements. Use the public key in the server's end-entity certificate to verify the signature of the credential using the algorithm indicated by DelegatedCredential.algorithm. If one or more of these checks fail, then the delegated credential is deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to verify the signature in the server's CertificateVerify message. 3.2. </ins> We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated credentials.  <ins> The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  The client MUST NOT accept a delegated credential unless the server's end-entity certificate satisfies the following criteria: </ins> It has the DelegationUsage extension.  <ins> It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280). </ins>  <ins> 4. </ins> TBD  <ins> 5. </ins>  <ins> 5.1. </ins> Delegated credentials limit the exposure of the TLS private key by limiting its validity.  An attacker who compromises the private key access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules.  <ins> 5.2. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated credential would revoke the credential.  Revocation of the long term  <ins> private key that signs the delegated credential also implicitly </ins> revokes the delegated credential.  <ins> 5.3. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate


operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely <del> on an external CA for such short-lived credentials.  In contrast to OCSP stapling, in which an operator could choose to talk to the CA frequently to obtain stapled responses, failure to fetch an OCSP stapled response results only in degraded performance, however </del>  failure to fetch a potentially large number of short lived certificates would result in the service not being available which creates greater operational risk. A public key (with its associated algorithm) The signature on the credential indicates a delegation from the <del> certificate which is issued to the TLS server operator.  The key pair used to sign a credential is presumed to be one whose public key is contained in an X.509 certificate that associates one or more names to the credential. </del>  A TLS handshake that uses credentials differs from a normal handshake in a few important ways: signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509 <del> which permits use of delegated credentials.  Clients MUST NOT accept </del>  delegated credentials associated with certificates without this extension. credentials, which rely on a cryptographic binding between the entire certificate and the Delegated credential, cannot. <del> Delegated credentials allow signed messages to be bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </del>  2.2. figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13. <del> These two classes of mechanism can be complementary.  A server could use credentials for clients that support them, while using LURK to </del>  support legacy clients. It is possible to address the short-lived certificate concerns above procedures.  It then takes the following additional steps: Verify that the current time is within the validity interval of <del> the credential. </del>  Use the public key in the server's end-entity certificate to verify the signature on the credential. provided in the handshake.  That is the CertificateVerify message in TLS 1.3 or ServerKeyExchange in 1.2. <del> Verify that the certificate has the correct extensions that allow the use of Delegated credentials. </del>  <del> Clients that receive Delegated credentials that are valid for more than 7 days MUST terminate the connection with an "illegal_parameter" alert. </del>  4. DelegationUsage ::= BIT STRING { allowed (0) } <del> Conforming CAs MUST mark this extension as non-critical.  This would allow the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </del>  5.

This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes

operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely  <ins> on an external CA for such short-lived credentials.  In OCSP stapling, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance.  On the other hand, </ins> failure to fetch a potentially large number of short lived certificates would result in the service not being available which creates greater operational risk. A public key (with its associated algorithm) The signature on the credential indicates a delegation from the  <ins> certificate that is issued to the TLS server operator.  The secret key used to sign a credential is presumed to be one whose corresponding public key is contained in an X.509 certificate that associates one or more names to the credential. </ins> A TLS handshake that uses credentials differs from a normal handshake in a few important ways: signatures for certificates that contain the keyEncipherment KeyUsage (RFC5280 section 4.2.1.3) In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509  <ins> that permits use of delegated credentials.  Clients MUST NOT accept </ins> delegated credentials associated with certificates without this extension. credentials, which rely on a cryptographic binding between the entire certificate and the Delegated credential, cannot.  <ins> Delegated credentials are bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </ins> 2.2. figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13.  <ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to </ins> support legacy clients. It is possible to address the short-lived certificate concerns above procedures.  It then takes the following additional steps: Verify that the current time is within the validity interval of  <ins> the credential and that the credential's time to live is no more than 7 days. </ins> Use the public key in the server's end-entity certificate to verify the signature on the credential. provided in the handshake.  That is the CertificateVerify message in TLS 1.3 or ServerKeyExchange in 1.2.  <ins> Verify that the certificate has the DelegationUsage extension, which permits the use of Delegated credentials. </ins>  <ins> If one or more of these criteria are not met, then the Delegated credential is invalid.  Clients that receive Delegated credentials that are invalid MUST terminate the connection with an "illegal_parameter" alert. </ins> 4. DelegationUsage ::= BIT STRING { allowed (0) }  <ins> Conforming CAs MUST mark this extension as non-critical.  This allows the certificate to be used by service owners for clients that do not support certificate delegation as well and not need to obtain two certificates. </ins> 5.


(*) indicates changes to the wire protocol.  draft-02 Change public key type. (*) working key for the TLS handshake. As detailed in delegated-credentials, the delegated credential is <del> cryptographically bound to the end-entity certificate and the protocol in which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </del>  Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. <del> Each delegated credential is bound to a specific version of TLS and signature algorithm.  This prevents them from being used for other protocols or with other signature algorithms than service owner allows. </del>  2.2. SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server. <del> The version of TLS in which the credential will be used, where the type ProtocolVersion is as defined in RFC8446.  This is expected to match the protocol version that is negotiated by the client and server. </del> The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that <del> credentials are only used with the certificate, protocol, and signature algorithm chosen by the delegator.  Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. </del>  The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. <del> Verify that expected_version matches the protocol version indicated in the server's "supported_versions" extension. </del> Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements.

As discussed in URL and subsequent.
I have responded to the two comments. No idea why CI is busted.
looks like the CI segfaulted :) I'll manually test locally and merge
Please add yourself to acknowledgements as well. remove change in line 192 as well "Each delegated credential is bound to a specific version of TLS and signature". somehow i cant comment on changes that you haven't made. Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson

(*) indicates changes to the wire protocol. <ins> draft-03 Remove protocol version from the Credential structure. (*) </ins> draft-02 Change public key type. (*) working key for the TLS handshake. As detailed in delegated-credentials, the delegated credential is  <ins> cryptographically bound to the end-entity certificate with which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </ins> Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot.  <ins> Each delegated credential is bound to a specific signature algorithm.  This prevents them from being used with other, unintended, signature algorithms. </ins> 2.2. SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server.  The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that  <ins> credentials are only used with the certificate and signature algorithm chosen by the delegator.  Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. </ins> The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message.  Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements.


the delegation to speak for names that the CA has authorized.  For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the <del> operator as a "delegated credential". </del>  1.1. cryptographically bound to the end-entity certificate with which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the <del> protocol is explicitly disallowed. </del>  Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate.  For this reason, <del> delegated credentials have very restricted semantics which should </del>  not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm.  This prevents them from being used with other, unintended, signature algorithms. </del>  2.2. private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with <del> TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials. </del>  These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance <del> APIs like ACME may be useful for provisioning credentials, within an </del>  operator network. 3. The signature algorithm used to verify DelegatedCredential.signature. <del> The signature over the credential with the end-entity certificate's public key, using the scheme. </del>  The signature of the DelegatedCredential is computed over the concatenation of: this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials. <del> The code changes to create and verify delegated credentials would be localized to the TLS stack, which has the advantage of avoiding changes to security-critical and often delicate PKI code (though of course moves that complexity to the TLS stack). </del>  3.1. On receiving a delegated credential and a certificate chain, the client validates the certificate chain and matches the end-entity <del> certificate to the server's expected identity following its normal procedures.  It also takes the following steps: </del>  Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more <del> than 7 days. </del>  Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message. <del> Verify that the end-entity certificate satisfies the conditions specified in certificate-requirements. </del>  Use the public key in the server's end-entity certificate to verify the signature of the credential using the algorithm limiting its validity.  An attacker who compromises the private key of a delegated credential can act as a man in the middle until the delegate credential expires, however they cannot create new delegated <del> credentials.  Thus delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between </del>  parties that have some trust relationship with each other.  The secrecy of the delegated private key is thus important and several <del> access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. </del>  5.2.

No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM

the delegation to speak for names that the CA has authorized.  For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the  <ins> operator as a "delegated credential" or "DC". </ins> 1.1. cryptographically bound to the end-entity certificate with which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the  <ins> protocol is not allowed. </ins> Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate.  For this reason,  <ins> delegated credentials have very restricted semantics that should </ins> not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature  <ins> algorithm that may be used to sign the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </ins> 2.2. private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with  <ins> TLS 1.3 I-D.ietf-tls-tls13. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance  <ins> APIs like ACME may be useful for provisioning credentials within an </ins> operator network. 3. The signature algorithm used to verify DelegatedCredential.signature.  <ins> The delegation, a signature that binds the credential to the end- entity certificate's public key as specified below.  The signature scheme is specified by DelegatedCredential.algorithm. </ins> The signature of the DelegatedCredential is computed over the concatenation of: this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials.  <ins> The code changes required in order to create and verify delegated credentials, and the implementation complexity this entails, are localized to the TLS stack.  This has the advantage of avoiding changes to security-critical and often delicate PKI code. </ins> 3.1. On receiving a delegated credential and a certificate chain, the client validates the certificate chain and matches the end-entity  <ins> certificate to the server's expected identity in the usual way.  It also takes the following steps: </ins> Verify that the current time is within the validity interval of the credential and that the credential's time to live is no more  <ins> than 7 days.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the server's CertificateVerify message.  <ins> Verify that the end-entity certificate satisfies the conditions in certificate-requirements. </ins> Use the public key in the server's end-entity certificate to verify the signature of the credential using the algorithm limiting its validity.  An attacker who compromises the private key of a delegated credential can act as a man in the middle until the delegate credential expires, however they cannot create new delegated  <ins> credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between </ins> parties that have some trust relationship with each other.  The secrecy of the delegated private key is thus important and several  <ins> access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </ins> 5.2.


These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low- <del> trust zones such as CDNs or remote data centers.  This allows server operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross- organizational transactions makes it operationally infeasible to rely on an external CA for such short-lived credentials.  In OCSP stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </del>  To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the peer.  The secret key used to sign a credential corresponds to the <del> public key of the peer's X.509 end-entity certificate. </del>  A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways: these two mechanisms with TLS 1.3 RFC8446. These two mechanisms can be complementary.  A server could use <del> credentials for clients that support them, while using LURK to </del>  support legacy clients. It is possible to address the short-lived certificate concerns above <del> by automating certificate issuance, e.g., with ACME RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </del>  3. While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the <del> digitalSignature KeyUsage (RFC 5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </del>  structure: Relative time in seconds from the beginning of the delegation 3.1. <del> This document defines the following extension code point. </del>  3.1.1.

Updating x690 version to match TLS1.2 (2015) Expanding acronyms (avoid genart) removed "!" from some refs (unneded) r/LURK/KEYLESS (completes derference from earlier PR).

These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low-  <ins> trust zones such as Content Delivery Network (CDNs) or remote data centers.  This allows server operators to limit the exposure of keys in cases that they do not realize a compromise has occurred.  The risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  In Online Certiicate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension types ocsp RFC6066 or ocsp_multi RFC6961), if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance. On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </ins> To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the peer.  The secret key used to sign a credential corresponds to the  <ins> public key of the peer's X.509 end-entity certificate RFC5280. </ins> A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways: these two mechanisms with TLS 1.3 RFC8446. These two mechanisms can be complementary.  A server could use  <ins> credentials for clients that support them, while using KEYLESS to </ins> support legacy clients. It is possible to address the short-lived certificate concerns above  <ins> by automating certificate issuance, e.g., with Automated Certificate Managmeent Encvironment (ACME) RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </ins> 3. While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is perfectly fine to use them to issue other signed objects as long as the certificate contains the  <ins> digitalSignature KeyUsage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation 3.1.  <ins> This document defines the following TLS extension code point. </ins> 3.1.1.


We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated <del> credentials. </del>  The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  The client MUST NOT accept a delegated credential unless it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.  5. 5.1.

I suspect at some point somebody would have asked for an ASN.1 module. I know not everybody uses an ASN.1 compiler, but some do. I also know Russ Housley was going through an making for all of the RFCs that include ASN.1. He also double checked that the ASN.1 module compiles (if you put a dummy OID in for the TBD it will compile). An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections.
"An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections." Are you thinking of getting a different OID for the DCs, does the cf OID not work?
Sean is talking about the Module Identifier. The CF OID inside the module is fine.
The CF OID for the extension works just fine - in fact I should have left the sentence in the PR explaining that. We need an OID for the ASN.1 module (TBD). Technically, I guess we do not need an OID if CF has an ASN.1 module already. But, I suspect there wasn't an ASN.1 module. Make sense?
NAME do you know if CF has an ASN.1 module already?
since noone seems to have any objections, merging away.
Not having an ASN.1 module for the certificate extension has bit us in the a** before. I will make one and add it in as an appendix.

We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated  <ins> credentials.  What follows is the ASN.1 X680 for the DelegationUsage certificate extension. </ins> The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  The client MUST NOT accept a delegated credential unless it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446. <ins> This document also defines an ASN.1 module for the DelegationUsage certificate extension in module.  IANA is requested to register an Object Identfiier (OID) for the ASN.1 in "SMI Security for PKIX Module Identifier" arc.  An OID for the DelegationUsage certificate extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. </ins> 5. 5.1.