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.


>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.
Received on Wednesday, 16 May 2001 09:19:56 UTC

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