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

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

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

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?

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

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

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