Andrew Farrell <afarrell(_at_)baltimore(_dot_)ie> writes:
(1) Are there any deployed codebases which would object to changing the
Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
semantics than in X9.42?
I know that John Pawling has stated that Van Dyke's S/MIME Freeware Library
has no issues, and as far as I know Microsoft haven't shipped anything with
Diffie-Hellman, so that S/MIME would appear to be in the clear on this.
Some of the OpenSSL people have complained in the past that they haven't been
able to find any examples of DH certs to test, and I've never seen one either,
so if anyone has implemented this they're keeping it very well hidden.
Actually the solution to this problem is easy, just switch back to the PKCS #3
OID which was the one which noone was using before they switched to not using
X9.42. This is far more sensible:
DHPublicKey ::= INTEGER
Parameters ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL
}
You can't get the parameters for that wrong (well, not without a lot of
effort).
(A problem with this is that it doesn't accommodate X9.42's q and j. If PKIX
is going to define a new OID without the asking-for-trouble X9.42 semantics,
it'd be good to have q and j OPTIONAL to allow key generation techniques
other than the FIPS 186 kosherizer, which is both unnecessarily inefficient
(when used to generate DH keys) and generates unsafe keys, requiring further
band-aids - draft-ietf-smime-small-subgroup.txt - to make their use safe. In
contrast key generation techniques like Lim-Lee are both faster and generate
keys which are immune to this problem, but are excluded from use by the need
to provide a q value in the AlgorithmIdentifier).
Peter.