[gnutls-devel] X.509 "Key Identifiers" in GnuTLS

[Peter Williams]

there is unlikely to be anything sinister about GNU (except the usual rants about GNU’s mission and ulterior motives)

 

What Im saying is that there is space for value-add, that someone might well have taken.

 

But, I do assume that IETF standards are “public policy” property; taking into full consideration all the hard politics that comes with key management. This includes biases and tradeoffs between what is forced to be a presumption for interworking (i.e. MUST statements).

 

It comes down to this. When IESG ratifies a SHOULD, this does not mean you have to do it. You may well choose to NOT engender “maximal” interworking - putting up with interworking (80% of the time). When one has a ratified SHOULD, It means partial reasons from some communities were convincing to avoid MUST, but those reasons are not relevant to the “internet” - though they may be relevant to some military internet (milnet) for example. Stuff that goes into the milnet applicability statement is NOT put in the RFC, but codifies as SHOULD.

 

Arguments about what the serial should be are long standing. One vendor, rather infamous, wanted the serial number to tie to the HSM, and its hierarchical identification scheme. In making a break with hardware “cultured” crypto (back in 1990-1994), I didn't. One can look at the field you are interested as the more modern form of the serial number (and all the debates over how the field is to be used in security enforcing functions, both software chaining and hardware box referencing).

 

Would be interesting to hear from the programmer though. One has heard (from me) why I/VeriSign did X, 20+ years ago - based on the desired culture shift to the expected 20-year reign of software CSPs.

 

From: Daniel Kahn Gillmor
Sent: ‎March‎ ‎5‎, ‎2013 ‎10‎:‎48‎ ‎AM
To: Peter Williams
CC: GnuTLS development list
Subject: Re: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS



On 03/05/2013 01:40 PM, Peter Williams wrote:
> Think of it as vendor-value add - where no one will agree on its value. Often patent or “other” reasons are behind such inability to agree.

hm, i'm not inclined to think of this as something sinister.  there
actually *is* a documented "common method" recommendation.  It's GnuTLS
that is divergent from it.  Are you implying that GnuTLS has some sort
of patent or proprietary reason for its divergence?  That seems
implausible to me.

> For example, a hash value in the serial number of certs saved VeriSign from the md5 compromise, since it made it SO Much harder to predict a plaintext AND find a collision. To me it was elementary cryptanalysis; but try convincing generalists of it. Specialists in the know would accept the argument, but there would always be “specious” reasons why not to make it a standardized element. We all know what lay behind those specious reasons, now.

Again, i'm not sure what you're implying here.  I'm not talking about
the serial number, but rather the key identifiers.

If GnuTLS is doing something different from everyone else, and we have a
good reason for doing it different, shouldn't we be encouraging other
toolkits to at least offer their users the option of taking our improved
approach?

On the other hand, if GnuTLS has no reason for the divergence (e.g. if
it was an accident) then shouldn't we try to reduce divergence to
improve interoperability?

        --dkg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130305/0fba9fa4/attachment.htm>