[Date Prev][Date Next]
Re: (ITS#5070) Issues in X.509 certificate parsing
> email@example.com wrote:
>> I've an issue with X.509 certificate parsing in HEAD/re24. The certificate,
>> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails
>> to parse it because it is an integer with length equal to 9, which is larger
>> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER
>> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time
>> to get past the sizeof(ber_int_t) limitation...
> ... which would violate RFC 4511 where it states that INTEGER means from
> 0 up to 2^31-1... I have a simple solution for this problem, at the
> cost of partially violating rfc 4523: if an integer is larger than
> 2^31-1, it could be represented in the certificateExactMatch
> normalization in hexadecimal form, much like OpenSSL does. This would
> increase interoperability with OpenSSL and be at least self-consistent,
> since all serialNumbers that large would be consistently expanded that
> way. Another solution, preserving the decimal representation, would
> probably require some arbitrary precision support from external
> libraries. If there's consensus, I'd post my simple patch.
I just got tripped trying to import an LDIF with a cert with 16 byte
SerialNumber. I've patched this to just use the same hexadecimal format that
OpenSSL uses when the number is larger than ber_int_t. We really don't want
the format to change just because someone has a BigNum library available; it
needs to stay consistent.
Normalizing to a string format like this still seems pretty gross, but I guess
that's the best we can do given dumb clients that aren't aware of schema.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/