Re: KeyName white space

It may be too late but it would be nice if KeyName were normalized
like a CDATA attribute value.  In fact, I think it would have been
better if we had defined a "Name" attribute, rather than element
content...

See other comments below.

From:  Ed Simon <ed.simon@entrust.com>
Message-ID:  <7D901CFF4FC51942AF52A0AD43AA3F821B6200@sottmxs08.entrust.com>
To:  w3c-ietf-xmldsig@w3.org
Date:  Tue, 15 May 2001 18:14:46 -0400

>BTW, I'm not pushing one way or the other; those working most directly with
>complex implementations are in the best position to comment.  My suggested
>wording was only iff there was a concensus to make the change.
> 
>Ed
>
>-----Original Message-----
>From: Brian LaMacchia [mailto:bal@microsoft.com]
>Sent: Tuesday, May 15, 2001 2:23 PM
>To: Ed Simon
>Cc: w3c-ietf-xmldsig@w3.org
>Subject: RE: KeyName white space 
>
>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.

We are not talking about it's semantic content.  We are talking about
it's encoding.  There are already numerous encoding rules.  The
KeyName can't have a less than character in it, it has to use &lt;,
etc.

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

So, just say &#20; where you want a real space, just like you
currently have to say &quot; if you want a " character, etc.

>(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.

Sure it's just a string, but what kind of string encoding is the
question.

>                    --bal

Thanks,
Donald

>-----Original Message-----
>From: Ed Simon [mailto:ed.simon@entrust.com] 
>Sent: Monday, May 14, 2001 5:35 PM
>To: w3c-ietf-xmldsig@w3.org
>Subject: RE: KeyName white space 
>
>
>
>1. The schema will not prevent people from having leading or trailing
>whitespace in the content of KeyName (and it shouldn't!).  The spec will
>just say that any leading and trailing whitespace MUST be trimmed to obtain
>the actual KeyName.
>
>2. The code will look something like this: 
>
>  Node nodeKeyName = XPathAPI.selectNode(doc, "//KeyName/text()");  // get
>the text content of <KeyName> 
>  String strNodeKeyName = nodeKeyName.nodeValue(); 
>  String strKeyName = strNodeKeyName.trim(); 
>  KeyResolver.resolveWithKeyName(strKeyName); 
>
>Ed 
>
>-----Original Message----- 
>From: Joseph M. Reagle Jr. [ mailto:reagle@w3.org <mailto:reagle@w3.org> ] 
>Sent: Monday, May 14, 2001 6:18 PM 
>To: merlin 
>Cc: Donald E. Eastlake 3rd; w3c-ietf-xmldsig@w3.org 
>Subject: Re: KeyName white space 
>
>
>I don't think I completely understand the problem yet. Is this to say that 
>
>1. the content model for KeyName should be precluded from having a 
>white-space as the first or last character? (Not sure if this is possible 
>using XML Schema patterns [1] since they don't support ^ and $.) 
>2. That a processor will not have those white spaces available to them? 
>(What happens if people want to use generic xml tools like query or XPath 
>where the whitespace is preserved/important) 
>
>[1] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#element-pattern
><http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#element-pattern>  
>
>At 22:18 5/14/2001 +0100, merlin wrote: 
>>Agreed. DNames already have this property (from RFC 2253 I think), 
>>and I believe so do base-64 coded data as well as integers, so 
>>this would unify pretty much all of our text handling. 
>> 
>>merlin 
>> 
>>r/dee3@torque.pothole.com/2001.05.14/14:35:23 
>> >Hi, 
>> > 
>> >Some questions have arisen about in the XML Encryption activity the 
>> >handling of white space in the content of the KeyName element. There 
>> >was substantial feeling there that leading and trailing whitespace 
>> >should be stripped from KeyName content.  I think this would be an 
>> >improvement but since it is in the XMLDSIG namespace, this list is 
>> >the right place for discussion.  What do others think? 
>> > 
>> >Thanks, 
>> >Donald 
>> >===================================================================== 
>> > Donald E. Eastlake 3rd                      dee3@torque.pothole.com 
>> > 155 Beaver Street                                +1 508-634-2066(h) 
>> > Milford, MA 01757 USA                            +1 508-261-5434(w) 
>> > 
>> 
>> 
>>---------------------------------------------------------------------------
>-- 
>>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 <http://www.baltimore.com>  
>
>__ 
>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
><http://www.w3.org/People/Reagle/>  
>W3C Policy Analyst                mailto:reagle@w3.org
><mailto:reagle@w3.org>  
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
><http://www.w3.org/Signature>  
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
><http://www.w3.org/Encryption/2001/>

Received on Thursday, 17 May 2001 09:06:17 UTC