RE: [dss] Policy-wise Server profile doc

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

Hi Trevor, just to summarize, you question the relevance of supporting
signed policy statements, partly because of complexity and partly because of
the fact that, as the DSS Server must already trust its client to send only
valid requests, it might as well also trust it to send policy.

With respect to complexity, I'm sure we could support signed policy with a
minimum of additional complexity. 

With respect to the latter, to my mind, you are conflating two different
trust decisions that the DSS Server needs to make - 'Is the request coming
from a trusted client?' and 'Do any policy statements in the request come
from a trusted policy authority (that is authoritative for the document to
be signed and the eventual recipient)?'

The DSS Server makes the first trust decision based on the identity of the
requestor and some criteria that defines the community of trusted clients. 

The DSS Server makes the second trust decision based on the origin of the
policy statements, and some combination of the nature of the doc being
signed and the eventual recipient.

It may be the case that the two communities - 'trusted clients' and 'trusted
policy authorities' are the same. Here, if a client can prove that it
belongs to the first, then the DSS Server needs no separate proof of origin
for the policy statements. However, when the two communities are disjoint,
membership in the first does not automatically guarantee membership in the
second, and the DSS Server will require some separate proof of the
authenticity of the policy statements - ergo signature

Thanks

Paul

>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: Tuesday, March 16, 2004 2:57 PM
>To: Paul Madsen
>Cc: dss@lists.oasis-open.org
>Subject: RE: [dss] Policy-wise Server profile doc
>
>
>
>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 
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_
workgroup.php.