Well OK, a bit of a rant rather than just comments...
I've had a go at implementing this, and after stuffing around with it for
awhile I've come to the conclusion that this option must have been designed by
RSADSI to make the alternative of getting a patent license to use
KeyTransRecipientInfo look good[0]. What a mess! Consider the most obvious
use for DH keying material, which is to use it in Elgamal as per the existing
KeyTransRecipientInfo and RFC TBA, the X.509 profile for Elgamal. All it
takes is a few lines of code to use it with existing mechanisms.
Now let's look at the way it's applied here. A rough outline of what's
contained in KeyAgreeRecipientInfo is:
originatorDH -- Originators DH values p, g, y = g^x mod p
recipientDH -- Recipients fixed DH values p, g, y' = g^x' mod p
nonce -- Extra material to mix in to ensure different keys are
produced
First of all, both sender and recipient need to somehow agree on using the
same p and g values, which means either everyone shares the same values
(presumably these will be ones for which the NSA et al have performed the
necessary precomputations to make solving the DLP easier), or alternatively
you need to get a new certificate for each users values (OK, looks like
Verisign were in on designing this thing as well). As a result you either end
up with a solution which is of questionable security due to use and re-use of
widely-shared public values, or which is extremely expensive and practically
impossible to manage because you need to have a certified DH public key
corresponding to each recipients DH key (CMS tries to kludge around this by
requiring the use of originatorKey, an uncertified, unauthenticated DH public
value).
Anyway, moving past this, you either have a DH static key (inexpensive but
insecure due to reuse), a DH ephemeral key (expensive since you need a new
cert issued for each key), or the abovementioned unauthenticated DH public
value (again, CMS explicitly requires the use of a static key for the
recipient). Since the DH exchange with fixed parameters always produces the
same output, you also need to mix in extra keying material in a further kludge
to try and shoehorn straight DH into functioning as a form of key transport
mechanism.
"To walk right past the correct solution and come up with this
takes some beating"
- Comment from someone who reviewed this rant
I realise there's probably some sort of motivation to try and do something
with X9.42, but do we really have to jump off a cliff just because X9.42 does
as well?
"Just because it's possible to push a pea up a mountain with
your nose doesn't mean that this is a good way of getting it
there"
- Chris Strachey
Why not just change the requirements to:
"Implementations MUST support key transport using Elgamal. Implementations
MAYM[1] include key agreement using X9.42 Ephemeral-Static Diffie Hellman".
This provides a straightforward nonpatented alternative to RSA which uses DH
keys just as KeyTransRecipientInfo does (so it's possible to claim compliance
to X9.42 or reference it in the spec or include it in the product advertising
or whatever the rationale for working with it is) while still having something
which is practical and simple to implement.
Peter (and I made it right through that without including the "looks like the
winning candidate from a 'Worst way to apply DH to a key management
problem' competition" comment :-).
[0] This is satire folks, not intended as a slight on RSADSI.
[1] "MAY if the implementors are Masochists". An alternative is MAYEURKW,
"MAY if they Enjoy Unnecessary Root Canal Work".