On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >It took reading the code to determine the following:
> >
> > - ASN.1 Strings extracted from X.509v3 certs are not validated for
> > conformance with the declared character syntax. Strings of type
> > PrintableString or IA5String may hold non-printable or non-ASCII
> > data.
>
> Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning
> behind this. I don't think any ASN.1-using security toolkit since TIPEM has
> done character-set checking, it would fail to verify a large chunk of the
> certs out there (I once had a TIPEM user complain to me that they had to stop
> using it specifically because it would reject invalid character strings, which
> encompassed a nontrivial portion of their user base).
I understand the motivation, and agree that this is the right thing to
do, indeed in the application (Postfix) I just map the content to UTF8
(using the identity mapping where appropriate) and then decide what
characters are acceptable, I don't need the original ASN.1 string type
after the string is in canonical form.
My point was that not all the fine details are always documented (even in
closed source libraries with funded documentation teams), and having the
source allows me to move beyond cargo-cult programming and to understand
how to use the library correctly. I guess this is RTFS to extract the
semantics out of the syntax documentation.
In addition, I think that the library should-provide idiot-friendly
interfaces for handling ASN.1 string data holding security sensitive
information (CommonName, subjectAltName, ...), because the code one
finds and copies from other projects is not sufficiently careful.
RFC 3820 suggests that it is OK to consider strings of different ASN.1
types as different content for comparison and then, by implication,
just compare the raw content when the types match, but what one finds
is that applications mostly IGNORE the ASN.1 string type and use the
raw octets for comparison, display, ... and they do that at their peril.
It is also almost universal practice (in C code anyway) to not check
for embedded NUL in the ASN.1 strings, and I wonder how may CAs would
issue "eve.biz" a cert for "alice.com\0.wwww.eve.biz"? (If the CA's code
handles NUL in octet strings as just another byte, this could happen.
But we digress again, the source is useful in any case, and not just
for full code reviews, used with care it is the ultimate documentation.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAIL Morgan Stanley confidentiality or privilege,
and use is prohibited.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
