RE: [dss] Policy-wise Server profile doc

[Paul Madsen <p.madsen@entrust.com>]

Hi Trevor, apologies for delay

inline

>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: Sunday, February 29, 2004 7:53 PM
>To: Paul Madsen
>Cc: dss@lists.oasis-open.org
>Subject: RE: [dss] Policy-wise Server profile doc
>
>
>
>Hi Paul,
>
>Sorry I didn't respond earlier.
>
>
>>>Use Case
>>
>>1) SOAP Client in remote policy domain sends SOAP Request for some
>>application - request includes security policy for eventual response -
>>policy specifies client's policy for particular elements to 
>be signed in
>>subsequent response. Policy statement is signed.
>>2) SOAP Request intercepted by SOAP Gateway, clients policy 
>requirements
>>extracted and stored. SOAP Gateway forwards on request to application
>>3) Eventual outgoing SOAP response is intercepted by SOAP 
>Gateway. gateway
>>builds DSS <SignRequest> to send to DSS Server,
>>4) SOAP Gateway sends <SignRequest> to DSS Server, includes previously
>>cached policy statement
>>5) DSS Server validates signature over policy statement, determines
>>appropriate intersection of policies, signs accordingly.
>>6) DSS Server sends <SignResponse> to Gateway
>>7) SOAP Gateway returns SOAP Response to SOAP Client.
>
>
>Is it necessary for the policy statement to be signed?  I 
>guess that stops 
>the gateway from modifying the policy statement.  But does it? 
> The gateway 
>could invent an entirely new policy statement, from scratch, that was 
>similar to the signed one but different in one respect.  Or it could 
>mix-and-match signed policy statements with outgoing SOAP responses.

Its unlikely that the DSS Server would recognize the gateway as
authoritative for policy for the remote domain. So, even if the gateway were
to sign the modified policy statements, the trust that the DSS server might
have for the gateway wouldn't go so far as recognizing it as a policy
authority.  
>
>So it seems the gateway has to be trusted to request 
>signatures.  In which 
>case, the SOAP Client in the remote domain just needs to tell 
>the gateway 
>what DSS parameters to use, and the gateway just needs to use 
>those.  That 
>wouldn't require a DSS protocol change.

I think we could do it without a protocol change if necesary. Rather than
defning a new PolicyContainer, we could have the DSS client insert the
Signed Policy Statement within the <OptionalInputs> and use the existing
<ServicePolicy> element to indicate the name of the policy.

>
>I dunno, I'm just having trouble imagining a setup of trust 
>relationships 
>that would require someone besides the sender of a request to 
>vouch for 
>only the policy portion of the request.

In distributed scenarios, the eventual recipient of a signature may have its
own expectations of that signature. The DSS Server must be confident that
these expectations did indeed come from the eventual recipient or from some
other entity who has the right to defined policy for the signature
recipient. 

Either the request carries this info or the DSS goes and asks the signature
recipient.

>
>If some other party wants to tell the sender what parameters 
>to use, that's 
>one thing, but it seems we're looking at something more subtle here..

I'm not thinking of anything more subtle - this is indeed what I want to
support, albeit in a manner that allows the DSS server to determine the
validity of the policy statements.

Paul

>
>
>Trevor  
>