IA5 String...

[Brad Knowles]

On Feb 26, 11:12am, Jueneman at gte.com wrote:

> >Wow, is this true?  I dont think so.  The CCITT document I have (CCITT
> >T.50) mentions that an @ sign (Commercial at) is a member of the IRV.
> >>From what I understand IA5 basically means US ASCII.  

    [ ... deletia ... ]

> If people are going to criticize X.509, they ought to at least get
> their facts straight, beginning with the difference between Printable
> String (standardized around the time of the IBM 1403 printer with its
> 48 character print chain) and some of the more extended alphabets.  In
> particular, X.500 has been amended to include BMPString within
> DirectoryString, and BMPString is essentially Unicode.  Now, there may
> be some who would argue that a 16 bit character isn't sufficient to
> represent every language in the galaxy (Old High Martian may have some
> additional requirements), but as a first approximation it should
> certainly good enough.

    I don't recall who made the comment that X.509 used IA5, but I was
the one who noted (wrongly?) that IA5 had no representation of the at
sign ("@"), and instead used a lower-case letter "a" inside of
parentheses.

    I remembered it then in context with all the work I'd done on the
X.400 projects tying together the DISA cc:Mail and the OSD MS-Mail
backbones, and I'm still quite convinced that at least in the context
of the systems we were using, this is exactly what IA5 meant.  There
was much wailing and gnashing of teeth over this one, because it made
our directory sync and directory query stuff all that much more of a
pain.  It could even have contributed to the stillbirth of those
projects, the omnipresent and oppressive spectre of DMS not
withstanding.


    Now, perhaps the definition of IA5 has changed, and if so, then
that's great.  Or maybe DISA and the X.400 we had (not too unrelated
to the formless but very chilling DMS) were badly broken and this is
what they made us live with.


    In any event, if X.509 certificates don't have this problem, then
that is wonderful.  It's another reason why we might want to support
X.509v3 certificates as an absolute minimum acceptable standard.

> And one of the virtues of ASN.1 is that a compliant implemtnation
> shouldn't have to be concerned with such details as the alphabet that
> is used.

    I await the wisdom of Steve Crocker to be visted upon us regarding
the use of ASN.1.  I do know that, from general principle, the mere
concept of being forced to go out and buy something like an ASN.1
compiler just so that I can implement a parser for a format seems
abhorrent in the extreme.  Not to mention the additional complexity,
unwieldiness, and sluggishness it lends to the final product.

-- 
Brad Knowles                           MIME/PGP: BKnowles at aol.net
    Mail Systems Administrator          <http:www.his.com/~brad/>
    for America Online, Inc.                   Ph: (703) 453-4148