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


Help: OASIS Mailing Lists Help | MarkMail Help

dss-dev message

[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 and other,

The question I basically have is about the difference between two
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

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


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

Why would it be necessary to evaluate a DSS-implementation as SSCD and not
only as signature application component? 


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]