jiebi/CodeConvo huggingface dataset:
Change:
The suggested OID for the DelegationUsage extension will be 1.3.6.1.4.1.44363.44.

Discussion:
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> <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 <del> Change public key type (*) </del> <ins> Change public key type. (*) </ins> <del> Change DelegationUsage extension to be NULL. </del> <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 <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> <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 <del> type ProtocolVersion is as defined in TLS 1.3.  This is expected </del> <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.
Change:
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.

Discussion:
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> <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.
Change:
Fix formatting issue in changes.
This is trivial and straightforward change so I'm just going to merge this directly.

Discussion:
(*) indicates changes to the wire protocol. <del> draft-05 * Removed support for PKCS 1.5 RSA signature algorithms.  * Additional security considerations. </del> <ins> draft-05 Removed support for PKCS 1.5 RSA signature algorithms. Additional security considerations. </ins> draft-04
Change:
Hearing no objections on the list, merging this in. NAME can you please spin a new version for WGLC?
Allow the client to send a list of signature schemes that are supported in a delegated credential handshake.
Fixed by .

Discussion:
3.1.1. <del> 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. </del> <ins> A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello.  The body of the extension consists of a SignatureSchemeList: If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send

certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a <del> type advertised by the client in the "signature_algorithms" extension and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </del> <ins> type advertised by the client in the SignatureSchemeList and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </ins> 3.1.2.
Change:
Currently the codepoint is TBD
NAME does one know what we need to get a code point.
NAME if we want one early, we can kick that process off. If not we wait for it to be assigned later in the process.
I think we need an early one. It's not possible yet to implement this to evaluate in various scenarios. We plan to use delegated credentials in our internal infrastructure and then probably would push the implementation back to open source projects like OpenSSL.
i think a resolution to URL is the only thing that is probably holding back the code point.
NAME can you please start the code point allocation process now that is resolved?

Discussion:
This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" <del> extension has been assigned a code point of TBD.  The IANA registry </del> <ins> extension has been assigned a code point of 34.  The IANA registry </ins> lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.
Change:
These came up when I implemented the extension in Go (URL) and I think would be useful to add to the standard.
looks good to me

Discussion:
This document defines the following extension code point. A client which supports this document SHALL send an empty <del> "delegated_credential" extension in its ClientHello. If the extension is present, the server MAY send a DelegatedCredential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent. When negotiating TLS 1.3, and using Delegated credentials, the server MUST send the DelegatedCredential as an extension in the CertificateEntry of its end-entity certificate.  When negotiating TLS 1.2, the DelegatedCredential MUST be sent as an extension in the ServerHello. The DelegatedCredential contains a signature from the public key in </del> <ins> "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client SHOULD 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 credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, 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 with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. The delegated credential contains a signature from the public key in </ins> 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

than 7 days. Verify that the certificate has the DelegationUsage extension, <del> which permits the use of Delegated credentials. </del> <ins> which permits the use of delegated credentials. </ins> Use the public key in the server's end-entity certificate to verify the signature on the credential.

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 <del> verify a signature provided in the handshake: in particular, the </del> <ins> verify the signature provided in the handshake: in particular, the </ins> CertificateVerify message in TLS 1.3 and the ServerKeyExchange in 1.2.
Change:
Also fixed a few smaller grammatical/punctuation errors. Rationale from the mailing list: I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong, but that isn't really made explicit.I'm not sure what "only" means in "only in degraded performance." Is it "the worst that can happen is just degraded performance" or "it can result only in degraded performance, as opposed to better performance"? At first I thought it was the latter, but after reading the subsequent sentence, I realized it was probably the former.The use of "On the other hand" sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance, which obviously would be silly.

Discussion:
These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low- <del> trust zones such as Content Delivery Network (CDNs) or remote data </del> <ins> trust zones such as Content Delivery Networks (CDNs) or remote data </ins> centers.  This allows server operators to limit the exposure of keys <del> 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 Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446, 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> <ins> in cases where they do not realize a compromise has occurred. However, the risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  For instance, in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446), a CA may fail to deliver OCSP stapled response.  While this will result in degraded performance, the ramifications of failing to deliver short-lived certificates are even worse: the service that depends on those certificates would go down entirely.  Thus, ensuring independence from CAs for short-lived certificates is critical to the uptime of a service. </ins> To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own
Change:
Based on One of the design criteria for this standard is to isolate the TLS with the DC extension from other protocols. In this PR, I propose explicitly restricting the X.509 KeyUsage of the end-entity certificate. This change is made in the last commit: URL The two commits that proceed it don't actually change the semantics of the standard, but clean up the language a bit. If the KeyUsage change isn't adopted, we might consider merging the other two commits.
if it's not too painful, could you move this particular diff above all the others, I think I want to have some more discussion on this one. If its painful, we can just resolve this one first
Done, NAME
looks like i merged this as a result of merging a dependent PR accidentally. This is fine, we can just discuss this before I put up the next draft versions

Discussion:
4.1. <del> We define a new X.509 extension, DelegationUsage to be used in the </del> <ins> We define a new X.509 extension, DelegationUsage, to be used in the </ins> certificate when the certificate permits the usage of delegated credentials.

