W3C home > Mailing lists > Public > www-xkms@w3.org > January 2002

Re: Question about Locate Service

From: Stephen Farrell <stephen.farrell@baltimore.ie>
Date: Mon, 21 Jan 2002 09:49:12 +0000
Message-ID: <3C4BE418.874AEFF6@baltimore.ie>
To: Yassir Elley - Sun Microsystems <Yassir.Elley@sun.com>
CC: www-xkms@w3.org


Yassir Elley - Sun Microsystems wrote:
> Stephen,
> I am not sure I understand the second option you suggest.
> Are you suggesting that the client would send a KeyName of Alice
> to the Locate Service and would request a Certificate and the
> Locate Service would return several Certificates for Alice
> and the client would then select one of the certificates that
> contained Alice's encryption key and send that to the Validate service?
> If so, wouldn't it be simpler just to call the Validate service and
> request a particular KeyUsage (of Encryption)? 

Maybe yes, maybe no. That depends on the application context which
is what we (want to) know nothing about! My argument would be that
the scenario I've described means that applications can work ok
even if we haven't defined how to describe every last possible use 
for a key, in particular, we don't have to have an n-r bit anywhere!

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


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 Monday, 21 January 2002 04:48:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:17 UTC