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

[Dr. Detlef Hühnlein <detlef.huehnlein@ecsec.de>]

Hallo Oscar, Pim, Andreas, Ezer,

if we keep the two layers (DSS-logic and transport binding) separate it 
seems to me that we will do not need to introduce very much, because
the SOAP-binding is already part of the Core and it would be sufficient to
refer to the PAOS-specification and only fix the details in a short
additional
section of a profile or the next version of the Core.

BR,
 Detlef 
 

> -----Ursprüngliche Nachricht-----
> Von: Òscar Burgos [mailto:oburgos@catcert.net]
> Gesendet: Montag, 21. Februar 2011 17:10
> An: Pim van der Eijk; kuehne@trustable.de
> Cc: dss-x@lists.oasis-open.org
> Betreff: RE: RE: RE: [dss-x] Fwd: Presentation client and server signature
> 
> Hi Pim and Andreas,
> 
> Thanks for your comments. Both of you are proposing a more advanced
> solution :) than the one I was explaining, where all the requests are
> synchronous and the control (requester) is always the client application,
not
> the DSS server. I still have to take a look to the ebXML profile, but I
don't
> know if this is the best approach to cover this use case. I will read the
profile
> specification.
> 
> Please take a look at this presentation:
> http://prezi.com/9wmcvk99onmh/use-cases-for-dss-x-client-signatures/, I
> tried to model the scenario and 3 use cases (the last one covers the
multiple
> signature scenario). It is still too generic as there is no detail in the
signature
> requests and responses, I will try to send some more information before
the
> end of the week.
> 
> Taking again Andreas proposal, I'm trying to understand the polling
> mechanism. If I'm not wrong it would be helpful to avoid storing in the
client
> application the "digests", and also to simplify the intermediate
> request/response protocol to return the result of the user's signature to
the
> DSS server. The only problem I see is that then, the client application
needs
> to be aware of requests coming from the DSS server. I'm afraid to be
adding,
> probably, too much complexity to the client's side. Maybe it's easier than
I
> expect, so anything you could say is welcomed.
> 
> BR,
> 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
> 
> _
> _
> 
> 
> 
> 
> 
> 
> 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.
> 
> 
> 
> -----Missatge original-----
> De: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
> Enviat: dimecres, 16 / febrer / 2011 18:03 Per a: kuehne@trustable.de;
dss-
> x@lists.oasis-open.org
> Tema: RE: RE: RE: [dss-x] Fwd: Presentation client and server signature
> 
> 
> OK, let's hear what other people think.
> 
> Pim
> 
> PS "ebXML stack" sounds somewhat intimidating,  an ebMS
> "light handler" can be (in fact my light handler is being)
> written as a set of Python scripts, so no need for complex
> and/or expensive toolkits or products.
> 
> -----Original Message-----
> From: kuehne@trustable.de [mailto:kuehne@trustable.de]
> Sent: 16 February 2011 17:30
> To: pvde@sonnenglanz.net; dss-x@lists.oasis-open.org
> Subject: Re: RE: RE: [dss-x] Fwd: Presentation client and
> server signature
> 
> Hi Pim,
> 
> thanks, now I see !
> My knowledge is pretty outdated, I'm not aware of all the
> new stuff introduced with version 3 ...
> 
> Yes, this inversion-of-control on the transport level will
> do the job. But I have some doubts that the Oscars likes to
> deploy an ebXML stack on his clients. Afaik the driving
> force of Oscar's approach was to keep deployments lean.
> 
> On the other hands is's always the better approach to use an
> existing solution in favour of building another
> hard-to-understand special way. As we once implemented this
> i-o-c hack I wouldn't have bet a penny that it could make to
> an OASIS profile ;-)
> 
> Let's see what the other think about it.
> 
> Greetings
> 
> Andreas
> 
> ----- original Nachricht --------
> 
> Betreff: RE: RE: [dss-x] Fwd: Presentation client and server
> signature
> Gesendet: Mi, 16. Feb 2011
> Von: Pim van der Eijk<pvde@sonnenglanz.net>
> 
> >
> > Andreas,
> >
> > What I was saying is that ebMS 3.0 in Pull mode offers
> exactly this
> > "inverted" model.  The DSS server would pull messages as
> an HTTP
> > client (initiator+receiver) from a DSS client that is the
> HTTP server
> > (sender+responder). The requests are pulled using a
> standardized
> > pre-defined pull signal message.
> >
> > In the ebMS 3.0 Part 1 Core that the DSS ebXML profile
> references, a
> > pull request pulls a single "UserMessage", and multiple
> such user
> > messages are polled by repeated polling.
> > If there is nothing to pull, there is a standardized
> response
> > indicating this. Section 5.2.4 of the Core also describes
> a way of
> > combining a UserMessage push and Pull request, which you
> want here.
> > The only limit is that the Part 1 Core bundling is limited
> to a single
> > user message per bundle. The ebMS 3.0 Part 2 defines a
> "bundling"
> > feature to pull or push a set of user messages. That makes
> it
> > equivalent to what you describe, and that is what I wanted
> to point
> > out.
> >
> http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/part2/201004/
> >
> >
> > If your WSDL operation definition is about responses that
> are
> > responses to requests made in a previous invocation of the
> operation,
> > and about requests that are new requests, the responses to
> which will
> > sent in a later invocation, then you are stretching the
> semantics of
> > "operation".  But as long as everybody understands what
> you're doing,
> > why not.  It's possible to define custom polling,
> bundling,
> > asynchronous processing protocols for DSS as for any other
> 
> > application.
> >
> > Pim
> >
> >
> > -----Original Message-----
> > From: kuehne@trustable.de [mailto:kuehne@trustable.de]
> > Sent: 16 February 2011 16:07
> > To: pvde@sonnenglanz.net; dss-x@lists.oasis-open.org
> > Subject: Re: RE: [dss-x] Fwd: Presentation client and
> server signature
> >
> > 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 ----
> >
> >
> >
> >
> ------------------------------------------------------------
> ---------
> > 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 ----
> 
> 
> 
> ---------------------------------------------------------------------
> 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_workgroups.php
> 
> 
> 
> ---------------------------------------------------------------------
> 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_workgroups.php