ando@sys-net.it wrote:

ando@sys-net.it 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.