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

RE: signature portability / C14N / inherited namespaces

From: John Boyer <JBoyer@PureEdge.com>
Date: Wed, 16 May 2001 10:23:44 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B520C33D2@tigger.PureEdge.com>
To: "Rob Lugt" <roblugt@elcel.com>, "merlin" <merlin@baltimore.ie>, <reagle@w3.org>
Cc: <w3c-ietf-xmldsig@w3.org>


Hi Rob,

<rob> <snip/> However, if you are willing to put some onus on the
application to be aware of the namespace context of the document
fragment, then perhaps it would be a reasonable idea to recommend an
extension to Canonical XML processors enabling them to take a list of
namespace prefixes that they should not copy into the output document.
<snip/> </rob>

<john>
Such a mechanism already exists: document subsetting.  The namespace
axis processing only includes those namespace nodes that are both in the
axis and in the node-set.  Thus, if the application has a particular
blob of XML to be signed, it is assumed that the application might know
a bit more about the namespaces at play within that blob and hence could
construct an Xpath to keep all desired elements and attributes plus only
those namespace nodes required.  As a result, the signature could be
moved to other contexts since unwanted namespace nodes from the new
context are also not kept.

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

Regards
Rob Lugt
ElCel Technology


----- Original Message -----
From: "John Boyer" <JBoyer@PureEdge.com>
To: "merlin" <merlin@baltimore.ie>; "Rob Lugt" <roblugt@elcel.com>
Cc: <w3c-ietf-xmldsig@w3.org>
Sent: Wednesday, May 16, 2001 4:56 PM
Subject: RE: signature portability / C14N / inherited namespaces


>
>
> Hi Merlin and Rob,
>
> The group discussed this issue at length before deciding on the
current
> methodology.  If a namespace attribute is not being used anywhere
within
> a document subset, and it is inheriting that declaration from the
> outside, then there is no good reason to keep the namespace
declaration.
> But if a namespace declaration is inherited from the outside and it
*is*
> being used, then moving the document subset from one context to the
> other changes the meaning of the signed information without breaking
the
> signature.  The group's decision to always import the full namespace
> context was based on the relative difficulty of assessing whether a
> namespace attribute is actually being used.  It seemed a passable if
not
> desirable compromise to put some onus on the application creating the
> signatures to capture the contexts under which they might be
> transported, even if such must be done dynamically.
>
> At a minimum, the fact that my signature was taken from some context
and
> placed into another means that there is already not that much of a
> burden to take my signature back out of the foreign context before
> trying to validate it.  The fact that one XML syntax might be meant as
a
> container for elements in other namespaces does not mean that those
> other elements can retain their exact meaning when in the container.
To
> wit, many document processors will report errors if the root document
> element does not have the tag that they are expecting to process.  The
> element must be removed from the container before it can be used.
>
> 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/>
>
>
>
>
> -----Original Message-----
> From: merlin [mailto:merlin@baltimore.ie]
> Sent: Wednesday, May 16, 2001 7:29 AM
> To: Rob Lugt
> Cc: w3c-ietf-xmldsig@w3.org
> Subject: Re: signature portability / C14N / inherited namespaces
>
>
>
> Hi Rob,
>
> r/roblugt@elcel.com/2001.05.16/15:13:01
> >One last try at a workable solution whilst adhering to the c14n
> >specification:- re-use the same namespace prefix from the SOAP
header.
> >
> ><ns:Envelope xmlns:ns="http://schemas.xmlsoap.org/soap/envelope/">
> > <ns:Body>
> >  ...
> >  <Contract xmlns="&foo;">
> >   <ns:Signature xmlns:ns="&dsig;">...</ns:Signature>
> >  </Contract>
> > </ns:Body>
> ></ns:Envelope>
> >
> >I think the namespace prefix should ideally be a descriptive name
which
> >makes this solution less than elegant.  But perhaps it satisfies your
> >current requirement?
>
> I've actually solved it for myself by using a framework that can
> defer signing until the final document is complete. This is okay
> for my particular needs, but it won't work for someone who is
> using, for example, Apache's SOAP framework (which never builds
> a DOM tree, but instead manually marshals the SOAP envelope in
> text format*) or who has no control over the final embedding of
> their signature.
>
> My concern really revolves a bit more around interop and the dsig
> spec than this particular instance.
>
> Merlin
>
> * It does make the namespace available, but not through DOM.
>
>
>
------------------------------------------------------------------------
> -----
> 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 13:25:48 GMT

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