Draft: draft-ietf-tls-subcerts

Commentary:  provided an AD review that can be found . 
 Addressed via .
Paragraph (version A):
The signature algorithm used to verify
DelegatedCredential.signature.
Paragraph (version B):
The signature algorithm used to create
DelegatedCredential.signature.
Paragraph (version A):
A string that consists of octet 32 (0x20) repeated 64 times.
Paragraph (version A):
The context string "TLS, server delegated credentials" for server
authentication and "TLS, client delegated credentials" for client
authentication.
Paragraph (version A):
A single 0 byte, which serves as the separator.
Paragraph (version B):
An octet stream that consists of octet 32 (0x20) repeated 64
times.
Paragraph (version B):
The non-null terminated context string "TLS, server delegated
credentials" for server authentication and "TLS, client delegated
credentials" for client authentication.
Paragraph (version B):
A single octet 0x00, which serves as the separator.
Paragraph (version A):
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.  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
SignatureSchemes listed only contain signature schemes for which a
corresponding delegated credential does not exist or are otherwise
unsuitable for the connection.
Paragraph (version B):
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.  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
SignatureSchemes listed only contain signature schemes for which a
corresponding delegated credential does not exist or are otherwise
unsuitable for the connection.
Paragraph (version A):
The algorithm field MUST be of a type advertised by the client in the
"signature_algorithms" extension of the ClientHello message and the
expected_cert_verify_algorithm field MUST be of a type advertised by
the client in the SignatureSchemeList and is considered invalid
otherwise.  Clients that receive invalid delegated credentials MUST
terminate the connection with an "illegal_parameter" alert.
Paragraph (version B):
The algorithm field MUST be of a type advertised by the client in the
"signature_algorithms" extension of the ClientHello message and the
dc_cert_verify_algorithm field MUST be of a type advertised by the
client in the SignatureSchemeList and is considered invalid
otherwise.  Clients that receive invalid delegated credentials MUST
terminate the connection with an "illegal_parameter" alert.
Paragraph (version A):
If the extension is present, the client MAY send a delegated
credential; if the extension is not present, the client MUST NOT send
a delegated credential.  The client MUST ignore the extension unless
(D)TLS 1.3 or a later version is negotiated.
Paragraph (version A):
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.
Paragraph (version A):
The algorithm field MUST be of a type advertised by the server in the
"signature_algorithms" extension of the CertificateRequest message
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.
Paragraph (version B):
If the extension is present, the client MAY send a delegated
credential; if the extension is not present, the client MUST NOT send
a delegated credential.  When a (D)TLS version negotiated is less
than 1.3, the client MUST ignore this extension.
Paragraph (version B):
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.
Paragraph (version B):
The algorithm field MUST be of a type advertised by the server in the
"signature_algorithms" extension of the CertificateRequest message
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.
Paragraph (version A):
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.
Paragraph (version B):
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.