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