W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: AW: KeyName white space

From: Tom Gindin <tgindin@us.ibm.com>
Date: Tue, 15 May 2001 06:55:24 -0400
To: merlin <merlin@baltimore.ie>
Cc: "Gregor Karlinger" <gregor.karlinger@iaik.at>, w3c-ietf-xmldsig@w3.org
Message-ID: <OF9C26CAA1.8F4CCD92-ON85256A4D.003AACA8@somers.hqregion.ibm.com>

     Actually, section 4 of RFC 2253 does lay some clear requirements on
the parsing application.  Spaces must be ignored if they are immediately
before the comma, the plus sign, or the equal sign, and unescaped
semicolons must be treated as equal to commas.  There's no requirement
explicit in that section for the beginning or end of the full DN, however.
It's just that the creator of the DN is required not to end a given value
with unescaped whitespace.  Since the format of attribute type seems to
require it to start with an alphanumeric, trimming any leading whitespace
would be safest.
     So I think considering unescaped spaces at either end of a DN to be
part of it is actually in violation of RFC 2253.  However, and very
strangely, no similar requirement exists for horizontal tab or line feed,
while carriage return must be escaped according to RFC 1779 but not 2253.
Should we require that XMLDSIG implementations escape all ASCII control
characters as well?

          Tom Gindin


merlin <merlin@baltimore.ie>@w3.org on 05/15/2001 05:49:55 AM

Sent by:  w3c-ietf-xmldsig-request@w3.org


To:   "Gregor Karlinger" <gregor.karlinger@iaik.at>
cc:   w3c-ietf-xmldsig@w3.org
Subject:  Re: AW: KeyName white space



Hi Gregor,

I qualified RFC 2253 with 'I think' because I did not
have documentation in front of me.. You're right, it
is not explicit, but I think it is in the spirit of the
document and its requirements of flexibility in the
handling of whitespace. In particular, spaces at the
end of attribute values must be escaped, which suggests
(to me) that unescaped spaces at the end may be ignored.

But you are right, an XMLDSIG statement would be in
order, and would appear to be compatible with RFC2253.
It should probably state that escaped spaces at the end
must be preserved.

Merlin

r/gregor.karlinger@iaik.at/2001.05.15/11:25:32
>Merlin,
>
>> Agreed. DNames already have this property (from RFC 2253 I think),
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>What do you mean? Currently XML-Signature does not say anything about
>stripping the white space, nor is there a requirement in RFC 2253 to
>be tolerant regarding whitespace at the beginning or at the end of a
>DName string.
>
>We currently make a trim() prior to parsing the DName string in our
>implementation, but I would like to see an appropriate sentence in
>XML-Signature.
>
>> and I believe so do base-64 coded data as well as integers, so
>> this would unify pretty much all of our text handling.
>
>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
>---------------------------------------------------------------
>
>


-----------------------------------------------------------------------------

Baltimore Technologies plc will not be liable for direct,  special,
indirect
or consequential  damages  arising  from  alteration of  the contents of
this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com
Received on Tuesday, 15 May 2001 06:56:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:04 UTC