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

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

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