W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > June 2007

Re: DName space encoding

From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
Date: Mon, 18 Jun 2007 21:54:06 +0200
Message-ID: <4676E2DE.1030608@iaik.tugraz.at>
To: public-xmlsec-maintwg@w3.org
Dear all,

maybe it's worth to have a look at the postings following at the end of
this mail.
After reading them I would presume the last "\20" escaped characters
sole purpose was to allow people to add whitespace after the last
AVA-Value.
That whitespace should be considered insignificant for the DNAME.

The following shows the discussions essence, however  I strongly doubt
that there is a "real" value in allowing this for future signature
creation. It's rather confusing and we should drop it.

Why would someone really care to type a DNAME as follows

  <DName>CN=foo \20
  </DName>

instead of

  <DName>CN=foo \ </DName>

or am I missing something here?

My proposal hence is still to be more stringent about the RFC 2253
interpretation and not to work with plain vanilla whitespace trimming
that makes a "\20" ending necessary for a DNAME. (cf. sections ##3## and
##4## in the proposal in
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0016.html).

The burden to trim every whitespace but the one whitespace preceded by a
"\" is minimal to any average programmer.

Nevertheless please make up your own mind by following the discussion I
discovered in the archives and let me know whether you agree.

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0140.html :
> > The escaping is useful because:
> > 
> >            <DName>CN=foo
> >            </DName>

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0159.html :
> Taking the whole RFC 2253 encoded name leads to the problem that
> insignificant white space will turn into significant whitespace
> after one round of encoding and decoding

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0118.html
> 1. The schema will not prevent people from having leading or trailing
> whitespace in the content of KeyName (and it shouldn't!).  The spec will
> just say that any leading and trailing whitespace MUST be trimmed to obtain
> the actual KeyName.
>
> 2. The code will look something like this:
>
>   Node nodeKeyName = XPathAPI.selectNode(doc, "//KeyName/text()");  // get
> the text content of <KeyName>
>   String strNodeKeyName = nodeKeyName.nodeValue();
>   String strKeyName = strNodeKeyName.trim();
>   KeyResolver.resolveWithKeyName(strKeyName);
>   


Konrad



-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
https://www.iaik.tugraz.at/aboutus/people/lanz
http://jce.iaik.tugraz.at

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm



Received on Monday, 18 June 2007 19:54:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:00 GMT