Howard Chu wrote:
In general, the codebase we inherited from UMich has tended to treat
everything as BLOBs (or worse yet, ASCII strings). In my opinion that
completely undermines the point of ASN.1; we should make it a priority
to properly parse everything according to its ASN.1 definition as a
precursor to promoting more application-specific syntaxes down the road.
E.g., I think it's stupid that most LDAP schemas use DirectoryString for
everything, with some associated comments (not visible in the schema
definition) describing the actual intended values for an attribute. LDAP
needs proper syntaxes for URLs, IP addresses, email addresses, etc. etc.
etc. and we need to get everyone out of the mindset of "everything is a
string of octets and we don't know what's inside".
Of course we don't need to go overboard; we don't need to do a full JPEG
decompression on every incoming jpegPhoto attribute. But we probably
ought to check the first few octets for the signature/magic numbers...
But in the case of objects that are part of the actual X.500 spec (such
as certificates and certificate lists) we will typically need to have
deep knowledge of their structure (at least to extract the relevant DNs)
and there's no excuse for a directory software package not to understand
these aspects of the directory specification.
Agreed. I'll distinguish between "it has to be formally correct" and "I
need it to be formally correct to work properly". The latter would be
the case of X.500 stuff, the former could be relaxed when data sanity is
the matter of other pieces of software.
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.
I guess it would be OK to log the issue and return success. One other
check we might do instead, is to remember the initial Sequence length,
and make sure we've hit the proper end-of-sequence location.
I'll fix it this way.
p.
