Change:
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> <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.

Discussion:
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