Ashley Kopman <akop...@conceptsbeyond.com> writes:
>Although our use case is aviation, our goal is to write this draft so that it
>can be used by other domains.
Someone has to say this, so I may as well: I don't think you'll have to worry
about anyone else using it. The PKIX WG left behind it a long trail of RFCs
that no-one ever implemented except for maybe one sample attempt by the
company that commissioned the RFC. One notorious example is one of the
protocols with "path validation" in the name somewhere for which the sole
known sort-of implementation at the time was a set of abandoned patches to
OpenSSL dating from about 2005 located on an FTP server in a disused lavatory
in France with a "Beware of the leopard" sign on the door [0].
The problem is that every now and then some industry body finds one of these
RFCs and decides that they're exactly what they need without being aware of
the fact that support for them is essentially nonexistent, thus my surprise
when mention of SCVP use came up a few months ago, it was one of the many
protocols that had no known, or at least visible, support anywhere.
>From a vendor point of view this is brilliant because you get paid once to
implement your guess at some protocol that none of the usual suspects supports
so it's necessary to commission a custom implementation, and then again for
each other custom implementation that it has to talk to when you try and
reverse-engineer what their guess at the protocol was. Then once it's
implemented you've got a captive market with very little choice for
alternatives or competitive pressure. It's, um, great for business.
More difficult is when said industry body specifies stuff that's in the spec
but that absolutely nobody implements, typically because nobody can figure out
why it's in the spec or what purpose it serves. If there's five different
ways of doing the same thing (there usually are in PKIX specs), industry
bodies have an unerring knack for picking one of the four that no-one
implements because when you do you realise they don't make any sense, rather
than the one that does. This is less good because as an implementer you're
now stuck between a rock and a hard place. Technically what's being asked for
is in the spec so you end up in a long argument over whether the contract
should be interpreted as "follows the spec" or whether it should be "works in
practice", and if it's the former, how the other implementation managed to
create something that appears to work ("accept any old rubbish that arrives"
seems to be one approach, including in one case a Stalin quote in what was
supposed to be a security-relevant field).
After all that, two comments:
1. You may as well make it as aviation-specific as you like and thereby get
exactly what you want, I doubt anyone will care, or even notice.
2. We really need a register of RFCs that essentially nothing supports or
implements to prevent more cases of industry groups thinking they should do
something with them.
Peter.
[0] It may have been Italy or one of the Benelux countries, I can't remember
exactly.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
