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?

> 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.)

> The configuration you propose is not one I believe is suited to the
> completely naive client where surely chaining with the Validate service
> doing the locate would be the configuration of choice.

Doesn't matter. It is possible and the spec has to say what to do about
it or else craft language that says "don't do that, and here's why".

> 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?

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

Received on Tuesday, 3 December 2002 12:04:57 UTC