Subject: RE: X9.42 and RFC2459 inconsistency?

From: "William Whyte" <[email-masked]>
Date: Wed, 28 Jul 1999 16:54:35 +0100

>  William> 1) A BER-encoded integer doesn't have trailing unused bits
>  William> in the last byte. If you weren't expected to left-shift,
>  William> surely it would say something like "the BIT STRING encoding
>  William> should indicate zero unused bits in the last octet". And
>  William> note that it says "If the integer is not an integral number
>  William> of octets in length", not "If the INTEGER..."; the
>  William> implication is that we're dealing with the raw data.
> 
> Agreed that it's dealing with the raw integer, not an encoded
> integer.  But my point is that "7 bit integer" doesn't mean that the
> MSB is set.  You can have the value 1 in a 7 bit integer.  So that
> would say the shift count for that example is 1, and the unused bit
> count is 1, while your description says the shift count and unused bit 
> counts are 7.

Fair enough, I suppose that's a possible interpretation. But it
makes the X9.42 spec even more ambiguous than before. It gives us
eight different possible encodings of the integer 1, for example,
depending on whether you mean an eight-bit 1 or a one-bit 1. The
only unambiguous interpretation I can see is that you're intended
to left-shift it.

William

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Jul 1999 04:39:17 (NZST)

"William Whyte" <[email-masked]> writes:

>There seems to be an inconsistency between X9.42 and RFC 2459 about how to 
>encode Diffie-Hellman public keys.

During RFC 2459's draft stages this was changed to the current form when it
was pointed out that the X9.42 version was essentially unworkable (it 
required complicated and unnecessary processing of the value which is
incompatible with the way any other subjectPublicKey is handled, and it's
practically guaranteed that implementors will get it wrong in a variety of
ways which will cause all sorts of headaches - the values will look right
and even work properly, they just won't give the expected results when used
with implementations which do it differently to however you're doing it).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Jul 1999 05:06:52 (NZST)

William Whyte <[email-masked]> wrote:

>On the other hand, X9.42 says 
>
>[...]
>
>which reads like you take the ASN.1 INTEGER, strip off the tag, left-shift
>it until the most significant bit is set, and then encode it as a BIT
>STRING with the appropriate number of unused bits, not containing an
>INTEGER at all.

Paul Koning <[email-masked]> commented:

>I don't read it quite that way.

William Whyte <[email-masked]> came back with:

>Fair enough, I suppose that's a possible interpretation. But it makes the 
>X9.42 spec even more ambiguous than before. It gives us eight different 
>possible encodings of the integer 1

I hereby rest my case about confusion and non-interoperability caused by 
going with the X9.42 version :-).

Peter.

---

From: "Tolga Acar" <[email-masked]>
Date: Fri, 30 Jul 1999 09:49:53 -0600

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 <[email-masked]> 7/31/99 2:47:28 >>>
Andrew Farrell <[email-masked]> 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.