Re: (ITS#5070) Issues in X.509 certificate parsing

[hyc@symas.com]

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.
-- 
   -- 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/