RE: policy stuffing

All,

	Well we could simply back out and accepts Steve's proposal that
a policy is exactly equivalent to UseKeyWith and since a key binding can
already have multiple UseKeyWith statements call our problem complete.

	This has the added advantage that the policy qualifier can be
bound to a specific subject name. So for example we might have.

<KeyBinding>
   <blah/>
    <UseKeyWith Application="urn:ietf:rfc:2440"
Identifier="bob@bobcorp.test" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="bob@bobcorp.test" />
    <UseKeyWith
Application="urn:dns-name:tbs-sct.gc.ca:20021202:Policy:Level1" 
 		Identifier="C=CA O=UniversalExports CN=Bob Bobsweorthy"
/>
    <UseKeyWith
Application="http://www.nist.gov/fbca/policies/reallysecure"
		Identifier="bob@bobcorp.test" />
    <UseKeyWith
Application="urn:oid:10.234.23.1.23.1.3.45.1.33.43.2.1.3.1"
		Identifier="bob@bobcorp.test" />
   <blah/>
</KeyBinding>

	Thus stating that the key binding may be used for S/MIME, PGP
and complies with three specified policies.

	So we might put in a comment to the effect that if you must do
this policy stuff this is the preferred route, just to stop people
creating their own mechanisms and so helping the interop.

		Phill

> -----Original Message-----
> From: Just.Mike@tbs-sct.gc.ca [mailto:Just.Mike@tbs-sct.gc.ca]
> Sent: Thursday, November 28, 2002 10:44 AM
> To: reagle@w3.org; stephen.farrell@baltimore.ie; www-xkms@w3.org
> Subject: 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.
>