Re: [Fwd: [dss] More on EnvelopingSignature]

[Trevor Perrin <trevp@trevp.net>]

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