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 09:00:21 -0800
Message-ID: <CE541259607DE94CA2A23816FB49F4A34D60BD@vhqpostal6.verisign.com>
To: Daniel Ash <dash@68summit.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com>
Cc: Just.Mike@tbs-sct.gc.ca, reagle@w3.org, stephen.farrell@baltimore.ie, www-xkms@w3.org
I think it is critical that we have sojme language to explain this is an
option, otherwise we will end up with people developing XKMS' just to
add in the policy identifier.

Fortunately the term UseKeyWith is sufficiently neutral for this
purpose.

		Phill

> -----Original Message-----
> From: Daniel Ash [mailto:dash@68summit.com]
> Sent: Monday, December 02, 2002 11:44 AM
> To: Hallam-Baker, Phillip
> Cc: Just.Mike@tbs-sct.gc.ca; reagle@w3.org;
> stephen.farrell@baltimore.ie; www-xkms@w3.org
> Subject: Re: policy stuffing
> 
> 
> Sounds like the same effect.  As long as there is a place to bind 
> policy identifiers to a request/response for those who have this 
> requirement. I think wording should be added to make this 
> clear however.
> 
> -dan
> 
> On Monday, December 2, 2002, at 10:26 AM, Hallam-Baker, Phillip wrote:
> 
> > 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.
> >>
> > <smime.p7s>
> 

Received on Monday, 2 December 2002 12:00:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:40 UTC