Re: AW: AW: KeyName white space

     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
different:
before +  Discard.
before =  Invalid
before , or ;  Discard
after +        Discard
after =        Discard
after , or ;   Discard

     Should normalization software need to deal with this?

          Tom

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:

           <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:

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.

Merlin

r/gregor.karlinger@iaik.at/2001.05.15/13:10:53
>>      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?
>
>Why would you like to require such an escaping?
>
>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 13:19:50 UTC