Original text:
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

Reviewer comments:
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:"

Revised text:
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