RE: KeyName white space

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

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