On Mon, 2017-06-19 at 19:31 -0400, John C Klensin wrote: > > --On Monday, June 19, 2017 21:26 +0300 Yoav Nir > <ynir.ietf@xxxxxxxxx> wrote: > > >... > > By the Postel principle, the receiver should accept this > > chain. In practice I might limit it to a lower number, because > > I assume nobody does that. I think it's best for the > > specification to say that "MUST support a chain of at least > > 7 and MUST NOT send a chain longer than 7", and of course > > you'd have to say that profiles may further reduce this > > number (for IoT). > > It seems to me that your example, and some others, suggest that > if the principle was being stated today, it would be "be > conservative about what you send and liberal about what you > accept, but nothing justifies violations of common sense or > taking actions that would create risks". If the latter/new part > is really needed, we may be in worse trouble than with questions > about what the principle really means or even whether Jon was > right or wrong. > Yeah, as the joke goes, common sense isn't. Even assuming it's prevalent, if you run a survey at the next TLS meeting what is a reasonable limit for the length of a chain, you'd get a bunch of different answers. Mine would be 10 because I have seen a real 7-cert chain in production, but before that I might have said 4 or 5. Without specifying it any sender has to be really conservative, maybe limiting themselves to 3 in case there is some receiver out there that is making severe assumptions. Without this being specified we end up with receivers planning for 10 and senders limiting themselves (and their PKI) to 3. This is not optimal. I am not sure what the take away is. On the one hand under-specifying creates interop failures, security issues and much complexity to address issues and fix interop with old and new implementations. On the other hand, the most successful protocols had a lot of wiggle room, and I don't think this is coincidence. Yoav