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 would go with the hex representation. IMO LDAP/X.500 has long needed a hex 
integer syntax (or at least some other binary base, but hex is probably best), 
since we can parse/validate them bytewise without any word size limitations or 
expensive conversions.

And IMO GSER is a giant leap backward in network protocol efficiency. If it 
were merely a UI format, like LDIF, that would have been ok, but over the wire, 
that's ridiculous. (But that's a separate discussion entirely...)
-- 
   -- 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/