Chris Ridd wrote:
>
> On 03 Nov 1999 20:04:07 EST, William M. Perry wrote:
> > "Ramsay, Ron" <[EMAIL PROTECTED]> writes:
> >
> > > I don't have an opinion on producing LDAP DNs but I think you should use
> > > the v3 form (RFC 2253) rather than the v2 form.
> >
> > Well, 1485 is obsoleted by 1779, which is then in turn obsoleted by 2253.
> > I'd say go with the least obsolete format, which seems to be 2253, which is
> > useful outside of LDAP.
> >
> > -Bill P.
>
> Yes, I considered RFC 2253. The problem with this is that all the
> attribute values will need to be converted into UTF-8.
>
> The problem with that is two-fold:
>
> 1) Converting T.61 into Unicode is non-trivial;
> 2) Useful type information is lost, ie was the value
> PrintableString/T.61/etc. See RFC 2253 section 7.2 for some discussion
> on this, and why this is a problem.
>
> I think the conversion problem is the worst problem. To avoid problem 2
> the string DN could have the hex form, however that wouldn't make it
> IMO a very useful string.
>
> 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.
[Anyone know if Netscape/MSIE handles shifts and escaping with T61 BTW?]
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.
> Sticking with RFC 1779 means problem 1 goes away, but a third problem
> appears:
>
> 2) BMPString/UniversalString values can't be represented.
>
> There appear to be some changes in the CVS repository to move towards
> supporting the BMPString choice of DirectoryString.
>
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
multibyte string in various format to its "minimal" string type and its
been merged with the X509_NAME code. Just by passing one of the
MBSTRING_* values as the "string type" will make the relevant function
lookup the field, check the length limits and use the correct string
type.
Its also possible to change how DirectoryString is handled using a
default setting.
It doesn't follow RFC2459 by default because of the aforementioned
broken Netscape.
It doesn't attempt to do anything clever with T61s yet other than copy
values to/from them if they fit.
This is all very experimental and is only supported in 'req' at present.
It will be in 'ca' in due course.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
