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

["Phillip H. Griffin" <asn1@xxxxxxxxxxxxxx>]

Roland Lockhart wrote:
>
> 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 agree.

>
> 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!
>

If you mean the former ASN.1 standards, X.208/209, I agree. But numerous
defects in these works have been corrected in the current standards,
ASN.1:1994.

> 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.

Many of the vendors working on the SET protocol, which makes heavy use
of
X.509v3 and the ASN.1:1994 standards use an ASN.1
compiler/code-generator
from OSS (www.oss.com) that correctly supports these integer
requirements,
even for integer values which exceed the maximum integer representation
on a given machine. This is accomplished by adding a local directive,
--<HUGE>--, to the SET ASN.1. So, for these implementors, there is no
need for new identifiers.

>
> 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?
> >
> >

Phil
--
Phillip H. Griffin         Griffin Consulting
asn1@mindspring.com        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------