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

Re: KeyName white space

From: merlin <merlin@baltimore.ie>
Date: Wed, 16 May 2001 14:19:23 +0100
To: "Brian LaMacchia" <bal@microsoft.com>
Cc: "Ed Simon" <ed.simon@entrust.com>, w3c-ietf-xmldsig@w3.org
Message-Id: <20010516131923.71D9644A86@yog-sothoth.ie.baltimore.com>

I'm not particularly motivated either way on this (moreso
on dnames), but if we leave things unchanged I'd suggest
that we add a sentence stating that whitespace surrounding
the value of a KeyName _is_ significant.

Apps with damagable key names could always surround their
keyinfo names with quotes - after all, they have to conform
their key names to valid XML characters. But that's probably
more ugly than leaving things the way they are.

Merlin

r/bal@microsoft.com/2001.05.15/11:22:45
>While I understand the sentiment behind this proposal, I believe it
>would be a mistake.  We have specified that KeyName is a String value
>whose semantic meaning is defined solely by the sender & recipient.
>It's a transport mechanism for a string, that's all -- any rules about
>proper format, contents, etc., thus are application-specific.
>
>I can all too easily envision, unfortunately, scenarios for KeyName
>where automatically stripping off white space would break
>interoperability.  Consider the case where the KeyName is actually a
>filename telling the recipient where to look in a local key cache for
>the verification key.  Filenames on many operating systems can have
>spaces in them, including leading spaces.  Alternatively, suppose that
>the value of KeyName was used as a database lookup key, and it was
>space-padded to be of fixed length.
>
>(Here's another example, although specific to Microsoft.  On Win32
>platforms, it is likely that folks would use KeyName to store CryptoAPI
>key container names.  Rules for container name validity are defined by
>each algorithm implementation (crypto service provider -- CSP).  A
>limitation like this could create all sorts of weird behaviors...)
>
>Let's leave KeyName as just a string.
>
>                    --bal


-----------------------------------------------------------------------------
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 Wednesday, 16 May 2001 09:19:56 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:13 GMT