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 <<>> ?
> 
> I note you didn't answer, but would I be right that your answer
> is along the lines of "the client can't be that naive - it has to
> recognise and understand, or else ignore, the UseKeyWith values".
> In which case the answer would be "whichever of p1-5 it knows about,
> and wants, or else nothing", right?
> 
> 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. 

We can put a tweak in the area of UseKeyWith.


> > The naive client has to operate off applications, not policies. So
> > look for the key that is labeled for use with S/MIME or whatever you
> > want to use.
> 
> But there's no way to know what URIs are policies and what are
> applications (something I like, btw), so we cannot depend on that
> distiction. (Assuming that both apps and policies are represented
> via UseKeyWith.)

I would put it differently, the typical client will have a very narrow
scope and only care about the specific URIs for the very specific
application protocols it is trying to use at a given time.

The policy stuff will be very useful for Locate when done by fat 
clients at validating XKMS gateways.


> > What is the point of having the client do a Locate if it 
> does not have
> > any comprehension whatsoever of the data returned?
> 
> Because it happens. The client can't be expected to know abut 
> the actual
> UseKeyWith values that will be returned in a Locate response. 
> Seems to 
> me that assuming clients to be that policy-aware is a great 
> way to continually
> get "status=invalid" responses, (due to some irritating 
> policy gank mismatch) 
> which would IMO damage XKMS. Maybe you meant something else though?

That would seem to argue for some sort of attribute on the query
to distinguish the attributes that you want to match exactly
and the ones that are just there for information.

		Phill