Thank you for the list reference. I agree with Eric that a comparison is unnecessary. I'm not interested in seeing this document stack ranking itself against other documents. What I am asking for is an explanation as to why it is =N, which can be done without making any comparisons.
For those following along on email, the rejected text was a simple reference to Section 9.1 of draft-ietf-lamps-pq-composite-sigs, saying it "considers when a PQ/T could be preferred": https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19#section-9.1 My concern unfortunately is not mitigated by the change being contentious. As it stands, I cannot in good faith agree this document is ready for publication when the only other RFC (9963) to define Recommended=N values in this registry not published through ISE (and therefore lacks the "IETF doesn't endorse this" language) went to great lengths to explain why it is =N, but this document says absolutely nothing about it. That creates a very obvious difference in the documents with =N entries, where all but one explicitly tell the reader it isn't endorsed or it normatively must/should not be used in the default case. This could be as simple as explaining exactly what you just stated: this Informational standard was adopted by the WG because it saw value in standardizing the mechanism, but did not have consensus to set Recommended=Y because there was disagreement at publication time that pure PQ algorithms have sufficient experience in deployment to be recommended. Note that there is no need to then proceed to explain "because <pure PQ versus hybrid debate>", though it circles back to the concern other ADs have about maybe Experimental being a better fit for this. On Jul 2, 2026 at 05:54, Bas Westerbaan <[email protected]> wrote: Adding some words on composites has been proposed, and got pushback, eg. https://mailarchive.ietf.org/arch/msg/tls/7TDHk9yQQ_LvXFwMG7dJmsC9YEs/ On Thu, Jul 2, 2026 at 2:50 PM Salz, Rich <[email protected]> wrote: > There is not WG consensus to recommend pure-PQ algorithms at this time. I > doubt further clarification is needed, and adding any words runs the risk > of restarting the flame wars that have enveloped the WG on this issue. >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
