- From: Petteri Stenius <Petteri.Stenius@remtec.fi>
- Date: Tue, 28 Mar 2000 19:39:12 +0300
- To: "'Mark Bartel'" <mbartel@thistle.ca>, Petteri Stenius <Petteri.Stenius@remtec.fi>, "''John Boyer' '" <jboyer@PureEdge.com>
- Cc: "'''IETF/W3C XML-DSig WG (E-mail) ' ' '" <w3c-ietf-xmldsig@w3.org>
Yes, this is good. We could add some text about the intention and motivation of the exclude-element transform, like: "The element exclusion transform is intended to support enveloped signatures (only?) and SHOULD (or MUST?) be used by implementations when creating enveloped signatures. The transform excludes the SignatureValue and DigestValue elements from digest calculation." A question here: Why can't we simply exclude the entire Signature element? Are not all the important elements from the Signature element already included in the digest used for the SignatureValue? Are the detached or enveloping signatures weaker in security because they do not include the Signature element? Petteri > -----Original Message----- > From: Mark Bartel [mailto:mbartel@thistle.ca] > Sent: Tuesday, March 28, 2000 7:11 PM > To: 'Petteri Stenius '; ''John Boyer' ' > Cc: '''IETF/W3C XML-DSig WG (E-mail) ' ' ' > Subject: RE: Enveloped signatures and XPath > > > I worry that it might be confusing to have a new transform > with XPath in the > name. I have no problem with the spec saying "this Transform > is equivalent > to an XPath Transform with the expression '...'". > > How about (as a discussion point): > > 6.6.5 Element Exclusion > > Identifier: > http://www.w3.org/2000/02/xmldsig#exclude-element > > This Transform contains a single parameter child element > called Id. The > content of the Id element is the id of the element to be > excluded. This > transform is equivalent to the following XPath Transform: > > [some XPath transform] > > -Mark Bartel > JetForm > > -----Original Message----- > From: Petteri Stenius > To: 'John Boyer'; Mark Bartel > Cc: ''IETF/W3C XML-DSig WG (E-mail) ' ' > Sent: 3/27/2000 4:56 PM > Subject: RE: Enveloped signatures and XPath > > > John, > > I agree with you that it is possible to make more specific > inclusion (or > exclusion) transforms with XPath. > > But what you are also saying is that it's possible to compose not so > specific transforms with XPath. How does the verifying > application know > that > a given XPath expression is good enough to trust? Should the verifier > simply > trust the signer? This requirement for trust is what I guess Mark is > also > trying to point out. > > Exclusion by id only solves the most simple case with enveloped > signatures, > and as such is rather restricted. > > Mark suggests that we should define a new transform, and I agree with > that. > > I'd take this a little bit further by defining the new transform using > the > existing algorithms (XPath or XSLT) and by identifying the transform > with a > URI reference. For example > > <Reference URI=""> > <Transforms> > <Transform > Algorithm="&dsig;xpath:exclude-the-signaturevalue-element"/> > </Transforms> > </Reference> > > The XML Signatures spec would include the XPath expression for this > named > transform, the expression does not need to be included with the > signature. > > The signature verifier easilly identifies this transform and > can choose > to > use the XPath expression, or have the functionality > programmed into the > implementation. > > > Petteri > > > > -----Original Message----- > > From: John Boyer [mailto:jboyer@PureEdge.com] > > Sent: 27. maaliskuuta 2000 21:57 > > To: Mark Bartel; 'Joseph M. Reagle Jr. ' > > Cc: ''Petteri Stenius ' '; ''IETF/W3C XML-DSig WG (E-mail) ' ' > > Subject: RE: Enveloped signatures and XPath > > > > > > Hi Mark, > > > > Actually, I will maintain that exclusion by id only is a bad idea > > > > Inclusion by id is useful because you identify an element > > whose content WILL > > BE in the message digest, so if the identified element's > > content is changed, > > then the message digest will break. > > > > Exclusion by id is bad because you identify an element whose > > content WILL > > NOT BE in the message digest, so if the identified element's > > content, tag, > > attributes, etc. are changed, then the message digest will > not break. > > > > The purpose of doing exclusion logic with XPath is that, > > although it is > > possible to do exclusion by id with XPath, it is also > > possible to do much > > better. One can identify an element, but then add additional > > tests that > > only exclude the element if it has the right properties, > > properties which > > the application author can guarantee do not impact the > > interpretation of the > > signature over the material that is digested. > > > > Exclusion logic is quite unsecure and therefore useless > > unless appropriate > > measures have been taken to be quite specific about what gets > > excluded. > > > > John Boyer > > Software Development Manager > > PureEdge Solutions, Inc. (formerly UWI.Com) > > Creating Binding E-Commerce > > jboyer@PureEdge.com > > >
Received on Tuesday, 28 March 2000 11:39:23 UTC