[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Fwd: [dss] More on EnvelopingSignature]
Hi Ed and Trevor... Sorry for not saying anything during this week: I was in some meetings in ETSI and come back to the office yesterday.... I have been thinking in the issue and I would like to share some of my thoughts. First some comments on Ed's suggestions: Scenarios 1 and 2. Ed's suggestion is to add the Id attribute to the <bookOrder> element. I doubt that this behaviour could be generalized: if the signed document aligns to a DTD or a Schema, and they do not define such an attribute, the server would have generated a signed document that would be invalid against the DTD or the schema. And I would say that we should not mandate the usage of Id attributes for allowing enveloping signatures, as there exist other means: transformations... Scenario 2 should require Id added to ds:Object, and then we would come to the origing of my comment: we should write something in the core for this processing. No comment on scenario 3, except that the server should check the existance of the Id attribute. Scenarios 4 and 5. I share Ed's view: I would prefer not to allow the client do this kind of work.... Once here, I have to say that all these scenarios are, in fact the easiest ones, because they do not take into account the fact that: i. The client may have applied certain transformations to the to be enveloped object. I admit that it is difficult for me imaging transformations other than the canonicalization or something in the like. And I would not have any problems if we forbid the client to do such things. But in its current wording this is still allowed by the core. ii. The client may request the server to perform certain transforms... Just note that by using transformations, the alignment RefURI / ObjId could be broken, as they would allow the client to do something like: RefURI="". In this case the verifier of the signature should start transformations in the <ds:Signature>. RefURI absent. Which means that the verifier would know in advance how to get the starting point for dealing with transformations... If we allow for i and ii, we can have requests that include both...so the client knows what transforms has performed, what transforms to request and how the server should start to do its work in terms of performing the additional transforms.... Why then not allowing it to instruct the server on this aspect (by means of an attribute) saying :"do the processing with the ds:Object or with the input document that I pass you? I take the responsability of building up a combination ofRefURI (if any), ObjId (if any), SignedReference.Transforms (if any) and XMLData.Transforms (if any) SUCH AS if you process what I tell you in the way I want, the enveloping signature will be a valid one...." We could profile a set of minimum checks to be performed by the server when NO transformations are indicated, but not of course when these transforms are present... I have produced a short document that includes tables with the different combinations of fields and a discussion on the server behaviour for each. I still doubt whether the XMLData.Transforms element would make sense in the enveloping signature case, but I have included it. Sorry for this lengthy message.... Regards Juan Carloos >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 > > > >--------------------------------------------------------------------- >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 > > >
CASE STUDY FOR ENVELOPING SIGNATURES.zip
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]