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

[Trevor Perrin <trevp@trevp.net>]

At 08:01 PM 7/8/2003 +0100, Nick Pope wrote:
>Content-Transfer-Encoding: 7bit
>
>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.

You're right, this should be optional, to allow for cases where the server 
can figure this out by itself.  I'll add text in 3.4.1 and 3.4.2 to make it 
clear that the client can omit these options and let the server decide if 
it wants.

Some profiles of DSS might go further and not allow the client to send 
these options, so that servers could be simpler.

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

Right now, the idea is that any options not explicitly requested by the 
client are controlled by the "Signing Policy", and that a server will have 
a default Signing Policy, though a client could request a different one.

So a server can have one policy where it signs a particular part of a 
document in a particular way using a particular key and following a 
particular archiving strategy and adding particular signed attributes, and 
another policy where it does all these things differently, and the client 
doesn't have to request each difference separately, but is just configured 
to request one policy or another (by contacting different URIs, or 
different WSDL endpoints/interfaces/services/whatever, or something).

Is that sufficient?  Or do we need something like an <IntendedAudience> 
element, where the client says "I want this signature to be verifiable by 
Alice@Acme.com and Bob@Acme.com".

Something like that might seem more precise, but I worry it would get 
complicated.  We'd need to add wildcarding, and different name forms..

Trevor