Ok thanks, I'm going to risk pedanticism in order to nail things down a bit more rigorously..
' =JeffH ' <[EMAIL PROTECTED]> writes: >>[EMAIL PROTECTED] said: >> 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 question >>is actually concerning section 2.1.2 "Generation of Keying Material" in >>RFC2631. [EMAIL PROTECTED] said: > 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. <snippage/> 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. thanks, =JeffH --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
