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

["Edward Shallow" <ed.shallow@rogers.com>]

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 (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.

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