certificates. The client MUST NOT accept a delegated credential unless the server's <del> end-entity certificate has the DelegationUsage extension. </del> <ins> end-entity certificate satisfies the following criteria: It has the DelegationUsage extension. It has the digitalSignature key usage enabled (see the Keyusage type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. </ins> 5.
Change:
NAME please go ahead and merge after resolving conflicts!
From Martin: The security considerations don't cover the potential for misissuance creating a credential that is as long-lived as the certificate, but they probably should.
NAME I'm not sure what you mean here. Are you talking about explicitly calling out the possibility that the credential may expire after the certificate and that this should be forbidden?
If you are able to access the signing key of the certificate, or are otherwise able to construct a DC, you can create multiple DCs that cover the time from now until the certificate expires. It's not a big deal, but I thought it might be worth noting.
Gotcha. I'll note this.
Closed in

Discussion:
Address case nits <ins> Add text around using an oracle to forge DCs in the future and past </ins> Add text about certificate extension vs EKU draft-08

elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. <ins> Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field.  Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate.  Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate. </ins>
Change:
In section 3, the document says: The secret key used to sign ... Please change "secret" to "private". Later in the sentence, [RFC5280] is referenced, and it talks about "private key" in this context.
Addressed in

Discussion:
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 <del> peer.  The secret key used to sign a credential corresponds to the </del> <ins> peer.  The private key used to sign a credential corresponds to the </ins> public key of the peer's X.509 end-entity certificate RFC5280. A TLS handshake that uses delegated credentials differs from a
Change:
From Russ: I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage. From Watson: One of the hard requirements for our deployment was that the same certificate be useable with DCs and without. A different EKU would be more problematic then an extension for this purpose, and while it might be more or less irritating for implementors depending on how their stack works (sorry Rich - https://boringssl-URL might serve as inspiration, but the client side got dropped for similar issues). We know the extension doesn't bust things, I don't know an EKU would, and the root program issues make me hesitate.
Addressed in

Discussion:
Address case nits <ins> Add text about certificate extension vs EKU </ins> draft-08 Include details about the impact of signature forgery attacks

It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280). <ins> A new extension was chosen instead of adding a new Extended Key Usage (EKU) to be compatible with deployed TLS and PKI software stacks without requiring CAs to issue new intermediate certificates. </ins> 5. This document registers the "delegated_credentials" extension in the
Change:
Based on There is currently no binding of the credential to the signature scheme used to sign the handshake. The field of the encodes the DC public key type; but there's not a one-to-one correspondence between X.509's and TLS . Hence, the TLS terminator could use a signature scheme to sign the handshake other than the scheme intended by the delegator. To prevent this, this PR adds the SignatureScheme that the TLS terminator selects in the "signature_algorithms" extension to scope of the delegation signature. In addition, it makes this and the protocol version explicit parameters of the Credential structure. This is intended to make debugging easier.

Discussion:
make such delegations as long as they only enable the recipient of 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 <del> "certificate", or "deleagation certificate", and the one issued by the operator as a "delegated credential". </del> <ins> "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential". </ins> 2.

issue other signed objects as long as the certificate contains the digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that <del> are needed for this application. </del> <ins> are needed for this application.  The credential has the following structure: </ins> <del> Relative time in seconds from the beginning of the certificate's notBefore value after which the delegated credential is no longer valid. </del> <ins> Relative time in seconds from the beginning of the delegation certificate's notBefore value after which the delegated credential is no longer valid. The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in the TLS 1.3 standard. The version of TLS in which the credential will be used, where the type ProtocolVersion is as defined in TLS 1.3. </ins> The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280. <ins> The delegated credential has the following structure: </ins> The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard.

The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. <del> The ProtocolVersion in which the delegated credential is to be used, where ProtocolVersion is as defined in the TLS 1.3 standard. The SignatureScheme of Credential.public_key, the signature scheme used by the server to sign the handshake. </del> <ins> DelegatedCredential.cred. </ins> DelegatedCredential.scheme. <del> DelegatedCredential.cred. </del> The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and
Change:
Update the condition for validating a DC to the following: now() <= notBefore + valid_time <= now() + 7d
LGTM % nit

Discussion:
Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential <del> is no longer valid.  Endpoints will reject delegate credentials with valid_times exceeding 7 days (as described in client-and- server-behavior). </del> <ins> is no longer valid.  Endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in client-and-server-behavior). </ins> The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be

On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity <del> certificate to the peer's expected identity.  It also takes the following steps: Validate that DelegatedCredential.cred.valid_time is no more than 7 days. </del> <ins> certificate to the peer's expected identity.  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 <del> is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. Verify that the delegated credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </del> <ins> does not exceed the expiry time. Verify that the delegated credential's remaining validity period is no more than the maximum validity period.  This is done by asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days). </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the
Change:
Follow up to PR . Add a link for the ALPN RFC to the relevant alert's description. (same as with other extension alerts above)
URL & No feature in the TLS 1.3 spec, optional or required, needs ALPN to work. We merely cite places where it needs to be taken into consideration if it is in use. It could be argued that it is an "optional feature" of TLS (as a whole), but not of this document, thus I don't think it meets the qualifications to be normative. I think staying as informative is correct.
There's a bunch of text that specifically mentions ALPN, some of it with normative statements. If those normative statements can't be understood, optional feature or not, then it's normative.

Discussion:
Sent by servers when a client "application_layer_protocol_negotiation" extension advertises <del> protocols that the server does not support. </del> <ins> protocols that the server does not support (see RFC7301). </ins> New Alert values are assigned by IANA as described in iana- considerations.