W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

RE: History: Question on C14N list of nodes instead of subtrees

From: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
Date: Tue, 29 Jan 2002 08:34:24 +0100
To: <reagle@w3.org>, "'John Boyer'" <JBoyer@PureEdge.com>, "'merlin'" <merlin@baltimore.ie>
Cc: <w3c-ietf-xmldsig@w3.org>
Message-ID: <00b001c1a897$601fa820$64981b81@iaik.at>
hi,

> -----Original Message-----
> From: Joseph Reagle [mailto:reagle@w3.org] 
> Sent: Monday, January 28, 2002 9:21 PM
> To: Karl Scheibelhofer; 'John Boyer'; 'merlin'
> Cc: w3c-ietf-xmldsig@w3.org
> Subject: Re: History: Question on C14N list of nodes instead 
> of subtrees
> 
> 
> On Monday 28 January 2002 13:17, Karl Scheibelhofer wrote:
> > yes, i use three references in each signature. those look like this:
> 
> Ok.
> 
> > 
> c%20./ancestor::dsig:Signature%5b1%5d/child::dsig:Object/child::aida:p
> > ro
> > 
> perties/child::aida:signedProperties//@*%20%7c%20./ancestor::d
> sig:Signat
> > 
> ure%5b1%5d/child::dsig:Object/child::aida:properties/child::ai
> da:signedP
> > roperties//namespace::*)">
> 
> Well having a transform such these expressions can be easily 
> expressed 
> without character escaping would be one benefit -- much more 
> readable! 
> <smile/>
> 
> > each of these parallel
> > signatures uses the same XPointer references, because the XPointers 
> > are relative.
> 
> How is the relativity achieved? I note you are using 
> "./ancestor" instead 
> of "here()/ancestor". In XPtr isn't your context location [1] still 
> initialized to the root node?
> 
> [1] http://www.w3.org/TR/xptr/#context

yes you are right. the '.' should rather be a "here()". i have to rvise
my XPointer code.

> 
> > i think i could live without this omission filters, because 
> i cannot 
> > imagine a reasonable other use-case for them. who needs a 
> filter like 
> > "just sign all attributes which's name is ..."?
> 
> The motivating scenario was of signing a form whereby I want 
> to sign the 
> whole form except a few of the fields where the recipient 
> might enter their 
> own information. This isn't easily accomplished via subtrees.

i agree that the filter mechanism as it is is very flexible.

> 
> > the signature is never part of the signed document. consequently, i 
> > structure my documents that this is really the case. this 
> means, the 
> > signature is never the descendant of any of its signed 
> elements. in my 
> > use-case the signature is a sibling of the signed content, if it is 
> > inside the same document. and if the signature is detached, 
> there is 
> > no problem anyway. putting all singed data into the Object 
> element of 
> > a signature and then signing the complete document excluding the 
> > signature itself, is "not a nice design" putting it mildly.
> 
> Ok, thank you! Understanding folks deployment scenarios is 
> very useful.
> 

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:Karl.Scheibelhofer@iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Graz University of Technology, Austria, http://www.iaik.at and
http://jcewww.iaik.at
Phone: (+43) (316) 873-5540
Received on Tuesday, 29 January 2002 02:30:21 GMT

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