Re: policy stuffing

I agree with all that, the question is whether we're at what
we all agree to be the goal. To try (again) to be clear: Are we 
now agreeing that all policy gank is placed in UseKeyWith
elements, *and* that clients MUST NOT emit a UseKeyWith value that
they don't "understand"? 

If so, then that means that responders can tell clients whatever they 
(the responders) want to, and the clients can (indeed MUST) happily 
drop the bits they don't understand on the floor. I'm fine with this
outcome. But, if there's a use case where a client is expected (somehow) to 
emit a UseKeyWith value that it doesn't understand then I believe we'd 
still have a problem.

And finally, I think a consequence is that responder's MUST NOT 
REQUIRE that specific UseKeyWith values be present in locate & validate
requests, since to do so would break interop with any dumb clients.
For example:

        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, but doesn't understand any
        of p1-5)
        Alice: Validate Fred's key1 with no <<UseKeyWith stuff>> present
        in the request
	Responder: key is good for UseKeyWith p1,p2,p3
        Alice: good enough for me; encrypts stuff to Fred

Stephen.

"Hallam-Baker, Phillip" wrote:
> 
> The use key with information is useful if the client is interested in
> it.
> 
> We have been over this whole policy stuff back and forth for the past 20
> years. It took folk 10 years to realise that they needed some policy
> info and it has taken another 10 to realise that obsessing about it is
> pointless.
> 
> There is a real need to be able to ask questions like 'what is the right
> key to use for S/MIME' and even 'what is the right key to use for
> Veterans administration security policy #4' - And get back answers of
> the form 'this key is good for S/MIME and good for policy #4'
> 
> Agreed that expecting the application to deal with the equivalence of VA
> policy #4 with OMB policy B6-NOFORN through requisite policy mapping is
> fantasy. But an XKMS service could do that stuff.
> 
>         Phill
> 
> > -----Original Message-----
> > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> > Sent: Wednesday, December 04, 2002 1:08 PM
> > To: Hallam-Baker, Phillip
> > Cc: Daniel Ash; Just.Mike@tbs-sct.gc.ca; reagle@w3.org;
> > www-xkms@w3.org
> > Subject: Re: policy stuffing
> >
> >
> >
> > In which case, what's the point of the UseKeyWith in a locate or
> > validate response at all? (Ignoring request/response integrity for
> > the moment.) If its just informational gank then that's ok, but
> > then we ought to have UseKeyWith be an element that a client puts
> > in requests, and MightBePolicyGank be an element that lives only
> > in Responses and which *never* needs to be processed by any client.
> >
> > Maybe its late here and I've lost the plot, but does the above
> > (were it to be accepted) basically get rid of "policy" entirely?
> > If so, good:-)
> >
> > Stephen.
> >
> > "Hallam-Baker, Phillip" wrote:
> > >
> > > Actually what I think the client should do in this case is
> > ONLY forward
> > > the UseKeyWith that describes what it wants to do AND NOTHING ELSE.
> > >
> > > The use key with data is not authenticated so there is no
> > reason that
> > > the validate service should have the slightest interest in the
> > > information.
> > >
> > > So if the client wants to do S/MIME it simply strips out all the
> > > usekeywiths returned in locate and forwards the usekeywith
> > for S/MIME.
> > >
> > > The validate service may be interested in the policy info
> > but it will
> > > have to get the data from a trusted source so the request
> > can't be it.
> > >
> > >                 Phill
> > >
> > > > -----Original Message-----
> > > > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> > > > Sent: Wednesday, December 04, 2002 10:06 AM
> > > > To: Hallam-Baker, Phillip
> > > > Cc: Daniel Ash; Just.Mike@tbs-sct.gc.ca; reagle@w3.org;
> > > > www-xkms@w3.org
> > > > Subject: Re: policy stuffing
> > > >
> > > >
> > > >
> > > >
> > > > > > In that case, I still have to ask whether
> > valid(p1,p2)=>valid(p1)
> > > > > > and regardless of whether that's a "yes" or "no", what goes in
> > > > > > the spec?
> > > > >
> > > > > OK, I believe the answer is yes.
> > > >
> > > > So its wrong/a bad idea to define & use p1, p2 & p3 as follows:
> > > >
> > > > p1: key is generated according to rules a,b,c
> > > > p2: key is good for €1000
> > > > p3: key is good for $1000
> > > >
> > > > where a responder is configured (howsoever) with the following
> > > > logic:
> > > >
> > > > if (p1) {
> > > >       if (p2 || p3) status=notYetInvalid;
> > > > } else {
> > > >       status=Invalid;
> > > > }
> > > >
> > > > Does that sufficiently illustrate the quagmire of exposing policy
> > > > arithmetic? I'm sure equally daft examples could be given if
> > > > you'd said "no" above.
> > > >
> > > > But, I don't think we need take this further for now
> > (unless someone
> > > > else wants to chime in), until we've text that captures
> > this thread.
> > > >
> > > > Stephen.
> > > >
> > > >
> > > > --
> > > > ____________________________________________________________
> > > > 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
> > > >
> >
> > --
> > ____________________________________________________________
> > 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
> >

-- 
____________________________________________________________
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 Thursday, 5 December 2002 11:26:48 UTC