RE: ASN.1 types for Distinguished names (was: Re: Distinguished n ames and

John Lowry <jlowry@bbn.com> Thu, 03 April 1997 17:47 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id JAA27715; Thu, 3 Apr 1997 09:47:27 -0800
Received: from dave.bbn.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id JAA27710; Thu, 3 Apr 1997 09:47:25 -0800
Received: (jlowry@localhost) by dave.bbn.com (8.6.9/150.200.504) id MAA26352; Thu, 3 Apr 1997 12:45:35 -0500
Date: Thu, 03 Apr 1997 12:45:35 -0500
From: John Lowry <jlowry@bbn.com>
Message-Id: <199704031745.MAA26352@dave.bbn.com>
To: briank@terisa.com, Holger.Reif@PrakInf.TU-Ilmenau.DE, AndrewP@esd.nec.com.au
Subject: RE: ASN.1 types for Distinguished names (was: Re: Distinguished n ames and
Cc: ietf-pkix@tandem.com, ssl-users@mincom.oz.au
X-Sun-Charset: US-ASCII

A couple of datapoints with NO assertion as to correctness:

BBN systems default to a method of "least inclusive" set when trying 
to determine which character encoding to use.  That means we try to 
encode as PrintableString first, then T61 and finally UniversalString.  
(This behavior can be configured and specified to be different is desired.)

We note that Microsoft IE seems to go from PrintableSting straight
to UniversalString encodings with the net result that many certificates
will have multi-byte encodings.

Are there any other datapoints ?

John Lowry

> From <@suntan.tandem.com:chandras@loc201.tandem.com>  Wed Apr  2 21:28:08 1997
> From: Andrew Probert <AndrewP@esd.nec.com.au>
> To: "'Brian Korver'" <briank@terisa.com>, Holger.Reif@PrakInf.TU-Ilmenau.DE
> Cc: ietf-pkix@tandem.com, ssl-users@mincom.oz.au
> Subject: RE: ASN.1 types for Distinguished names (was: Re: Distinguished n
> 	ames and
> Date: Thu, 3 Apr 1997 12:13:46 +1000
> X-Priority: 3
> Mime-Version: 1.0
> 
> Further to my previous email, here is a comment from Microsoft:
> 
> <snip>
> We have UNICODE X.509 Name ASN.1 encode/decode routines. When converting
> UNICODE to a T61String we convert to UTF8. The UTF8 represents the
> characters 0 .. 0x7f as a single byte, 0x80 .. 0x7ff as two bytes, and
> 0x800 ..0xffff as three bytes. UTF8 is also being used by Java.
> 
> <snip>
> 
> > -----Original Message-----
> > From:	Brian Korver [SMTP:briank@terisa.com]
> > Sent:	Thursday, April 03, 1997 3:32 AM
> > To:	Holger.Reif@PrakInf.TU-Ilmenau.DE
> > Cc:	ietf-pkix@tandem.com; ssl-users@mincom.oz.au
> > Subject:	Re: ASN.1 types for Distinguished names (was: Re:
> > Distinguished names and
> > 
> > 
> > Holger Reif writes:
> > > 
> > > Hi,
> > > 
> > > this seems to be a nice thread to jump in ;-)
> > > 
> > > I noticed that many of the X.520 Selected attributes are of type
> > DirectoryString
> > > which in turn is a choice of teletexString, printableString and
> > universalString.
> > > Does anybody know when which Form is to be used and wether a
> > transformation 
> > > between these types (if possible) is allowed and gives equal
> > meaning. 
> > 
> > BMPString has basically replaced UniversalString because, I have
> > been told, nobody used UniversalString.  I can be believe this.
> > 
> > Both TeletexString (T61String) and PrintableString have constraints as
> > to what can be placed in them.  So for instance if you need to use a
> > character such as '@', you cannot use PrintableString.
> > 
> > I'm unaware of any equality rules to use when comparing strings of 
> > unequal type.  I assume that most implementations assume that strings
> > of unequal type are by definition not equal.  IMHO this is the best
> > approach because of the lack of well-defined equality matching rules.
> > 
> > I'm also unaware of any rules for "which string do I use" when there
> > are multiple string types to choose from.
> > 
> > 
> > > Of course, if it's within a SIGNED context then the answer is clear:
> > 
> > > one can't change the types. But in other cases?
> > 
> > brian
> > briank@terisa.com
>