W3C home > Mailing lists > Public > www-xkms@w3.org > December 2002

RE: policy stuffing

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Mon, 2 Dec 2002 07:26:53 -0800
Message-ID: <CE541259607DE94CA2A23816FB49F4A34D60B2@vhqpostal6.verisign.com>
To: Just.Mike@tbs-sct.gc.ca, reagle@w3.org, stephen.farrell@baltimore.ie, www-xkms@w3.org

	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.

    <UseKeyWith Application="urn:ietf:rfc:2440"
Identifier="bob@bobcorp.test" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="bob@bobcorp.test" />
 		Identifier="C=CA O=UniversalExports CN=Bob Bobsweorthy"
		Identifier="bob@bobcorp.test" />
		Identifier="bob@bobcorp.test" />

	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.


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

Received on Monday, 2 December 2002 10:27:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:22 UTC