Ok thanks, I'm going to risk pedanticism in order to nail things down a bit 
more rigorously..

' =JeffH ' <[EMAIL PROTECTED]> writes:
>> http://www.xml-dev.com/blog/index.php?action=viewtopic&id=196
>>thanks, but that doesn't actually answer my first question. It only documents
>>that a and b (alice and bob) arrive at the ZZ value independently. My 
>>is actually concerning section 2.1.2 "Generation of Keying Material" in

>  I'm going to approach the answer somewhat differently: Why are you using
> this mechanism?

Are you referring to the above mentioned mechanism of arriving at the ZZ value 
independently, which is implied in RFC2631?

(btw, I am not myself designing anything at this time that uses DH, I'm 
reviewing/analyzing. I am _not_ reviewing RFC2630/2631 themselves, rather it's 
a (non-IETF) spec that references 2631)

>  The only reason that it's present in the spec is politics,
> it being an attempt to avoid the RSA patent.

So by "the spec" you're referring to RFC2631 here?

Or are you referring to X9.42?

Or something else?

>  Its adoption was severely
> hampered by the fact that US vendors already had RSA licenses, non-US vendors
> didn't care (and in any case the patent has now expired, so they care even
> less), no CA's of note will issue X9.42 certificates, and even if they did
> almost no S/MIME implementations support it.


So here, and in the snippage, are you referring to X9.42 itself, or CMS 
(Cryptographic Message Syntax) ?

>  A few years after the expiry of the RSA patent, the matter was corrected by
> changing the standard so that vendors were no longer required to even pretend
> to support X9.42.  My comments at the time were:

Exactly which "standard" ?  From grepping all RFCs, it seems you're referring 
to CMS when you say "the standard", which has indeed been revised a few times 
since RFC2630.



The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to