I agree with those who have observed that this is out of scope for RSWG. With that said, I also don't think that this proposal really addresses the issues with mapping specifications onto RFCs. In particular, the proposed restructuring of TLS 1.3 would not really be an improvement.
On Sun, May 17, 2026 at 6:07 AM Timo Gerke <[email protected]> wrote: > > > Part 1: Core Specification (Algorithm-agnostic Handshake/State > Machine) > Parts 2–5: Mandatory Crypto Modules (Key Exchange, Signatures, etc.) > I don't see how this would really work, for several reasons: 1. The vast majority of the complexity in 8446 is in what you're calling the "core specification", with the actual algorithm specifications being comparatively short. 2. It's much easier to understand 8446 if you have some sense of how the key establishment works. 3. The distinction between Mandatory and Optional isn't really that interesting from the perspective of understanding the specification and we sometimes move algorithms from one category to another. > Parts 6–8: Optional Extension Modules (ECH, SNI, etc.) > And what if there are > 3 modules? > Part 9: Strict Compliance Profile (SCP) (Test Vectors and > Environments for Parts 1 to 5, chapter-separated) > Part 10: Extended Compliance Profile (ECP) (Test Vectors and > Environments for Parts 6 to , chapter-separated) > Parts 11-18 modules mot defined yet > Part 19 Test Vektor and Environments for modules 11-18 Having the modules and test vectors interlaced like this seems like a mess. -Ekr
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
