Dr Stephen Henson wrote:
>
> Michael Str�der wrote:
> >
> > > o Steve is currently working on
> > > Various X509 issues: character sets, certificate request
> > > extensions.
> >
> > I am very much interested in learning more about these character set
> > issues.
>
> One big issue at present: YOU CAN'T USE NETSCAPE!! It crashes when
> BMPStrings or UTF8Strings are present in things like S/MIME email.
(Sigh!) You're right. I did some more testing with Netscape Communicator
4.7: If a S/MIME messages contains a cert which contains BMPString in
cert DN NS crashes during displaying the message no matter if opaque
signing or not. If the message does not include the cert it is displayed
but off course the signature cannot be verified. I wanted to download
the cert into NS via my CGI-BIN get-cert.py. NS for Windows crashes
during any attempt loading a cert issued for IE. NS for Linux just
refuses to download the cert. Obviously the Linux and the Windows
version behave differently regarding character sets. And there are even
more character set confusions in Netscape concerning LDAP... :-(
> IE5 supports BMPStrings but not UTF8Strings. Its Xenroll enrollment
> control use BMPStrings but can be persuaded to use T61Strings.
I switched on this (certHelper.EnableT61DNEncoding = True) but Netscape
still refuses to download certs via CGI-BIN issued for IE.
> My limited knowledge of other languages suggests Cyrillic isn't in
> ISO-8859-1 though.
It's something completely different but rather simple. The bit 0x80 is
set for every character a..zA..Z. Funny, the russian user reported that
under Linux (Netscape and pyCA server) everything went fine. The KOI-8
characters were encoded like T.61 and displayed in Netscape communicator
(KOI-8 aware version). Well, this won't be interoperable in a global PKI
world and therefore does not make sense.
I hoped that it can be mapped to something like Unicode (UTF-8) and
would be world-readable then.
> I assume the SPKAC doesn't look right?
The SPKAC is fine. Everything in pyCA works just fine for NS Comm. and
M$ IE as long as I am simply using ISO-8859-1 characters...
> In future OpenSSL might allow the
> SPKAC to use UTF8 encoding and handle things that way.
:-)
> All academic
> though because this wont work with Netscape.
:-(
> > A russian pyCA user requested support for his KOI-8 (kyrillic) based
> > web
> > environment and I am not quite sure how this can be achieved with
> > OpenSSL...
>
> Tricky at present. The main problem is how to display international
> characters on all platforms.
Well, as long as there isn't stable support for UTF-8 in all client
software we can forget about this.
> What is likely to happen is that the 'ca'
> utility will not be able to properly display the string but it should
> still sign the request properly.
I understand your statement this way: There is no way to tell the
application which character set the DN of a X.509 cert contains. :-(
> If there's a way to display BMPStrings then this shouldn't be a problem:
> you might even be able to parse the output of 'ca' and handle it
> properly.
Displaying BMPStrings is no problem in pyCA as long as they contain only
ISO-8859-1 characters. Other mappings are unknown.
> I think the best OpenSSL can do in the short term is to give some
> options on how these things are displayed: for example converting to
> enescaped UTF8 which should then be displayed properly on a "UTF8
> console".
All academic at the moment as you mentioned above.
I can store these test certs on my web server for easy displaying and
downloading if you're interested in that. Hmm, I could also set up a
"Test CA" for all people with foreign client software to collect test
data.
Ciao, Michael.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
