Re: DName encoding (was:KeyName white space)

Which element types does this apply to, only the RFC2253 X509IssuerSerial 
and X509SubjectName, or KeyName as well (which can be anything *including* a 
DNAME). I assume MgmtData and PGPKeyID are left as a string without further 
specification.


At 15:27 6/12/2001, Donald E. Eastlake 3rd wrote:

>Since no one has responded to my message below, I assume that we have
>adopted Gregor's proposal and that, except as may be provided in RFC
>2253, whitespace is significant.
>
>Donald
>
>From:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
>Message-Id:  <200105310255.WAA0000031182@torque.pothole.com>
>To:  w3c-ietf-xmldsig@w3.org
>Date:  Wed, 30 May 2001 22:55:30 -0400
>
> >It seems to me that we need to come to some sort of conclusion on
> >this... Maybe people think we did and I missed it, in which case I
> >hope they will set me straight.
> >
> >The following proposal by Gregor for encoding STRINGS in DNames does
> >not seem to have been refuted, but do we need to say more about
> >leading and trailing whitespace on the DName as a whole?
> >
> >Thanks,
> >Donald
> >
> >From:  "Gregor Karlinger" <gregor.karlinger@iaik.at>
> >To:  "Tom Gindin" <tgindin@us.ibm.com>, "Merlin Hughs" 
> <merlin@baltimore.ie>,
> >            <duerst@w3.org>
> >Cc:  <w3c-ietf-xmldsig@w3.org>
> >Date:  Wed, 16 May 2001 15:13:14 +0200
> >Message-ID:  <LBEPJAONIMDADHFHAEAOMELJCFAA.gregor.karlinger@iaik.at>
> >In-reply-to: 
> <OF8536EC68.279166CB-ON85256A4D.005E2175@somers.hqregion.ibm.com>
> >Subject:  DName encoding (was:KeyName white space)
> >
> >All,
> >
> >I have cited the most important statements (from my point of view)
> >regarding DName encoding below. I would like to make the following
> >proposal for a guidline that should appear in XML-Signature on how
> >to encode a strings in a DName in XML-Signature relevant structures
> >(IssuerName, SubjectName):
> >
> >o Consider the string as consisting of unicode characters.
> >
> >o Escape occurences of the following special characters by prefixing
> >  it with the "\" character:
> >
> >    - a "#" character occurring at the beginning of the string
> >    - one of the characters ",", "+", """, "\", "<", ">" or ";"
> >
> >o Escape all occurences of ASCII control characters (Unicode range
> >  \x00 - \x20) by replacing them with "\x" folloed by a two digit
> >  hex number showing its Unicode number.
> >
> >Since a XML document logically consists of characters, not bytes
> >(Thanks Martin for reminding me ;-) the resulting unicode string is
> >finally encoded according to the character encoding used for producing
> >the physical representation of the XML document (But this is not in
> >scope of the guidline that should be taken into the XML-Signature
> >specification ...)
> >
> >Liebe Gruesse/Regards,
> >---------------------------------------------------------------
> >DI Gregor Karlinger
> >mailto:gregor.karlinger@iaik.at
> >http://www.iaik.at
> >Phone +43 316 873 5541
> >Institute for Applied Information Processing and Communications
> >Austria
> >---------------------------------------------------------------
> >
> >
> >### Tom Gindin ###
> >
> >[...]
> >>      The situation is actually even more confusing than that.  The rules
> >> seem to be, for HT, LF, FF and VT, something like the following:
> >[...]
> >
> >### Merlin Hughs ###
> >
> >[...]
> >> The escaping is useful because:
> >>
> >>            <DName>CN=foo
> >>            </DName>
> >>
> >> According to RFC 2253, this states that the common name is
> >> foo<LF><TAB>. However, if you trim() the text value then you
> >> would get common name foo. Requiring escaping of ASCII controls
> >> would result in CN=foo\0A\09 (if that is what is meant) which
> >> is unambiguous and can be safely indented, whitespace formatted
> >> and trim()ed. It would also eliminate a few other potential
> >> ambiguities:
> >[...]
> >> is significant. If we require that all significant ASCII
> >> controls be escaped, then trimming and formatting involving
> >> newlines and tabs will be safe, and meaningful whitespace in
> >> dnames will be explicit.
> >
> >### Martin Duerst ###
> >
> >An XML document consists of characters, not bytes. And in
> >content, each character can be escaped by a numeric character
> >reference. Therefore, you can have a document only encoded
> >in us-ascii, but will lots of &#dddd; (or &#xhhhh;); this
> >will transport any character in Unicode, and a browser
> >will display it correctly (assuming it has the right font).
> >
> >> > There's another issue that seems relevant. RFC 2253 states
> >> > that strings must be converted to UTF-8 and then the escaping
> >> > rules must be applied. Do we honour this, or should we UTF-8
> >> > decode the RFC2253 string before embedding it in the text node.
> >> >
> >> > Essentially, should the final example in RFC 2253 be encoded
> >> > in XML as:
> >> >
> >> > UTF-8 encode and require ASCII escaping of high-bit-set chars:
> >> >   SN=Lu\C4\8Di\C4\87
> >
> >This would be okay.
> >
> >[...]
> >> > De-UTF-8 and embed the Unicode original:
> >> >   SN=Lu?i? (where ? is the original character)
> >> >
> >> > The last seems like the best option to me.
> >
> >I agree. But it has to be spelled out clearly, and tested.
> >
> >############
> >


--
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Tuesday, 12 June 2001 16:43:54 UTC