Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX

[Roland Lockhart <roland.lockhart@xxxxxxxxxxx>]

Hi,

I am not a regular on this mailing list and maybe I'm a bit late, but
the OCTET STRING versus INTEGER debate was brought to my attention and
I'd like to add my two cents.

I oppose the issuing of new OIDs and parameter definitions. I believe
that INTEGER encoding is absolutely the right way to respresent the
quantities in question since they are in fact mathematical integers. The
INTEGER encoding is perfectly suited because it unambiguously defines
how to respresent the number, i.e., in two's complement form, fewest
octets possible, with the most significant octet first.

I think the answer to the leading 00 octet issue is implied in the
definition of an INTEGER: two's complement with the fewest octets
possible. For example, under these rules the number +128 cannot be
represented in a single octet, so it becomes two octets: 0x00, 0x80. The
"Layman's Guide to a Subset of ASN.1, BER, and DER" by Burt Kaliski at
RSA Labs has a good summary of all this. I do agree that the official
ASN.1 specs are less clear than they could be on this point!

I am surprised that "most current software and certs are wrong". I have
seen a few wrong ones and lots of right ones from various product
vendors.

Some ASN.1 compilers, including the one we use, cannot handle large
INTEGERS (bigger than 32 bits). However, we've been able to work around
this limitation quite easily.

The INTEGER precedent has been set in a number of places (PKCS-1, X9.57,
etc.) and I think any change would lead to confusion and
interoperability problems.

- cheers,
  Roland Lockhart
  Entrust Technologies Ltd.
  Ottawa, Canada

>
>----------
>From:  David P. Kemp[SMTP:dpkemp@MISSI.NCSC.MIL]
>Sent:  December 16, 1997 9:34 AM
>To:    IETF-PKIX@LISTS.TANDEM.COM
>Subject:       Re: [IETF-PKIX] Encoding of INTEGER fields in PKIX
>
>Thanks to all who replied, either publicly or privately, to my question
>on INTEGER encoding.
>
>The consensus was unanimous (a rare event!) that:
>
>  a) cryptographic bignums should *not* be typecast to signed integers at
>     the ASN.1 coding interface, and therefore must always be encoded
>     such that the MSBit is zero,
>
>  b) most current software and the certs floating around are wrong, and
>
>  c) it was a mistake to use INTEGER for cryptographic keys, parameters,
>     signatures, etc, and that these fields should have been defined as
>     OCTET STRING or BIT STRING when the algorithmIdentifiers were
>     created.
>
>I will therefore correct the PKIX part 1 examples to add a leading 00
>octet where needed, and hope that future algorithmIdentifier definitions
>will use OCTET STRING instead of INTEGER.
>
>Is it too late for x9 to assign new OIDs for dsa and rsa using OCTET STRING
>values, and have PKIX recommend support for the new algorithmIds?
>
>