A note to consider:
"DHPublicKey" has an implied meaning that the Diffie-Hellman algorithm is the
discrete logarithm version based on unsigned integer operations. However, this
is not the only version of DH. There is an integer version with cofactor
exponentiation, and similarly there are elliptic curve versions, with and
without cofactor multiplication.
In the search of a "standard" OID and its associated parameters, these should
be considered as well, including the naming, which may be misleading.
One place to look at would be the IEEE P1363 effort on public-key standards.
- Tolga
Peter Gutmann <pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz> 7/31/99
2:47:28 >>>
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.