Some issues with the current standards

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

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

<xs:element name="SignResponse"> 
...
           <xs:element ref="dss:SignatureObject" minOccurs="0"/> 
...
</xs:element>

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?

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-timestamping-spec-v1.0-os.pdf .

Why is the current restriction necessary? Would it be possible to 
change the "SHALL NOT" during the maintainence process? 

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. 

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" />.

BR,
  Detlef

--
Dipl. Inform. (FH)
Dr. rer. nat. Detlef Hühnlein
Partner
secunet Security Networks AG
Sudetenstraße 16
96247 Michelau
Telefon +49 9571 896479
Mobil   +49 171  9754980
detlef.huehnlein@secunet.com
www.secunet.com
======================
Besuchen Sie uns auf der CeBIT 2008, 
4. - 9. März 2008, Halle 6 Stand J36
(www.cebit.de)
----------------------
und auf dem Managed Security Forum 2008
2. April in Frankfurt am Main
7. Mai in Düsseldorf
29. Mai in Hamburg
16. Juni in München
(www.managed-security-forum.org) 
Wir freuen uns auf interessante Gespräche mit Ihnen. 
======================
secunet Security Networks AG
Kronprinzenstr. 30
45128 Essen
Amtsgericht Essen HRB 13615

Vorstand:
Dr. Rainer Baumgart
Thomas Koelzer
Thomas Pleines

Aufsichtsratsvorsitzender:
Dr. Karsten Ottenberg

Diese E-mail kann vertrauliche Informationen enthalten. Falls Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte unverzüglich den Absender und löschen Sie diese E-Mail von jedem Rechner, auch von den Mailservern. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung, ist in diesem Fall untersagt. Außer bei Vorsatz oder grober Fahrlässigkeit schließen wir jegliche Haftung für Verluste oder Schäden aus, die durch Viren befallene Software oder E-Mails verursacht werden.

This e-mail may contain strictly confidential information and is intended for the person to which it is addressed only. Any dissemination, even partly, is prohibited. If you receive this e-mail by mistake, please contact the sender and delete this e-mail from your computer, including your mailserver.
Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses.