Re: Poll on Exclusive Canonicalization

Hi john,

I'm responding here primarily as an advocate of my proposal...

From:  "John Boyer" <JBoyer@PureEdge.com>
Date:  Mon, 18 Jun 2001 10:17:12 -0700
Message-ID:  <7874BFCCD289A645B5CE3935769F0B520C33F1@tigger.PureEdge.com>
To:  "Joseph M. Reagle Jr." <reagle@w3.org>,
            "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Cc:  "Donald Eastlake" <dee3@torque.pothole.com>, <lde008@dma.isg.mot.com>

>Hi Joseph,
>
>I'm sure that option 1 is not good, but unless the limitations imposed
>by this problem are acceptable, then perhaps the WG may need to spend
>more time generating and considering alternatives.  Here is the problem
>with option 2 that originally made us not use it within c14n:
>
>It is virtually impossible to assess whether a given namespace
>declaration is being used within a given XML subtree.  While it is
>possible to determine whether the start tags of an element and its
>descendants utilize a namespace declaration, it is not possible to
>determine the intent of attribute values and element character content.
>To wit, within the dsig markup, an XML namespace declaration may be used
>only within the character content of an <XPath> element.  Moreover, what
>about generic <Object> elements, which could contain arbitrary XML?

This is a good point. Certainly, the determination as to whether or
not a namespace should be included in the canonicalized outut needs to
be relativley simple.  My current proposal says to simply look at the
prefixes in use.  I guess that needs to be supplemented by some easy
way to cause namespaces to be retained if their "use" is hidden inside
what is, from the C14N and XML standard point of view, opaque data....

>==================================================================
>
>Note that the algorithm identifiers for excluding c14n seem to be the
>same in 6.5.2 as those for inclusive in 6.5.1.  This is probably just a
>copy paste error.

Sorry, they were meant to be the identifiers which appear in the
algorithms table at the start of section 6.1:
http://www.w3.org/2000/09/xmldsig#excludeC14N and
http:http://www.w3.org/2000/09/xmldsig#excludeC14NwithComments.

>So, namespaces used by XPath expressions in XPath elements would need to
>be declared.  Doesn't seem like a big problem to me.  

Do you have any suggestions here? Would an IncludeNS element content
of exclusive canonicalization algorithm elements which had an
attribute whose values was a list fo prefixs (NMTOKENS) that would be
considered used, even though their prefix did not appear to be used,
do the trick?  So you might have
  <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#excludeC14N">
    <IncludeNS Prefixes="foo bar etc"/>
  </Transform>     

>Namespaces used by XML in Objects has to be declared.  Make this the
>responsibility of the application that creates the Object.  Doesn't seem
>like a big deal.

I'm not sure exactly what you mean here. Do you mean like the declaration
of the XYZ prefix belows?
   <Object><mumble xmlns:XYZ="data:abc">...some data including XYZ
		   which later is caused to be interpreted as a prefix...
   </mumble></Obect>
I don't think that works unless enveloping identical declarations
are prohibited. It's OK it being an application responsibility but
it seems to me cleaner to specify the retention of the apparently
"unused" namesapce at the Transform or CanonicalizationMethod
algorithm element.

>Use of exclusionary c14n outside of the limited context of signing
>SignedInfo seems problematic from an implementers standpoint.  What is
>the plan here?

I don't understand your question. As I proposed them, these seem to me
to be well defined algorithms that can operate anywhere inclusive
canonicalization can be used.  What's problematic?

>Aside from these issues which need to be addressed, I find option 2
>preferrable.
>
>Thanks,
>John Boyer
>Senior Product Architect, Software Development
>Internet Commerce System (ICS) Team
>PureEdge Solutions Inc. 
>Trusted Digital Relationships
>v: 250-708-8047  f: 250-708-8010
>1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>  	

Thanks,
Donald

Received on Monday, 18 June 2001 14:46:34 UTC