RE: policy stuffing

I agree completely. 

Blair
 
-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
Sent: Thursday, December 05, 2002 7:55 AM
To: www-xkms@w3.org

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
>

Received on Thursday, 5 December 2002 12:11:56 UTC