[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss-dev] DSS services and European Signature law
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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]