questions on RFC2631 and DH key agreement

[Peter Gutmann]

' =JeffH ' <Jeff.Hodges at KingsMountain.com> writes:
>docbook.xml at gmail.com 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.

I'm going to approach the answer somewhat differently: Why are you using this
mechanism?  The only reason that it's present in the spec is politics, it
being an attempt to avoid the RSA patent.  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.  Although X9.42 was at one point listed as
mandatory to implement for S/MIME v3, the approach that was taken by most
vendors was to vaguely pretend to support X9.42 while actually concentrating
on RSA, knowing that noone else supported it either (AFAIK only two vendors
ever really supported it, Microsoft had a receive-only implementation so that
no-one could accuse them of not being compliant with the spec, and the S/MIME
Freeware Library (which was the reference implementation and therefore had no
choice in supporting it) supported it because it had to).  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:

-- Snip --

How about trying to make the spec at least vaguely approximate reality in the
choice of algorithms?  It doesn't really matter if you include requirements
like "MUST DSA OR WE WILL KILL YOU[0], SHOULD NOT RSA", in practice the world
will interpret it as "MUST RSA, MAY DSA, SHOULD NOT X9.42 DH, BWAHAHAHAHAHA
X9.31 RSA" no matter what it says in the RFC.

I've been sitting here watching this debate go on and on, but since no matter
what you put in the RFC the market will interpret it as MUST RSA and various
levels of deprecation for anything else maybe we could get Markov Chaney to
continue the debate for a while just for forms sake and then after enough
messages have been exchanged to satisfy everyone either put text in the RFC
which accepts what everyone's going to do anyway or which specifies all sorts
of options and alternatives secure in the knowledge that implementors will
ignore it and do what the market wants/expects, which ain't DSA or X9.42 or
X9.31 RSA.

Peter.

[0] RFC 2026bis, "When MUST just isn't enough".

-- Snip --

So by implementing this you're getting an unwanted orphan crypto mechanism
that was only added for political reasons.  Are you sure you don't want to use
RSA instead?

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com