Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03

[Benjamin Kaduk <[e-mail]>]

On Fri, Dec 16, 2016 at 01:06:01PM +0000, Salz, Rich wrote:
> > I believe that the OpenSSL people would be sad if we changed this at this
> > time.  I did some interop testing with their developers before the last version
> > was released and the OCTET STRING wrapper on the private key is what we
> > were doing at the time.
> 
> Speaking as an individual, yes.  Please don’t change this.

It's a fairly frustrating feeling for a protocol designer to be hedged
in to a particular behavior because an implementation of a draft version
escaped into the wild and the change is not worth the pain of breaking
interoperability.  This happens all over the place, not just here, of course,
which leads to the question of what can we do to avoid getting locked into
the draft interfaces.  It's easy to point fingers and say that the
software authors should know to have a transition strategy if they ship
a protocol that is explicitly a work in progress, but that doesn't really
seem very productive.  The TLS 1.3 story seems fairly reasonable, with
a scheme to indicate support for a specific draft version as opposed to
having to squat on the version number for the final protcol, but that
seems to have evolved semi-organically as I understand it, with informal
contact among the early implementors.  Should all drafts burn a set of
codepoints and map them to the given draft versions?  Probably not.
Should they think about it?  Maybe.  Are there other techniques that
we can use to help software authors avoid shooting the ecosystem in the foot?

-Ben