ietf-smime
[Top] [All Lists]

Re: X9.42 and RFC2459 inconsistency?

1999-07-30 07:51:40
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.


<Prev in Thread] Current Thread [Next in Thread>