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

[John Lowry <jlowry@xxxxxxx>]

I disagree that INTEGER is incorrect.  It is correct by
definition.  Those quantities are, in fact, integers.
I do not support the issuing of new OIDs and parameter definitions.

The observation that the encoding of INTEGER is general and typically
results in an inefficient encoding (one additional byte) when applied
to cryptographic integers shouldn't cause any panic.  If efficient
encoding were paramount then ... but I won't go down that path ...  :-)

Other notes:
        It is a rare machine that can handle interesting (e.g. large)
        bignums as signed or unsigned native integers.  I know of
        no one who has made the mistake of typecasting - probably because they
        don't have the right machine.  Have you got a machine with
        2048-bit integers ?   Even 1024 would suffice for me ...

        I don't know what "most current software and the certs" are.
        I suspect that your observation is that folks who try to
        write an ASN.1 DER encoder/decoder have their work cut out
        for them.  They have no excuses though - there are several
        publically available encoder/decoders that they could have
        used as a reference or just plain used.


At 09:34 AM 12/16/97 -0500, David P. Kemp wrote:
>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?
>
>