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