RE: FW: changelog #A1

I don't think the problem is with the explanation of the difference
between Locate and Validate. I think the real problem is that people
refuse to believe that there can be two operations that are identical
except in the degree of trust that is asserted. Lets get clear on the
processing model before we go onto the text...
 
 
Locate returns exactly the same information as Validate with the sole
exception that it explicitly does not undertake to meet even the minimal
requirements of a trusted service.
 
There is a major difference in the processing model for the client.
 
In the case of validate the client MAY rely on the information returned
directly. In the case of locate the client MUST accept responsibility
for validation.
 
There is a major difference in the deployment for the service.
 
A locate only service might be run on an untrusted machine in a location
with no physical security because the service can rely on the client
performing the validation step. This type of service would typically
return self authenticating data such as certificates, however one could
argue that a locate service would be adequate for distribution of raw
keys for 'promiscuous encryption' type scenarios in which the man in the
middle problem is not relevant since the choice is between encryption
susceptable to active attack and plaintext.
 
 
There is a major, major business reason for this. There is no way that I
can persuade enterprises to run their own XKMS discovery services if
they believe they have to secure them to the level required for
commercial grade PKI.
 
This is also a security reason, there should be no confusion between
trusted and untrusted infrastructure.
 
            Phill
 

-----Original Message-----
From: Slava Galperin [mailto:slava.galperin@sun.com]
Sent: Wednesday, December 18, 2002 1:19 AM
To: Hallam-Baker, Phillip
Cc: Www-Xkms (E-mail)
Subject: Re: FW: changelog #A1


IMHO, "intended use of the key" wording is still not precise enough. I
would like to have a generic specification of what is considered a
successful match between the QueryKeyBinding in the request and "target"
key binding. 

For Validate the most appropriate interpretation seems to be "superset"
("find(check if) a key binding which is good for all the intended
purposes simultaneously"): 


       (isAbsent(request.KeyInfo) or  target.KeyInfo = request.KeyInfo)
and 
       target.UseKeyWith "is-a-superset-of" request.UseKeyWith and 
       target.KeyUsage "is-a-superset-of" request.KeyUsage 


I am unclear if there is sufficient usage model difference between
Locate and Validate so that it makes sense to relax matching criteria
for Locate to "any" ("find  all key bindings good for any one of the
specified purposes but not necessarily for all of them at the same
time") : 
        (isAbsent(request.KeyInfo) or  target.KeyInfo = request.KeyInfo)
and 
        (isEmpty(request.UseKeyWith) or
nonEmptyIntersection(target.UseKeyWith,request.UseKeyWith)) and 
        (isEmpty(request.KeyUsage) or
nonEmptyIntersection(target.KeyUsage,request.KeyUsage)) 


We may also want to specify that we do not allow both KeyInfo and
UseKeyWith to be absent in QueryKeyBinding. 


Also what is the rationale for "Applications SHOULD NOT forward
<UseKeyWith> elements returned in a Locate result in a subsequent
Validate query." ? 

More generally, what is the rationale behind the "referral model in
which raw key binding information is obtained from a Locate service then
forwarded to a validate service" ? Why would a client go through a
two-step process instead of requesting "validated" keys directly from
Validate service through a single Validate request ?

"Hallam-Baker, Phillip" wrote: 



Element <UseKeyWith>

The <UseKeyWith> element specifies a subject identifier and application
identifier that determine a use of the key.
In the case of a <KeyBinding> or <UnverifiedKeyBinding> the <UseKeyWith>
element specifies a use of the key. If multiple <UseKeyWith> elements
are present each element specifies a use of the key.

In the case of a <QueryKeyBinding> or <TemplateKeyBinding> the
<UseKeyWith> element specifies an intended use of the key. If multiple
<UseKeyWith> elements are present each element specifies an intended use
of the key. 


Application     [Required] 
A URI that specifies the application protocol with which the key may be
used
Identifier     [Required] 

Specifies the subject to which the key corresponds within the specified
application protocol.
<UseKeyWith> application identifiers MAY be used to represent key
binding issuance and/or use policies instead of an application protocol.
In this case the <UseKeyWith> element specifies that the key binding
complies with the specified policy.

In the case that a client follows a referral model in which raw key
binding information is obtained from a Locate service then forwarded to
a validate service the <UseKeyWith> elements in the query should in both
cases specify the uses for which the application intends to use the key.
Applications SHOULD NOT forward <UseKeyWith> elements returned in a
Locate result in a subsequent Validate query.

-- 
Slava Galperin
mailto:slava.galperin@sun.com <mailto:slava.galperin@sun.com>  

For in much wisdom is much grief: and he that increaseth knowledge
increaseth sorrow. 


 
(Ecclesiastes 1:18)