On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann
wrote:
> Victor Duchovni <Victor.Duchovni MorganStanley.com> 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 .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 majordomo metzdowd.com
|