Steve Crocker writes:
3. So why not simply permit the use of ENs? A very good idea. We've
already said we'd do this. But then a funny thing happened. The
X.DN structure is a tad too restrictive. I'm told that some of the
normal EN special characters aren't permitted in ordinary text
values. Also, it's not clear what OID to use.
I _knew_ I should have paid more attention last year when
everyone was trying to come up to speed on ASN.1 notation. I've spent
the last hour searching without success through the '93 version of X.500,
trying to find the precise definition of DirectoryString (used in names, street
addresses, etc.) and PrintableString (used for CountryName, SerialNumber,
TelephoneNumber, DNQualifier, and DestinationIndicator).
Can someone point me to the correct reference, and perhaps answer the
question in passing?
I understand, but have not confirmed, that organizationName="AT&T"
or "Ringling Bros., Barnum & Bailey", or "C&P Telephone", etc.,
would not be permissable, because the ampersand is not in the DirectoryString
set. If so, I think this is _unacceptable_, and a different string syntax
should be
used or at least allowed for names. A user or his organization should not have
to
change his name in order to be listed in the directory or to receive a
certificate!
We also need to check for the admissability of @, %, <, >, and perhaps
a few other special characters.
In addition, as a result of the NAFTA treaty, we had better start worrying more
about international applications as well. That means supporting the Canadian
French and Mexican Spanish, as well as English character sets. If international
EDI takes off, all of the other languages will have to be supported as well --
not
just the Western European languages but the Greek, Cyrillic, Hebrew, Arabic,
Thai, Hindi, Vietnamese, Katakana, and Korean alphabets as well. I haven't any
idea what will be done with Chinese ideographs.
Bob