certificate list parsing issues

[masarati@aero.polimi.it]

I recently hit a pretty long certificate list with what appears to be crap
past the end of its valid portion.  I have no indication about how this
was generated, but it is supposed to be in production within a CA,
initially using a release of OpenLDAP without detailed CL validation in
place (remember this was released in 2.4).  I'm not posting this to the
ITS because it's data I'm not allowed to disclose.

To make a long story short, I got the CL in LDIF format; I could convert
it to DER and have openssl crl play with it.  Apparently, openssl crl
recognizes it and deals with its contents correctly, but our CL validator
fails because when it expects to be at the end there is still stuff to be
parsed (some 40KB of what appears to be garbage).  Howard found a small
issue in CL validation and fixed it (schema_init.c 1.459 -> 1.460), but
nevertheless the issue remains.  Howard also discovered that regenerating
the CL in DER form using openssl clr would yield a shorter certificate
that passes OpenLDAP's validator.

I'm raising it here because we need to understand how important it is for
us to be able to deal with broken CL, and how broken we can accept them to
be.  In this case, the CL looks fine until the end, with garbage at the
end.  This could be tolerated.  Or, we could just ignore any type of
error, as soon as we don't need to deal with its contents (slapd is merely
acting as a container, and needs not know whether it's containing good or
bad data).  This latter argument may be not valid as soon as our slapd
takes over as much certificate handling as possible, performing
certificate validation internally rather than delegating it to some
external package (I understand Howard would probably like to follow that
path, eventually).

Unless there is strong opposition, I'd relax the last check about being at
the end of the CL, in order to accept CL with this type of brokenness,
possibly logging about the issue.

p.