Peter,
Thank you for taking the time to respond and for explaining the history behind
this. You make some very valid points.
I don’t believe we have sacrificed any functionality by making the extension
generic enough to be used by others. It has been designed with the global civil
aviation community's needs in mind. But that is a large community with varying
needs.
I fully recognize that SCVP is not widely used. I would also not consider it to
be nonexistent. We have been using it in ground to ground communications. There
are at least three COTS offerings of SCVP Servers. Not a lot, but some
competition. I have personally tested interoperability with two of the three.
This testing was done between FAA and EUROCONTROL with separate vendors and
client implementations. We found some inconsistencies but overall
interoperability went quite smoothly. I believe this is because an RFC
followed. We do not intend to implement our own SCVP Server.
As for this extension, in aviation this will not be implemented by a single
vendor. It will require implementation by different aircraft,OEM and ground
system vendors worldwide. ICAO is looking to make support for this a
requirement for ground systems (optional for aircraft). Admittedly, this is all
within the global civil aviation community. But I want to be clear that I do
not intend to implement a solution and try to sell it to the community. My
implementation will be for testing the viability of the extension and will be
released open-source. Our business model is not what you describe.
With all of that said, I am here asking for guidance. I am new to this
community. I am not trying to game any bureaucratic processes. I am excited to
have the opportunity to interact with the experts in this area and to hopefully
make a contribution.
I will follow Rob’s advice and reach out to the Chairs and AD. Any other advice
is welcomed.
Thank you,
Ashley Kopman
> On Aug 26, 2022, at 6:15 AM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
>
> 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
