[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?