On Sun, May 17, 2026 at 11:20 PM Timo Gerke <[email protected]> wrote:
> Hi Eric, > > To be clear: TLS was merely an illustrative example, not a specific > protocol proposal for the TLS WG. > Well, when your example is bad, that suggests that perhaps the idea is also not good. > > The goal of this discussion is the Policy and Architecture of the STD > series as a whole. Whether it's TLS, IPsec, or BGP—the requirement for a > modular, audit-ready structure remains the same. > > Let's focus on the Blueprint (Points 1–5) and how we prevent the > namespace collapse, rather than getting lost in the implementation > details of a single example. As I said, i don't think this is addressing the primary problems with mapping specifications onto RFCs, which are much more about the ability to progressively revise than imposing some sort of meta-structure. -Ekr > > Regards, > > Timo > > Am 17.05.26 um 23:21 schrieb Eric Rescorla: > > 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] > > <mailto:[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. > > -- > Timo Gerke > Lohkoppelweg 40 > 22529 Hamburg > Germany > Fon: +49-40-24433033 > Fax: +49-40-22628453 > > If you think technology can solve your security problems, > then you don't understand the problems and you don't > understand the technology. > Bruce Schneier, amerikanischer Kryptograph > >
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
