[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]