AW: [dss-x] Some issues with the current standards

["Huehnlein, Detlef" <Detlef.Huehnlein@secunet.com>]

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 <SignRequest> MUST
contain either a single <Document> ..." 
   on line 935) to profiles (if necessary, or remove them at all).

3. Allow multiple SignatureObjects of multiple signature-types 
   This would certainly go further than just inserting the
maxOccurs-Attribute.

- Option #1 corresponds to the current state of the core specification,
but it precludes the 
  support of important use cases with DSS at all (e.g. batch signature,
long term archiving
  processes which produce n evidence records (cf. RFC4998) for n (hash
values of) documents etc.). 
- Option #2 would allow to support those use cases and only requires
moderate changes to 
  the core specification.
- Option #3 would be nice, but would require major changes to the core
specification. 

Considering the three cases it seems to me that the "cost/benefit ratio"
tends to 
be optimal in option #2 and hence we should think about whether we
should introduce these
changes during the maintainance process. 

> 
> > 
> > 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 <SignatureObject>-element "SHALL NOT 
> > contain a dss:TimeStamp-element as a child".
> > 
> > This stipulation implies that it is impossible that there 
> is a profile 
> > or an implementation, which satisfies the AdES _and_ the 
> > Timestamping-Profile 
> http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-timesta
mping-spec-v1.0-os.pdf .
> > 
> > Why is the current restriction necessary? Would it be possible to 
> > change the "SHALL NOT" during the maintainence process?
> 
> Maybe there is a certain use case where the adherence to both 
> profiles is required, but in my mind, they are quite disjoint 
> profiles: one serves for generating and/or verifying AdES 
> signatures (that may include timestamps, that is for sure) 
> and from this I conclude that the relevant objects are 
> signatures, and the time-stamping profile is for requesting 
> and / or verifying time-stamps,.... am I missing some 
> specific use cases where this adherence to both profiles is a 
> requirement?

From an abstract point of view (advanced electronic) signatures
and time stamps are similar - both produce a signed object - and
hence there may be implementations, which allow to request 
signatures or time stamps just by specifying the appropriate
SignatureType,
which defines the format of the signed object. In general we should
try to keep the interference of the various profiles to a minimum
such that one is able to support different profiles in some 
implementation (or a comprehensive profile). With the
eCard-API-Framework,
which is currently specified on behalf of the German government for
example
we aim at providing a comprehensive framework, which allows to 
produce or request and verify signatures or time stamps. For this
purpose it would be good if we could refer to the different existing 
profiles and "just combine them" in a comprehensive profile /
implementation.  
However this is not possible with the current AdES-profile, as it
precludes that an implementation, which supports this profile may
as well be used to produce / request time stamps. Are there any
further implications, if we would change the "SHALL NOT" to a more
open stipulation, which would allow an implementation to support 
both profiles?

> > 
> > 3. The <IncludeEContent> element (cf. core, section 3.5.7) does not 
> > seem to be defined in the schema. Hence we should probably add 
> > <xs:element name="IncludeEContent"/> during the 
> maintainance process.
> > 
> I think that you are right. Stefan, I am not sure who was in 
> charge of dealing with the list of issues for maintenance of 
> the core.... do you remember this?

OK. 

> 
> > 4. The UseVerificationTime-element is currently defined in 
> the schema 
> > as <xs:element name="UseVerificationTime"/>, but it should 
> most likely 
> > be defined as <xs:element name="UseVerificationTime"
> >  type="dss:UseVerificationTimeType" />.
> 
> I would also say that you are right....as above Stefan....

OK.

There is yet another issue in the core, which seems to provide 
a restriction, which might not be absolutely necessary:
 
The Result-element is defined in Section 2.6 of the core and it may 
contain (up to (!) one) element ResultMinor:

<xs:element name="ResultMinor" type="xs:anyURI"
minOccurs="0"/>

If the ResultMajor would indicate a warning, which indicates
that the general result is ok, but there are (possible multiple)
issues which should be considered further, it would be nice 
if it would be possible to allow multiple ResultMinor-elements, 
which correspond to individual warning codes. When verifying a 
signature for example there may be multiple reasons, which 
produce an individual warning (e.g. that some checks were not performed)
and it would be good, if these warnings could be communicated in 
multiple ResultMinor-URIs. 

Do you think that it would be possible to allow multiple
ResultMinor-URIs?
... at least in some profile?

Best regards,
   Detlef