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

[kuehne@trustable.de]

Hi Pim, 

I'm afraid I don't get your hint regarding the ebXML profile aligned with Oscar's problem ;-)

I'm thinking of adding a new operation to the wsdl, something like this 

		<operation name="pollingForSignRequests">
			<input message="impl:SignResponseList"/>
			<output message="impl:SignRequestList"/>
		</operation>

These are more or less the same structures as we know them from core, just wrapped into a 0..n List. But in contrast to the usual 'client calls, server responds' scenario, here the 'server' (the process holding the private key) calls the client (the process requesting the signature). With this call zero or more SignResponses of previous requests are send to the client and in return zero or more fresh SignRequests travel to the server.

This matches Oscars scenario where the browser serves as the 'server' as it has access to the private key. The browser periodically performs calls to the an instance where a specialized DSS process does all the pre- and postprocessing of the signature. But to a certain degree it plays the role of a client as it isn't able to encrypt a hash value.

This approach looks a bit wierd, especially as it intermixes the wellknown roles of server and client. But it's just a inversion of control to circumvent the inability of the web browser to be an endpoint of a call. It  serves as an originator of the polling calls.

I cannot an advantage of using ebXML as dtmu it just transports the payload for a given operation ...

Greetings

Andreas

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

Betreff: RE: [dss-x] Fwd: Presentation client and server signature
Gesendet: Mi, 16. Feb 2011
Von: 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
> 
> 
> 
> 
> 

--- original Nachricht Ende ----