On Fri, 05 Nov 1999 13:06:42 GMT, Dr Stephen Henson wrote:
> Chris Ridd wrote:
> > We'd also potentially run into the problem with some vendors assuming
> > that T.61 doesn't actually mean T.61, it means ISO-8859-1. So
> > converting these bogus "T.61" values would produce UTF-8 with bogus
> > characters.
> >
>
> Thats generally the problem with T61. The whole mess if descibed in
> Peter Gutmann's X509 style guide. Whatever we do its likely to be
> incompatible with some vendors implementation.
>
> We could follow the advice there and treat it as ISO-8859-1 and possibly
> additionally complain loudly if it sees any shifting or escape codes
> present or optionally use the hex encoding. Getting a specification for
> this might be the hardest part.
Treating it as 8859-1 is just plain wrong, and would penalise vendors
who bothered implementing the standards correctly (such as ourselves,
as it happens.)
> [Anyone know if Netscape/MSIE handles shifts and escaping with T61 BTW?]
I think they treat it as 8859-1.
> If a vendor wants to handle things properly then they should be using
> BMPStrings anyway. Netscape in this regard doesn't because it crashes on
> BMPStrings and UTF8Strings.
Oh, wonderful.
> The original SSLeay code was badly broken and attempted to manually
> correct string types in req/ca. It used Printable, IA5 and T61s and it
> could illegally put IA5Strings in some fields. BMPStrings and
> UTF8Strings weren't used at all.
>
> It should be a bit better now. There's a function which will copy a
[...]
I'll have to think a bit more about this. Thanks for all the feedback
so far!
Cheers,
Chris
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
