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 12:26:45 UTC