RE: [dss-dev] DSS services and European Signature law

["Pim van der Eijk" <lists@sonnenglanz.net>]

Hello Detlef,

It seems that ARX is taking this approach and is actually in the process of
being evaluated as an SSCD.

http://www.arx.com/products/electronic-signature-legal.php
"CoSign has been self-qualified by ARX as a SSCD. In addition, CoSign is
currently undergoing a Common Criteria evaluation (EAL 4+) under CWA 14169
(Protection Profile for SSCD) by an accredited assessment body." 

Ezer, it would be good if you could attend the next teleconference meeting
of the DSS-X TC, as the subject of DSS in relation to EU legislation has
been proposed as an agenda item.

Pim

-----Original Message-----
From: Huehnlein, Detlef [mailto:Detlef.Huehnlein@secunet.com] 
Sent: 19 February 2008 14:00
To: Pim van der Eijk; Andreas Kuehne; dss-dev@lists.oasis-open.org
Subject: AW: [dss-dev] DSS services and European Signature law

Hi Pim,

from an abstract point of view there is no difference between the two
settings. From a practical point of view however it is important to note
that the "trusted path" ends *in* the SSCD. Hence the DSS-implementation
would be part of the SSCD, which is IMHO not feasible (at least from a
current and commercial point of view).

BR,
 Detlef 

> -----Ursprüngliche Nachricht-----
> Von: Pim van der Eijk [mailto:lists@sonnenglanz.net]
> Gesendet: Montag, 18. Februar 2008 14:13
> An: Huehnlein, Detlef; 'Andreas Kuehne'; dss-dev@lists.oasis-open.org
> Betreff: RE: [dss-dev] DSS services and European Signature law
> 
> 
> Hello Detlef and other,
> 
> The question I basically have is about the difference between two
> situations:
> 1) The first is the conventional local fat client situation where the 
> SSCD is inserted into a card reader attached to a personal computer. 
> The user accesses the functionality of the card and signs using the 
> key stored on the card using a user interface and software on that 
> personal computer.
> 2) The second is the network-based situation where some device that 
> meets the SSCD requirements you mention is attached to a server, and 
> DSS is used as the "trusted path"
> by a remote user to access the SSCD from a remote client.
> 
> In my reading of 14169, there is no relevant difference in "trusted 
> path" in both cases. DSS with the TLS security binding provides 
> identification of end points, confidentiality and integrity. So, 
> should it be possible to sign using qualified certificates in both 
> situations?  If not, what is the requirement that the network-based 
> situation does not meet? If yes, are there examples of national 
> legislation/CSP policies that actually allow this?
> 
> Pim
> 
> -----Original Message-----
> From: Huehnlein, Detlef [mailto:Detlef.Huehnlein@secunet.com]
> Sent: 14 February 2008 08:44
> To: Andreas Kuehne; lists@sonnenglanz.net; 
> dss-dev@lists.oasis-open.org
> Subject: AW: [dss-dev] DSS services and European Signature law
> 
> Hi Pim,
> 
> the big problem is not really related to the EAL 4+, but to the 
> SSCD-requirements (e.g. that nobody, not even the user, may be able to 
> retrieve the private signing key).
> 
> Those requirements imply that the hardware and the operating system 
> MUST be part of the TOE - and not its operational environment. This is 
> usually not necessary for an evaluation of a DSS-implementation as 
> signature application component(*).
> 
> Why would it be necessary to evaluate a DSS-implementation as SSCD and 
> not only as signature application component?
> 
> BR,
>  dh
> 
> PS (*): A "signature application component" is a piece of hardware 
> and/or software, which sends the data to be signed to the (S)SCD, 
> performes hashing and similar transformations and/or acts as 
> signature-verification device (Art 1 Nr. 8 1999/93/EC).
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Andreas Kuehne [mailto:kuehne@trustable.de]
> > Gesendet: Mittwoch, 13. Februar 2008 18:32
> > An: lists@sonnenglanz.net; dss-dev@lists.oasis-open.org
> > Cc: Huehnlein, Detlef
> > Betreff: Re: [dss-dev] DSS services and European Signature law
> > 
> > Hi Pim,
> > 
> > as this is a difficult topic I used Detlef as my backup expert ;-) 
> > Detlef confirmed my quick guess that each an every component of a 
> > DSS-based SSCD needs to evaluated on its own.
> > Usually that's would require an evaluation of a hardware
> component (
> > hopefully a smartcard with a testimonial ) and the software
> artifacts.
> > But an EAL 4+ evaluation of a software component would be extremely 
> > expensive and would need a re-evaluation with every minor release ..
> > would presume this to be overkill.
> > 
> > Don't think that's a way to ...
> > 
> > Greetings
> > 
> > Andreas
> > 
> > ----- Original Message ----
> > From: Pim van der Eijk <lists@sonnenglanz.net>
> > To: Andreas Kuehne <kuehne@trustable.de>;
> dss-dev@lists.oasis-open.org
> > Cc: veit@trustable.de
> > Sent: Thursday, February 7, 2008 4:15:09 PM
> > Subject: RE: [dss-dev] DSS services and European Signature law
> > 
> > 
> > Hello Andreas,
> > 
> > Thanks a lot for your response.  You are right that there are many 
> > more issues to consider to be able to state whether or not a DSS 
> > implementation meets EAL 4+.  To rephrase my question, more
> precisely,
> > assume we have some device that is certified to meet the
> requirements
> > of CWA 14169 that has a "trusted path" to a local user
> interface. For
> > instance, it could be a hardware device that uses the keyboard and 
> > monitor of a computer as user interface.  Now assume an alternative 
> > device that is similar in all ways except that it can be
> accessed from
> > remotely using DSS.  Would this device qualify as an SSCD?
> > 
> > Pim
> > 
> > 
> > ___________________________________________________
> > Andreas Kühne
> > phone: +49 177 293 24 97
> > mailto: kuehne@trustable.de
> > 
> > 
> > Trustable Ltd.
> > Niederlassung Deutschland
> > Ströverstr. 18 - 59427 Unna
> > Amtsgericht Hamm HRB 5868
> > 
> > Directors
> > Andreas Kühne
> > Heiko Veit
> > 
> > Company UK
> > Company No: 5218868
> > Registered in England and Wales
> > 
> 
>