>> 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?

I'm referring to the "X9.42" mechanism (as used in CMS) as a whole (see below
for the reason why this is in quotes).

>(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)

Oh.  In that case you have my sympathy :-).

>So by "the spec" you're referring to RFC2631 here?
>Or are you referring to X9.42?

I'm referring to the (old) CMS RFCs.  Even the RFCs themselves don't use
proper X9.42, they were based on an old draft that floated around for awhile
and was subsequently changed and updated.  You can see this if you look at the
order of the DLP key parameters, everything else (e.g. FIPS 186) uses { p, q,
g }, while the old CMS RFCs flip the second two values to use { p, g, q }.

I think the definitive comment on this (which also talks about differences
between FIPS 186, various X9.42 drafts, and the CMS use of those drafts) is by
the former editor of X9.42, and is archived at

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

Specifically CMS, since X9.42 isn't necessarily what's used in CMS.


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

Reply via email to