RE: [dss-x] Fwd: Presentation client and server signature

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

Hello Andreas,

Just a comment that a "polling" use case could be provided
by using the ebMS 3.0 transport binding for DSS:
http://docs.oasis-open.org/dss-x/profiles/ebxml/v1.0/oasis-d
ss-1.0-profiles-ebxml.pdf

In ebMS 3.0, it is possible to have a service provider that
is HTTP "client only":  it pulls requests, and pushes the
responses back. This message exchange pattern is referred to
as the "Two-Way/Pull-and-Push MEP" in ebMS 3.0. The
definition is in section 2.2.8 of:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_
core-3.0-spec-os.pdf

A main benefit of this is that no changes are needed to the
DSS messages, the polling functionality is provided by the
transport protocol binding, not by a DSS profile.  A regular
DSS sign/verify request can be polled, and a regular DSS
response returned. I'm not sure that is appropriate for the
use cases you're describing, but it may be of interest
anyway. 

A light client conformance profile for ebMS 3.0 is defined
in section 3.2 of:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/2007
07/ebms3-confprofiles-cs-01.html

This ebMS 3.0 conformance profile does not require any of
the "heavy" Web Services modules (security or reliable
messaging) and no HTTP server capabilities.  It can be built
using just HTTP client, TLS, SOAP/MIME and XML libraries, so
it is not hard to implement.

Pim

-----Original Message-----
From: kuehne@trustable.de [mailto:kuehne@trustable.de]
Sent: 14 February 2011 19:31
To: dss-x@lists.oasis-open.org
Subject: Re: [dss-x] Fwd: Presentation client and server
signature

Hi all,

I would like to make on Oscars use case :

In this scenario the client itself requests a signature ad
is holding the required private key, too. In this case
outlined request / response pair is a perfect fit.

In my use case the requirements a bit broader :
The client can request a document to be signed but
additionally there may be more requests ready to be signed
originated earlier / by other sources. So I would like to
propose a more general approach that solves both
requirements :

1. A signing request as we already know it. Usually
asynchrounous, as it may take an unpredictable amount of
time to be processed. It cannot be guessed in advance when
the user / the supervisor / the notary logs in again to sign
pending documents.

2. A polling-styled request to get new signing requests for
the local private key and to return encrypted hashes. This
new method can be consructed by the elements we already got
in the schema, just a bit twisted :

The client request holds a signing response to an earlier,
already processed call. And the server response transports
new signing requests stripped down to the plain bytes that
should be encrypted by the clients private key.

As this is a polling mechanism, responses and / or requests
may be empty.

3. The server returns the signature as the response to the
initial call from 1. .

This solution could cover both requirements without to much
extra burden on Oscar client-initiated signing. Just a
little bit of inversion-of-control ...


Greetings

Andreas




----- original Nachricht --------

Betreff: [dss-x] Fwd: Presentation client and server
signature
Gesendet: Mo, 14. Feb 2011
Von: Juan Carlos Cruellas<cruellas@ac.upc.edu>

>
>
> -------- Mensaje original --------
> Asunto:       Presentation client and server signature
> Fecha:        Mon, 14 Feb 2011 16:23:26 +0100
> De:   Òscar Burgos <oburgos@catcert.net>
> Para:         Juan Carlos Cruellas <cruellas@ac.upc.edu>,
<stefan@drees.name>
> CC:   Òscar Burgos <oburgos@catcert.net>
>
>
>
> Sorry for the delay.
>
> If we have time (I’ll be a bit late) we can discuss on
this mixed
> scenario and how can we approach it (whether it is
possible using a
> profile or adding new elements to the core)
>
> See you later.
>
> Oscar.
>
> _
>
>      
>      
>
> *Oscar Burgos Palomar*
> Àrea d'assessorament
>
>
> Agència Catalana de Certificació - CATCert Passatge de la
Concepció
> 11, 08008 Barcelona
> tel: 93 272 25 88 - fax: 93 272 25 39
> www.catcert.cat <http://www.catcert.cat/>
>
> _
> _
>
>      
>
> Aquest correu electrònic, així com qualsevol fitxer annex,
conté
> informació classificada. Queda prohibida la seva
divulgació, còpia o
> distribució a persones diferents del seu destinatari
exclusiu sense
> autorització prèvia per escrit de l'Agència Catalana de
Certificació -
> CATCert. Si vostè ha rebut aquest correu electrònic per
error, si us
> plau notifiqui-ho immediatament al remitent reenviant-lo.
>
>

--- original Nachricht Ende ----


------------------------------------------------------------
---------
To unsubscribe from this mail list, you must leave the OASIS
TC that generates this mail.  Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
groups.php