- From: Yassir Elley - Sun Microsystems <Yassir.Elley@Sun.COM>
- Date: Tue, 22 Jan 2002 17:11:21 -0500 (EST)
- To: Yassir.Elley@Sun.COM, stephen.farrell@baltimore.ie
- Cc: www-xkms@w3.org
> I also do not understand the Data Encryption example for a Locate > service in the spec. Why would the client just want an unvalidated > KeyName and KeyValue for Alice? What is the client going to do with > that information? He is certainly not going to use it to send > an encrypted document since he has no idea if this is really Alice's > key or if it is valid. Doesn't that fit the 1st scenario, that you mentioned yourself? (Where the client turns out to be pkix-aware?) The scenario I mentioned was where the Locate service would return a certificate or certificate chain which a pkix-aware client could then validate. The Data Encryption example given in the spec has the Locate service returning a KeyName and a KeyValue (the raw public key). I am not sure what even a pkix-aware client (that wanted to use that public key for encryption) would do with that information. It seems the pkix-aware client would have to construct a certificate chain itself to determine whether the KeyName was bound to that KeyValue. The Locate service doesn't seem to add much value in this example. I suggest that we use a more compelling use case in the spec for the Locate service. -Yassir.
Received on Tuesday, 22 January 2002 17:11:11 UTC