RE: policy stuffing

I have mixed feelings regarding the inclusion of a policy URI as part of a
client request.  (Just so we have the same picture in mind, I'm assuming
that such a URI might point to a list of acceptable policy OIDs, acceptable
root certs, permitted subtrees, etc that the certificate in question would
be validated against. Such detail is abstracted from the client, and
implementation-dependent at the XKMS service. Presumably, the application
would automatically submit such a URI as part of their request, possibly
with manual user intervention for selection.)

On one hand, I can describe scenarios in which such a feature would seem to
be helpful.  For example, if I'm using an application for sending classified
information, I want to ensure that the encryption certificate that I use is
successfully validated to a classified assurance level.  Even further, I
might want to validate a certificate such that a successful path is built to
either Bridge #1 or Bridge #2, but not Bridge #3. Therefore, there might be
a policy that corresponds to "Bridge#1-Classified."

On the other hand, I thought that the whole point of XKMS was to provide a
simpler protocol (when compared to PKIX counterparts), removing the material
that most felt was excessive, as opposed to re-writing the protocols from
ASN.1 into XML.  I also assumed that this simplicity implied that the client
did not have to have as much information regarding their acceptable roots,
etc., as this would be "managed" by the XKMS service.  As Stephen points
out, we seem to have this information limited to a Service URI and
UseKeyWith - the worry is that the policy URI either goes one step too far,
or even further, puts us on a slippery slope (e.g. what about the client
that wants to ensure that a certificate is suitable for verification of a
transaction over $1M). 

In summary, I think that a lot of the detail can and should be managed by
the XKMS service, but we might still need to support the client who says
"I'm doing BLAH with my application".  As I highlight above, the problem
that we might be running into now is that we're trying to solve situations
that are more closely related to authorization than to authentication (or
it's quite possible that I've just stepped on the damn slippery slope in
this email).  If this is true, we should consider carefully what features
should be pushed to XKMS v2 consideration.

In any case, I don't think I've convinced myself either way yet (and
possibly even confused myself :-), but I hope this stimulates some further
thought. 

Cheers,
Mike  



 -----Original Message-----
From: 	Joseph Reagle [mailto:reagle@w3.org] 
Sent:	November 27, 2002 2:31 PM
To:	stephen.farrell@baltimore.ie; www-xkms@w3.org
Subject:	Re: policy stuffing


On Wednesday 27 November 2002 07:20 am, Stephen Farrell wrote:
> PS: Does anyone else think that issue#1 also applies to anything
> else handled syntactically the same way? In particular UseKeyWith?

This relates to my concern about the semantics of the query. Regardless, on 
the Policy front, let's keep it simple and say there is *one* Policy URI. 
That means if you want to validate under multiple policies, you need to 
send multiple requests, or the service can offer a URI with multiple 
policies composed in one. Anything else gets too complex and then indicates 
that the policy should be like any other thing, party of the query under a 
well defined query model.

Received on Thursday, 28 November 2002 10:44:31 UTC