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

Re: AW: AW: KeyName white space

From: Tom Gindin <tgindin@us.ibm.com>
Date: Tue, 15 May 2001 13:19:08 -0400
To: merlin <merlin@baltimore.ie>
Cc: "Gregor Karlinger" <gregor.karlinger@iaik.at>, w3c-ietf-xmldsig@w3.org
Message-ID: <OF8536EC68.279166CB-ON85256A4D.005E2175@somers.hqregion.ibm.com>

     The situation is actually even more confusing than that.  The rules
seem to be, for HT, LF, FF and VT, something like the following:

before +  Significant.
before =  Invalid
before , or ;  Discard
after +        Significant
after =        Significant
after , or ;   Discard

     But for CR, because of RFC 1779 backward compatibility, they are quite
before +  Discard.
before =  Invalid
before , or ;  Discard
after +        Discard
after =        Discard
after , or ;   Discard

     Should normalization software need to deal with this?


merlin <merlin@baltimore.ie>@baltimore.ie on 05/15/2001 12:26:03 PM

Sent by:  merlin@baltimore.ie

To:   "Gregor Karlinger" <gregor.karlinger@iaik.at>
cc:   "Tom Gindin" <tgindin@us.ibm.com>, w3c-ietf-xmldsig@w3.org
Subject:  Re: AW: AW: KeyName white space

The escaping is useful because:


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

To reiterate what Tom said, RFC 2253 states that ignorable
whitespace may surround the comma or semicolon, then it says
that ignorable spaces (as oppose to whitespace) may precede
the comma or plus and may surround the equals. It also states
that spaces at the end of an attribute value must be escaped.

In other words, non-space whitespace around a plus or equals
or at the end of an attribute value (e.g., the end of a dname)
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.


>>      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
>> while carriage return must be escaped according to RFC 1779 but not
>> Should we require that XMLDSIG implementations escape all ASCII control
>> characters as well?
>Why would you like to require such an escaping?
>Liebe Gruesse/Regards,
>DI Gregor Karlinger
>Phone +43 316 873 5541
>Institute for Applied Information Processing and Communications


Baltimore Technologies plc will not be liable for direct,  special,
or consequential  damages  arising  from  alteration of  the contents of
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.
Received on Tuesday, 15 May 2001 13:19:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:35 UTC