[TLS] (bonus) AD review draft-ietf-tls-subcerts

[Paul Wouters <[e-mail]>]

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:
https://mailarchive.ietf.org/arch/msg/tls/qa908s0dMNxbUOZhnUel0qEVBSg/

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?

 expected_cert_verify_algorithm - why is this not called
dc_cert_verify_algorithm or dc_verify_algorithm ?
  As in, why is there an "expected" prefix? We talk about
signature_algorithms and not expected_signature_algorithms ?

  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"


   1.  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" ?

   2.  The context string "TLS, server delegated credentials" for server
       authentication and "TLS, client delegated credentials" for client
       authentication.

- Same here, non-null terminated string?

   3.  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
   "delegated_credential" 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 "delegated_credential"
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 "delegated_credential", 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 <some fatal error>" ?


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:
https://datatracker.ietf.org/doc/review-ietf-tls-subcerts-12-genart-lc-davies-2022-04-08/

Paul