Re: policy stuffing

Phill,

Ok, we've eliminated issue#2 (degrees of freedom), but what's the 
answer to issue#1 after we do this? I.e. 

        Alice: Locate keys for Fred
        Responder: Here's Fred's key1 for UseKeyWith p1,p2,p3 and 
        his other key2 for p4,p5
        (Alice wants to encrypt to fred)
        Alice: Validate Fred's key1 for <<UseKeyWith stuff>>

What does the naive client, who has no idea of what p1-5 represent,
put in between the <<>> ?

If you say "p1,p2,p3" (i.e. all UseKeyWith values for key1), then 
explain the difference (if any) between that validate, and a validate
just containing "p1"? To give one problematic example, does valid(p1,p2,p3)
imply valid(p1) or not? This is the kind of policy arithmetic I don't
want us getting into.

If you don't say "p1,p2,p3", then you'll have to provide me with the
algorithm that the naive client uses 'cause I can't see anything that
doesn't involve Schiller's pixie dust. :-)

Stephen.

"Hallam-Baker, Phillip" wrote:
> 
> 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>
> >

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Received on Tuesday, 3 December 2002 07:23:06 UTC