RE: [dss] Policy-wise Server profile doc

[Trevor Perrin <trevp@trevp.net>]

Hi Paul,

I still have a couple questions.


At 10:33 AM 3/16/2004 -0500, Paul Madsen wrote:
> >>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.

Okay.  However, the gateway chooses the input documents sent to the DSS 
server.  So in your scenario, the gateway isn't trusted to create a policy, 
but it *is* trusted to get whatever it wants signed under a policy.

That seems backwards.  Consider the effects of a malicious gateway.  Your 
scenario stops (1) but allows (2):
  1) If a gateway creates a signature on a legitimate document with an 
illegitimate policy, the recipient will (probably) just reject the 
signature.  No big deal.
  2) If a gateway creates a signature on an illegitimate document with a 
legitimate policy, the recipient will think the sender said something he 
didn't.  Which *is* a big deal.

So if the gateway is trusted to choose the input documents, you might as 
well trust it with sending policy as well, and avoid the complexity of 
signed policy statements.

(Just to be clear: my objection is that *signed* optional inputs seem 
unnecessary.  If part of the rationale here is to allow for different 
policy languages, that's something I haven't considered.  I'm hung up on 
the signing part).


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

That might be a clean way to do it.


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

If the signature doesn't match the recipient's expectations, the recipient 
will just reject it, right?


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

I'm fine with having the request carry this info, as normal DSS optional 
inputs (use this key, and this policy URI, and add these properties, and so 
on).

It just seems overcomplex to have it signed.


Trevor