OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: DSS-Comments (Multiple signature verification, verification report and fixed request/response type)


Dear DSS-team,

first of all I would like to beg your pardon that 
I was not able to send the comments during your regular
public review period.  

We are currently working on a project for the 
German government, which aims at specifying a universal
framework for using smart cards and related cryptographic 
functions like the generation and verification of 
electronic signatures for example. As our framework is
based on webservice interfaces, we would like to make
use of the DSS-core profile or the XAdES-profile (or define a 
specific profile which fits our needs). While most parts 
of the current DSS-core-draft seem to be very well designed
(congratulations!) and DSS hence has the potential 
to become widely used in practice, there are a few points,
which (from our point of view) seem to provide serious limitations,
which seemingly can not be fixed by profiles based on the 
core standard. 

1. Multiple signature verification
----------------------------------
In section 4.3.1 you note that you do NOT support multiple
signatures on multiple documents. Why? 

A) Multiple signatures
----------------------
From our point of view it seems to be very important to support 
multiple signatures (and timestamps) in one document, especially 
if one thinks about aspects of long term archival of signed documents.

B) Multiple documents
---------------------
In batch scenarios (e.g. for eGovernment or eBilling purposes)
it is necessary to be able to verify very many signatures in a 
very short period of time and hence is desirable to feed multiple 
documents to a verification server in a single request. 

Due to your (seemingly artificial) limitation in section 4.3.1 it 
does not seem possible to realize both requirements simultaneously. For the
sake of generality of the core standard this does not seem 
to be a very good solution. 

2. Verification report
----------------------

Closely related with this point is the fact that your 
<ProcessingDetails> consist of a flat structure grouped 
"valid", "indeterminate" and "invalid". If you would like
to verify a batch of signatures and you would like to have a 
closer look at the in{valid/determinate} signatures you would need to
search the entire structure in order to extract all errors and
warnings for a specific signature, which will be rather cumbersome
if the batch sizes are large or there are multiple signatures per
document. For such usage scenarios it would seem to be better to 
have some sort of structured verification report for a single 
signature. Is it possible for a profile to redefine the 
<ProcessingDetails>-structure?  

3. Request / Response Type
--------------------------
A last point is that you probable should think about the possibility that 
profiles based on the core standard are able to redefine the basic 
request- and response-types such that it is possible to use some 
DSS-profile as part of larger webservice-infrastructures in which the 
request- and response-types are fixed (and probably not identical to the 
ones specified in the DSS-core). 

It would be nice if you would decide to think about the comments
above and let me know what happens with the suggested points. 

Best regards,
   Detlef Huehnlein

--
Dipl. Inform. (FH)
Dr. rer. nat. Detlef Hühnlein
Partner
secunet Security Networks AG
Sudetenstraße
96247 Michelau
Telefon +49 9571 896479
Mobil   +49 171  9754980
detlef.huehnlein@secunet.com
www.secunet.com

Diese E-Mail ist ausschließlich für den genannten Empfänger bestimmt.
Sie enthält streng vertrauliche Informationen. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung, ist untersagt. Falls Sie diese E-Mail versehentlich erhielten, informieren Sie bitte unverzüglich den Absender und löschen Sie diese E-Mail von jedem Rechner, auch von Ihrem Mailserver. 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 contains 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. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]