FW: [dss] Use-cases and requirements - observations

["Nick Pope" <pope@secstan.com>]

By mistake I started a discussion with Tim Moses which was not copied to the
list - see below.

Nick

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: 08 July 2003 18:46
To: 'Nick Pope'
Subject: RE: [dss] Use-cases and requirements - observations


Nick - As I read the use-cases and requirement document, it seems to be the
intention for the client to instruct the service which message elements are
to be signed.  I am merely arguing that it must be possible for the service
to figure this out by itself.  All that is required is that the client
indicate to the service who is the intended recipient of its signed message.

I think a face-to-face discussion would be very valuable.

The only reason I didn't post this discussion to the list is that your
original message to me was off-the-list.

All the best.  Tim.

-----Original Message-----
From: Nick Pope [mailto:pope@secstan.com]
Sent: Tuesday, July 08, 2003 1:21 PM
To: Tim Moses
Subject: RE: [dss] Use-cases and requirements - observations


Tim,

I would hope that the policy controls we are talking about in terms of DSS
does not get into application policy questions such as what data is to be
signed, just what does DSS service do.  I would expect that the XML
signature references / xpath transforms etc would provide what is necessary
to identify the data to be signed.

Anyway I am suggesting to the list that we include this on the agenda of the
face 2 face meeting.

Nick

(Any reason for not copying this to the list, or was it just a case of
selecting the rely instead of reply all.)

> -----Original Message-----
> From: Tim Moses [mailto:tim.moses@entrust.com]
> Sent: 08 July 2003 16:55
> To: 'Nick Pope'; Tim Moses
> Subject: RE: [dss] Use-cases and requirements - observations
>
>
> Nick - I can't quite see how that would work.  If policy addresses such
> things as which elements in a message have to be signed, then
> there will be
> at least as many policies as there are message types.  Sounds
> like a lot of
> policies.  All the best.  Tim.
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: Tuesday, July 08, 2003 9:37 AM
> To: Tim Moses
> Subject: RE: [dss] Use-cases and requirements - observations
>
>
> Tim,
>
> I agree with your basic principle - simple client, complicated service.
>
> If there is a multiplicity of signature policies as you suggest then I
> agree.  However, I would expect that I few useful policies to emerge to
> support different type of usage.  DSS could help by defining some profiles
> which supports the most uses styles of operation.
>
> Nick
>
> > -----Original Message-----
> > From: Tim Moses [mailto:tim.moses@entrust.com]
> > Sent: 08 July 2003 13:55
> > To: 'dss@lists.oasis-open.org'
> > Subject: [dss] Use-cases and requirements - observations
> >
> >
> > Colleagues
> >
> > The rationale behind a services-oriented architecture is
> > cost-reduction: the
> > cost of maintaining complicated clients.  The instant a
> complicated client
> > is deployed, it is wrong.  And the activity of replacing wrong
> clients is
> > costly and unreliable.  Hence, the argument goes, deploy clients
> > that are so
> > simple, they can't possibly be wrong, and do the complicated stuff in a
> > server setting, where there will be many fewer instances of the
> > function and
> > the software environment will be much more stable and predictable.
> >
> > The client function implied by the DSS use-cases and requirements is
> > incredibly complicated.  Just from memory, the client has to
> > decide whether
> > to request enveloped or enveloping signatures, it has to decide which
> > elements it wants to be signed, it has to decide what policy is
> > appropriate
> > to its needs, and more.  If we can cost-effectively deploy and maintain
> > clients with this sort of complexity, why don't we just get
> them to create
> > and verify their own signatures?
> >
> > Consider this exercise: suppose 10 million small and medium-sized
> > companies
> > were to use signatures on their electronic transactions.  Suppose
> > that each
> > company were to deal with 100 trading partners in this way.  That's 1
> > billion pairs of security policies that have to be coordinated.  Suppose
> > each coordination exercise takes one working day for an expert
> in digital
> > signature standards and protocols, charging (oh, let's say)
> > $1,000 per day.
> > That's 1 trillion dollars to set the security infrastructure up
> (the first
> > time!).  That's the GDP of France.  If each contractor goes crazy after
> > doing 100 such assignments, then it will take 10 million experts to
> > implement a secure e-commerce infrastructure for small and medium-sized
> > companies.  That's the global supply of experts in this field
> for the next
> > 100 years.  Will DSS be lauded as the breakthrough that finally
> > made secure
> > e-commerce possible?  Maybe not!
> >
> > Consider the model provided by GSS-API.  The client tells the service to
> > whom it is trying to talk (GSS_Init_sec_context) and the data
> it wants to
> > send (GSS_GetMIC).  The service figures out what needs to be
> done: simple
> > client, complicated service.
> >
> > The DSS use-cases and requirements do not necessarily disallow such a
> > division of responsibilities.  But, it seems like an appropriate time to
> > point out that DSS will not be successful unless it can be
> compatible with
> > simple, inevitably-correct, clients.
> >
> > All the best.  Tim.
> >
> > -----------------------------------------------------------------
> > Tim Moses
> > 613.270.3183
> >
> > You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
kgroup.php