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