OASIS Digital Signature Services eXtended (DSS-X) TC

Hallo all,

as briefly discussed in the telco yesterday, I would like to point
out some issues in the current standard(s), which might be worth looking at
during the maintainance process:

1. Return of at most one SignatureObject in SignResponse (core, section 3.2)
----------------------------------------------------------------------------
In section 3.2 of http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf, 
the SignResponse is defined as

Dear Detlef,

I appologize for not reacting before to your email...
See below intermixed,

Juan Carlos.
Huehnlein, Detlef escribió:

> 
> 1. Return of at most one SignatureObject in SignResponse (core, section 3.2)

> This definition (without maxOccurs="unbounded") would preclude the simplest
> (and hence a widely used) bulk signature use case in which somebody wants to 
> generate some sort of enveloping signature for a large number of (small) 
> documents, which are all provided in a single SignRequest.  
> 
> Why is the current restriction necessary? Would it be possible to 
> add the maxOccurs="unbounded" during the maintainence process?

My recollection of this was that it was actually discussed whether the 
protocol would allow the generation of one or more than one signature 
and it was decided to restrict the protocol to generate only one 
signature. In addition to that I would say that there are no means in 
the protocol for indicating what documents should be signed by one 
signature or the other, so if I have correctly understood you the issue 
would go farther than only include a maxOccurs="unbounded" attribute.

> 
> 2. Possible conflict between AdES- and Timestamping-Profile?
> ------------------------------------------------------------
> In section 3.3.2.1 and 3.4.1.2 of http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES-spec-v1.0-os.pdf 
> it is stated that the 

Hallo Juan Carlos,

> I appologize for not reacting before to your email...

no problem.

> > 1. Return of at most one SignatureObject in SignResponse (core, 
> > section 3.2)
> 
> > This definition (without maxOccurs="unbounded") would preclude the 
> > simplest (and hence a widely used) bulk signature use case in which 
> > somebody wants to generate some sort of enveloping signature for a 
> > large number of (small) documents, which are all provided 
> in a single SignRequest.
> > 
> > Why is the current restriction necessary? Would it be 
> possible to add 
> > the maxOccurs="unbounded" during the maintainence process?
> 
> My recollection of this was that it was actually discussed 
> whether the protocol would allow the generation of one or 
> more than one signature and it was decided to restrict the 
> protocol to generate only one signature. In addition to that 
> I would say that there are no means in the protocol for 
> indicating what documents should be signed by one signature 
> or the other, so if I have correctly understood you the issue 
> would go farther than only include a maxOccurs="unbounded" attribute.

In my point of view we may distinguish the following cases for the
SignResponse:
1. Only allow only one SignatureObject 
   This is how it is currently specified in the core. 

2. Allow multiple SignatureObjects of one specific signature-type
   This is could be reached by inserting the maxOccurs="unbounded"
attribute
   and moving the related restrictions (e.g. "The