Thank you Nick for your reply and for the changes. Hope that this helped to improve the document,
Regards -éric From: Nick Sullivan <[email protected]> Date: Tuesday, 14 June 2022 at 12:47 To: Eric Vyncke <[email protected]> Cc: The IESG <[email protected]>, "[email protected]" <[email protected]>, tls-chairs <[email protected]>, "<[email protected]>" <[email protected]>, Joseph Salowey <[email protected]>, Sean Turner <[email protected]> Subject: Re: Éric Vyncke's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT) Hi Éric, Thank you for your review. Responses inline and edits in Github (https://github.com/tlswg/tls-subcerts/pull/108/files). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-tls-subcerts-14 Thank you for the work put into this document. It solves a common and important issue while keeping backward compatibility. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Joe Salowey for the shepherd's write-up including the WG consensus and the intended status. I hope that this helps to improve the document, Regards, -éric ## COMMENTS ### Section 1 ``` Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032] even if their CA does not support them. ``` Does it also mean that the signature algorithm could be weaker ? In theory, TLS 1.3 (and by extension DCs) do not support weak signature schemes. I found the use of `(D)TLS termination services`, `(D)TLS server`, `(D)TLS peer` a little confusing on whether they represent the same entity. I added some text in the introduction to clarify. ### Section 3.2 The small graphic in the text is really useful but: * should include a figure legend * the bottom part would be welcome in the introduction Added ## Section 4.2 Thanks to Sean Turner for providing the explanation about the use of Cloudflare OID into an IETF standard. ## Section 5.1 Unsure whether having such a short subsection is useful (albeit being harmless) especially when there is only one subsection. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
