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

[Tim Moses <tim.moses@entrust.com>]

Trevor - It sounds like we are in agreement.  I don't object to having a
service interface that "allows" clients to control the plethora of choices.
I merely want to provide adequate support for those that can't.

The main lesson from GSS_API is that the interface must allow the client to
stipulate who the intended recipient is.  It's pointless signing a message
in conformance with one's own policy, if it does not conform with the policy
of the recipient.  So, the service has to know who the message is intended
for.  I am thinking of B2B Web-services in which there is a single
Web-service end-point or WSDL port.  This would not require wild-carding.

All the best.  Tim.

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Tuesday, July 08, 2003 6:13 PM
To: Tim Moses; 'dss@lists.oasis-open.org'
Subject: Re: [dss] Use-cases and requirements - observations



Hi Tim,

these are great points, I'll try my best to address them.

At 08:55 AM 7/8/2003 -0400, Tim Moses wrote:

>Colleagues
>
>The rationale behind a services-oriented architecture is cost-reduction:
the
>cost of maintaining complicated clients.

That's an important rationale for *some* of our use cases, but it's not the 
only one.

Consider an "applet-signing" service that an ISV hosts for its 
developers.  The rationale is to keep the code-signing key in a single, 
secure location, and to authenticate code-signing requests and maintain a 
record of who signed what when.

In this case, client complexity isn't the problem we're trying solve - 
jar-signing tools are easy to use (though it's not a problem we want to 
introduce either, so your points are still relevant to this case).


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

Agreed, that's a great statement of principle.  That's why I like the 
identified requestor / delegated signing case vs. client-side PKI, for
example.


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

What if the client doesn't *have* to decide these things, he just has the 
option of doing so?  And similarly, profiles of DSS don't *have* to support 
all the DSS options, only the relevant ones?

For example, the above code-signing service doesn't need client-side 
hashing, or any XMLDSIG complexity (which elements to sign, where to put 
the signature, what transforms to apply, sending multiple inputs of 
different formats).  So a profile for jar-signing should be very simple.

Now consider a DSS server that basically just holds the client's private 
key, and signs whatever the client wants signed.  If the client says "sign 
these 3 XML elements from this document, applying these transforms, and 
return me a signature which I can splice in at this particular point ", 
then the assumption is that the client finds requesting all these options 
less complicated than actually performing them himself (hashing and 
transforming the inputs, and managing his own private key), for 
example.  As long as that's true for at least some clients, I think we 
should leave these features in.

Admittedly, it gets pretty complicated, when we factor in that the client 
may also do client-side hashing and transforming of some inputs.  But I 
think if we're going to do one thing really, really well it should be 
giving clients as much power as possible in creating and verifying 
signatures.  Profiles of DSS, like EPM, eNotary, code-signing, email, etc., 
can shave off what they don't need, but it would be embarassing if someone 
found they needed more flexibility in handling signatures, since that's our 
core functionality and chief reason for existence.

I also think that how complex these things really are will be more apparent 
as we start the protocol design, and if it looks like particular things are 
going to be a tarpit, we can reconsider.


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

Your point is that if there's too many options, each pair of participants 
will have to negotiate beforehand on which to use?  Hopefully there will be 
profiles of DSS that satisfy particular business/legal requirements, and 
communities will just have to agree on a profile.

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

I agree, but I guess I'm arguing this is more a problem for profiles of DSS 
then the generic protocol itself.

Trevor