I fully agree. Thank you Ben!
On 4/6/21, 21:43, "Benjamin Kaduk" <[email protected]> wrote:
Hi Yaron,
Thanks for the (multiple!) reviews.
My understanding is that the intention is not to allow "server_name" in all
CertificateRequests but only specifically in the ClientCertificateRequest
case. I think it can be helpful to notate that with a "CR" in the "TLS
1.3" column of the registry but we would need some further clarification as
to what that notation actually means. I left some suggestions for how to
do that in my ballot position, but to summarize: a "comment" column in the
registry would be great for this, and failing that a note in the IANA
Considerations of this document to clarify what is and is not being
registered would probably work as well.
Thanks again for highlighting this point,
Ben
On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker
wrote:
> Reviewer: Yaron Sheffer
> Review result: Has Issues
>
> After a bit of back and forth over my *two* previous SecDir requests, I'm
> afraid that my original comment has not yet been fully addressed. The IANA
> considerations section (Sec. 8.1) adds server_name as a possible
extension for
> CertificateRequest. This would be a non-backward compatible change to TLS.
>
> IMO what we needed to do is both to clarify the allowed extensions for
what
> Nick called "the CR-like structure" (almost done in Sec. 4, though the
last
> sentence should by changed to include CertificateRequest) and undo the
change
> to the TLS ExtensionType registry (not done, would require to remove Sec.
8.1).
>
> * Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5,
and in
> both cases is mangled.
>
> Old:
>
> The application layer protocol used to send the authenticator request
SHOULD
> use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as
its
> as its underlying transport to keep the request confidential.
>
> New:
>
> The application layer protocol used to send the authenticator request
SHOULD
> use a secure *channel* with equivalent security to TLS, such as QUIC
> [QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
> confidential.
>
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
