[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Fwd: [dss] More on EnvelopingSignature]
I think it is a question of consistency and perhaps we could entertain a dash of simplicity. Take these scenarios: Scenario 1: Client passes in ... <bookOrder> <item> <title>XML and Digital Signatures</title> <isbn>0-201-48543-5</isbn> <quantity>1</quantity> <price unit="USD">39.95</price> </item> </bookOrder> ... and dss:EnvelopingSignature/No ObjId Server can either a) reject because No ObjId attr present in request, or b) it can unilaterally add a Reference URI and a matching Id attr e.g. <bookOrder Id=content> and construct a node-set under a <ds:Object> and sign it. Pre-Digest would not contain ds:Object tags Scenario 2: Client passes in ... <bookOrder> <item> <title>XML and Digital Signatures</title> <isbn>0-201-48543-5</isbn> <quantity>1</quantity> <price unit="USD">39.95</price> </item> </bookOrder> ... and dss:EnvelopingSignature/ObjId=MyOrder Server follows instructions and adds Reference URI and Id attr (to bookOrder element not ds:Object I would wager) Scenario 3: Client passes in ... <bookOrder Id="MyOrder"> <item> <title>XML and Digital Signatures</title> <isbn>0-201-48543-5</isbn> <quantity>1</quantity> <price unit="USD">39.95</price> </item> </bookOrder> ... and dss:EnvelopingSignature/ObjId=MyOrder Similar to Scenario 3 except that client included Id attr, server accepts it since it matches and is consistent Scenario 4: Client passes in ... <ds:Object Id="MyOrder"> <bookOrder> <item> <title>XML and Digital Signatures</title> <isbn>0-201-48543-5</isbn> <quantity>1</quantity> <price unit="USD">39.95</price> </item> </bookOrder> </ds:Object> ... and dss:EnvelopingSignature/No ObjId Personally I would reject this since the client is trying to do our job by specifying signature-specific ds:Object framing Scenario 5 Client passes in ... <ds:Object Id="MyOrder"> <bookOrder> <item> <title>XML and Digital Signatures</title> <isbn>0-201-48543-5</isbn> <quantity>1</quantity> <price unit="USD">39.95</price> </item> </bookOrder> </ds:Object> ... and dss:EnvelopingSignature/ObjId=MyOrder Personally I would reject this as well, in fact why not reject any thing that attempts framing with the ds:Object ? The alternative, and a possible way to support both ds:Object tag in or out of signature scope, is to allow the client to specify where the Id goes and force the server to find it on either the ds:Object or the First Child under the ds:Object. Doable but complicates things for little gain. Additionally, should not EnvelopingSignature restrict InputDocuments to 1 for clarity ? Ed -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: June 1, 2005 7:56 PM To: ed.shallow@rogers.com Cc: dss@lists.oasis-open.org Subject: Re: [Fwd: [dss] More on EnvelopingSignature] Edward Shallow wrote: > Agree with the True scenario as is presently supported. In fact one > could use either the ObjId passed in EnvelopingSignature or why not > simply the RefURI on the target BaseDocumentType to add the Id > attribute to the newly constructed ds:Object node That's what we do - we use the ObjId passed to add the Id attribute to the newly constructed ds:Object node. However, that doesn't solve Juan Carlos' problem. The signature is still calculated over the element inside the <ds:Object>, not the <ds:Object> itself. (see Andreas' enveloping example on the Wiki ... > #content). I do not believe that the False scenario will present > itself often enough to be useful and is not IMHO warranted. Why would > the user create any signature-specific framing at all ? That is what > they want the server to preform. You are moving in the template > direction and if you are going to suggest templates, then support them > all the way as is described in the EPM profile. > > If these exception scenarios are to be supported at all, I believe > they should be relegated to the profiles to handle. When an enveloping <ds:Signature> contains a <ds:Object> which contains <someElement>, the signature might be over A) <ds:Object> or B) <someElement> Juan Carlos pointed out that we have no way of using DSS with <dss:EnvelopingSignature> to create a signature over the <ds:Object> (A), only over the <someElement> (B). Do you have a solution that supports both, or do you think current support is ok? Trevor > > User-friendly will always get my vote. > > Ed > > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: May 29, 2005 3:21 PM > To: dss@lists.oasis-open.org > Subject: Re: [Fwd: [dss] More on EnvelopingSignature] > > > Juan Carlos, > > You make a good point: currently, there's no way for clients to use > <dss:EnvelopingSignature> and request a signature that references the > <ds:Object>. Thus, the ObjId attribute is not very useful. > > I propose that we eliminate the ObjId attribute. Instead add an attribute > dss:EnvelopingSignature/@addObjectWrap=[true/false]. > > If true, the server adds a <ds:Object> around the input document when > embedding it, per the current text. > > If false, the server assumes a <ds:Object> is already present in the inpout > document, so the server embeds the input document directly in the > signature. > > This approach doesn't require changes in basic processing. > > > Trevor > > > > > Trevor Perrin wrote: > >>---------------------------- Original Message >>---------------------------- Subject: [dss] More on EnvelopingSignatur > > > e > >>From: cruellas@ac.upc.edu >>Date: Fri, May 27, 2005 11:06 am >>To: dss@lists.oasis-open.org >>Cc: scabre@ac.upc.edu >>---------------------------------------------------------------------- >>---- >> >> >> >>Dear all, >> >>Concerning our previous email, and after looking at the request and >>thinking further,we would say that, as there is not in the request any >>ObjId in the EnvelopingSignature optional input,and there is not any >>Id in the enveloped xml data, the request is not correctly built and >>the server would generate a signature whose verification would fail. >>Requester's responsability.... >> >>But the issue on the description of the processing is still remaining. >>If the request is: >> >> >>xmlns:dss="http://www.docs.oasis-open.org/dss/2004/06/oasis-dss-1.0-co >>re-schema-wd-30.xsd"; >> >>RequestID="UPCRequestEnvelopingXMLSig_0"> >> >>urn:ietf:rfc:3275 >> >> >> >> >> >> >>xmlns:upc1="http://www.ac.upc.edu/namespaces/ns1";; >>xmlns:upc2="http://www.ac.upc.edu/namespaces/ns2";;> >>child1 content >>child21 content child22 content >> >> >>child31 content child32 content >> >> >> >> >> >> >> >>Then the server is instructed to add the Id attribute to ds:Object. In >>this case, in order the verification be successfull, the server has to >>digest the whole canonicalized ds:Object, not only the xmldata >>contents....and this process is not indicated anywhere in the core > > text..... > >> >>Going a bit further, we could have three general cases....The list >>below explains them and gives indications of what we think that the >>server could do in each case. We asume in all of them that the >>to-be-enveloped input document contains a RefURI....if not, things are >>per-application based (as indicated in XMLDSIG). >> >>1. EnvelopingSignature without ObjId, NO SignedReferences with >>Transformations, No transformations indication in the input document: >> >>---> If the input document is a XMLData and it contains an Id that >>matches the RefURI, the server should only process (canonicalize and >>digest) the contenst of the element with the Id for generating a valid >>signature!!. Difficulties for the server, unless the Id is in the root >>node of the input document....If not Id is present in the document >>there is no way of generating a valid signature: Requester's > > responsability.... > >>What about banning this request? >> >>2. EnvelopingSignature with ObjId and NO SignedReferences with >>transformations AND NO transforms indication in the input document. >> >>---> For generating a valid signature the server SHOULD PROCESS >>(canonicalize and digest in this case) the whole ds:Object (Not >>indicated in the core: need for modification?) >> >>3.EnvelopingSignature with or without ObjId AND some transformations >>within the inputdocument or within SignedReferences. >> >>--->The server will process THE INPUT DOCUMENT as indicated >>in the section corresponding to processing, and the client will be >>responsible for ensuring that the corresponding RefURI/Id pair and the >>transforms indicated and/or requested combine so that the built >>signature may be successfuly verified....Again, it is client's >>responsability. >> >> >>Do you agree with the summary of the 3 different cases? and what do >>you think of the server's behaviour that we describe for them? >> >>Regards >> >>Sergi and Juan Carlos. >> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe from this mail list, you must leave the OASIS TC that >>generates this mail. You may a link to this group and all your TCs in >>OASIS at: >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> >> > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]