[prev in list] [next in list] [prev in thread] [next in thread]
List: gnutls-dev
Subject: Re: [gnutls-devel] =?utf-8?q?X=2E509_=22Key_Identifiers=22_in_GnuTLS?=
From: Peter Williams <home_pw () msn ! com>
Date: 2013-03-05 18:59:48
Message-ID: SNT401-EAS31518F8F40EDFDF57AD969992FB0 () phx ! gbl
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
[Attachment #4 (text/plain)]
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
[Attachment #5 (text/html)]
<html><head><style data-externalstyle="true">
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, \
div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, \
li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, \
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast \
{ margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
</style><style><!--
.EmailQuote {
padding-left:4pt;
margin-left:1pt;
border-left-color:rgb(128, 0, 0);
border-left-width:2px;
border-left-style:solid;
}
--></style></head><body><div data-externalstyle="false" \
style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei \
UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao \
UI',Ebrima,sans-serif;font-size:16px;"><div>there is unlikely to be anything sinister \
about GNU (except the usual rants about GNU's mission and ulterior motives)</div><div \
data-signatureblock="true"> </div><div data-signatureblock="true" \
data-focusfrompointer="true">What Im saying is that there is space for value-add, \
that someone might well have taken.</div><div \
data-signatureblock="true"> </div><div data-signatureblock="true" \
data-focusfrompointer="true">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).</div><div \
data-signatureblock="true" data-focusfrompointer="true"> </div><div \
data-signatureblock="true" data-focusfrompointer="true">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.</div><div data-signatureblock="true" \
data-focusfrompointer="true"> </div><div data-signatureblock="true" \
data-focusfrompointer="true">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).</div><div data-signatureblock="true" \
data-focusfrompointer="true"> </div><div data-signatureblock="true" \
data-focusfrompointer="true">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.</div><div \
data-signatureblock="true"> </div> <div style="border-top-color: rgb(225, 225, \
225); border-top-width: 1px; border-top-style: \
solid;"> <strong>From:</strong> Daniel Kahn \
Gillmor<br> <strong>Sent:</strong> March 5, 2013 \
10:48 AM<br> <strong>To:</strong> Peter \
Williams<br> <strong>CC:</strong> GnuTLS development \
list<br> <strong>Subject:</strong> Re: [gnutls-devel] X.509 "Key Identifiers" \
in GnuTLS<br> </div> <div> </div>
<font size="2"><span style="font-size: 10pt;"><div class=" PlainText">On 03/05/2013 \
01:40 PM, Peter Williams wrote:<br> > 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.<br> <br>
hm, i'm not inclined to think of this as something sinister. there<br>
actually *is* a documented "common method" recommendation. It's GnuTLS<br>
that is divergent from it. Are you implying that GnuTLS has some sort<br>
of patent or proprietary reason for its divergence? That seems<br>
implausible to me.<br>
<br>
> 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.<br> <br>
Again, i'm not sure what you're implying here. I'm not talking about<br>
the serial number, but rather the key identifiers.<br>
<br>
If GnuTLS is doing something different from everyone else, and we have a<br>
good reason for doing it different, shouldn't we be encouraging other<br>
toolkits to at least offer their users the option of taking our improved<br>
approach?<br>
<br>
On the other hand, if GnuTLS has no reason for the divergence (e.g. if<br>
it was an accident) then shouldn't we try to reduce divergence to<br>
improve interoperability?<br>
<br>
--dkg<br>
<br>
</div></span></font>
</div></body></html>
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic