ietf-smime
[Top] [All Lists]

RE: X9.42 and RFC2459 inconsistency?

1999-07-30 15:51:32
We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
OID.

John

(Entegrity Solutions)

-----Original Message-----
From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz 
[mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: 31 July 1999 03:47
To: ietf-pkix(_at_)imc(_dot_)org; ietf-smime(_at_)imc(_dot_)org
Subject: Re: X9.42 and RFC2459 inconsistency?


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>