policy stuffing

After last week's call Phill and I and Don had a disussion about the
handling of policy URIs in xkms. We didn't reach any real conclusion 
(in fact Phill & I disagreed fairly convincingly:-) but I'll try to 
capture what I think are the two main issues below. 

Note: This description is probably biased - and just so you know, my 
bias would be to drop the whole idea of including policy URIs in xkms.
Phill's position is along the lines that including this is a real 
requirement, so we have to iron out whatever problems are there, but 
I'm sure he can explain that himself.

Issue#1: There is a problem with policy URIs if more than one is allowed
in a single xkms messaage, and if care is not taken. The problem is shonwn 
below happening to Alice (an xkms client) when she uses a responder to find 
out about Fred's keys.

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

The problem is what to put in the <<policy stuff>> slot. 

If Alice puts in all policies for that key does the responder
treat that as an "all" or as an "any"?
	If it means "all", does that mean that the key is to be 
	used in (simultaneous) accordance with the rules associated
	with all of the policies. If so, is that (in general) 
	possible?
	If it means "any", presumably the validate response will
	contain only those (one only?) where the validate "works",
	which breaks a kind of symmetry we used to have between
	locates and validates, which may produce bugs.
If Alice has to select some policies, then she has to have something
configured into her to allow the selection, which increases the
likelihood that the wrong thing is configured, and hence the liklihood
of a lack of interoperability. Basically having clients doing policy
arithmetic is one of the things we started xkms to avoid!

I also suspect that the presence of both UseKeyWith and policy URIs makes
it harder for Alice to figure out whether she ought do the validate on 
Fred's key1 or key2, but maybe that's just a detail.

Finally for this issue, there is the use case where Alice does the 
Locate against an untrusted responder (presumably "close" to Fred,
say via a DNS srv record), and then does the Validate against her
own favorite responder, which she does trust. How should policies be
moved from the locate response to the validate request and then to
the validate response, and are there any checks that Alice has to
make, e.g. comparing the policies from teh Validate response against
those from the Locate response?

Issue#2 might simply amount to having to be very clear in the spec. but 
right now I don't know what the right approach ought to be. The problem is 
that we already have two degrees of freedom required to be supported at the 
client - that is, the client has to know the responder location (or SOAP actor) 
as well as having some knowledge of UseKeyWith values. Now either of those 
could be used to separate different policies, so I don't see how to justify 
the additional degree of freedom represented by policy URIs, nor how to 
offer guidance for deployment as to what makes sense. It seems to me
that we're just building ourselves yet another X.509 CP/CPS consultancy
quagmire here.

Anyway, we clearly could do with some list discussion on these, 
Stephen.

PS: Does anyone else think that issue#1 also applies to anything
else handled syntactically the same way? In particular UseKeyWith?


	

-- 
____________________________________________________________
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 Wednesday, 27 November 2002 07:24:42 UTC