RE: FW: changelog #A1

> On Wednesday 18 December 2002 13:18, Hallam-Baker, Phillip wrote:
> > I.E. we can assume a total compromise of the Locate service,
> > Mallet has full control over it and there is no compromise of
> > the system other than a loss of service.
> 
> There is a compromise in that I might ask John's email 
> address, and I will 
> be given the wrong information (e.g., address). 

Nope, you cannot do a directory lookup.

I don't believe that directory systems have any place in a PKI.
They have been worse than a failure.

We are not building a trusted means of discovering an RFC822 
email address here. We are building a means of locating information
that an application would use.


> > Failure of as validate service MAY result in a failure of the
> > system as a whole because the client MAY rely on it.
> 
> There is a compromise in that I might ask John's email 
> address as bound to a 
> public key, and I will be given the wrong information (e.g., key). 

No, you cannot make that query to XKMS. If you want to query for
<Name>John</Name> you need a completely different specification.


> (I presume the "MAY"s are not meant in the RFC sense, what do 
> you mean by 
> "system as a whole"?)

The first is a CAN as in CAN RESULT IN, and the second is a MAY
as in the client is allowed to take a decision on the basis 
of the information returned without further verification.

> Regardless, there's innumerable understandings 
> of trust [1] 
> that are further complicated by some of the odd ways in which 
> we overload 
> and use the term in English. Absent specific and shared 
> definitions of 
> these terms, I'd like to avoid the term all-together and 
> substitute a more 
> precise understanding of what we are trying to say in its place.

I would dispute the claim that there is no formal definition
of 'trusted system'. The term 'trusted computing base' has been
standard in the litterature since orange book.

However the text looks almost ok to me. I would reword the bit where it
gets fuzzy 'insert favorite' to be a list of steps that mention 
both PKIX and PGP scenarios.

I would also remove the bit that says that a validate service 
cannot aggregate. The agreement is that we do not address the
chaining issue in the group. That does not mean that arbitrary and
untestable requirements can be placed on services to prevent 
the chaining use being applied.

If the referal model is mentioned then the chaining model should
also be mentioned. 

We have a deployed chaining XKMS service that aggregates on a 
validate. That is what the wireless carriers want.

It is also the model that meets the original goal of shielding
the client from the horrors of PKI. The model I have been 
promoting is the Client asks the validate service for a key
and the validate service then grovels through whatever databases,
DNS, directories, Locate services etc it needs to get the 
answer.

If you have a client that is already PKI litterate then the
locate service makes a lot of sense since chain building
is hard while chain validation is relatively straightforward.
That way you still get your traditional end to end security.

The mixed model of do a locate first then throw the data at 
a validate service makes much less sense to me. I know people
think it is a winner but I don't see that myself. Why have the
client be a blind relay when the service can do the job for it?

		Phill