RE: [dss] Policy-wise Server profile doc

[Trevor Perrin <trevp@trevp.net>]

Hi Paul,

I responded to this before, but I was trying to get it out before the 
concall so it was really brief.  So I'll try to do better -

At 10:24 AM 3/22/2004 -0500, Paul Madsen wrote:

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

Yes.


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

Having to validate an XML-DSIG makes this more complicated than most other 
optional inputs.  Some DSS Servers might not even support XML-DSIG, or 
might support creating it but not validating it.

(also, I thought the point of a policy-wise server was to lessen burdens on 
the client by assuming the server already knows the policy?)

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

Suppose the policy doesn't come from a trusted authority.  What's the worst 
that could happen?  The DSS Server will sign with the wrong key, or put the 
wrong properties in the signature, or something, and the recipient will 
reject the signature.

So getting policy from a trusted authority is not very important.  OTOH, if 
the client sends a bogus document to be signed, that's a huge problem.

So if you trust the client to send an authentic document, you're vesting an 
enormous amount of trust in it.  So you might as well trust it a tiny bit 
more, to get the policy right.


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

Yes, I think that's always the case.

>However, when the two communities are disjoint,
>membership in the first does not automatically guarantee membership in the
>second

Perhaps you could show a more detailed scenario where it makes sense for 
the DSS server to trust the client to send the document, but not trust it 
to send the policy?  This still doesn't seem a very realistic set of trust 
relationships, to me.


Trevor