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

RE: Question about Locate Service

From: Yassir Elley - Sun Microsystems <Yassir.Elley@sun.com>
Date: Tue, 22 Jan 2002 17:24:15 -0500 (EST)
Message-Id: <200201222223.RAA26062@bcn.East.Sun.COM>
To: Yassir.Elley@sun.com, stephen.farrell@baltimore.ie, pbaker@verisign.com
Cc: www-xkms@w3.org

It seems we are agreeing that the primary use case for the Locate service
is one in which the client uses the Locate service to retrieve a certificate 
or chain of certificates and then validates it himself. In this case, the client 
may use the Locate service because the client does not support LDAP or directory 
access, or because the client just doesn't want to deal with the complexity 
of constructing a chain of certificates.

I would suggest motivating the use of the Locate service in the spec
by using a compelling use case, such as this one. The examples that are
currently being used do not really explain why the client is using the
Locate service (rather than the Validate service).


	From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
	To: "'Yassir Elley - Sun Microsystems'" <Yassir.Elley@sun.com>, 
stephen.farrell@baltimore.ie, "Hallam-Baker, Phillip" <pbaker@verisign.com>
	Cc: www-xkms@w3.org
	Subject: RE: Question about Locate Service
	MIME-Version: 1.0
		I agree from the clients point of view. However from the service
	point of view there are many cases in which a service can provide the 
	function without being able to perform validate. To perform validate you
	have to have access to the certificate repository and the status
	information, that is not needed for locate.
		The main reason locate is there is because without it XKMS 
forces a
	model in which the client depends on the service for trust. While you 
may be
	correct in that being the model to follow, it is not a good strategy to 
	sacred cows like the end to end principle unecessarily.
		For example, say there was an XKMS service that provided locate
	service for the Federal Bridge CA on W2K. The part that W2K can't grok 
	the locate over cross-certified domains. However the client does have a
	pretty complete X.509 stack built in. There might well be a requirement 
	the client to do trust processing in the client. So the client fetches a
	cert chain using locate and verifies it using the validation path math 
	is much easier (in the general case) than the chain location match.
		While you may well be right that the service model is the one to
	adopt I see no reason to insist on baking that model into the protocol. 
	is going to have to work side by side with X.509/PKIX for many years. 
	Phillip Hallam-Baker FBCS C.Eng.
	Principal Scientist
	VeriSign Inc.
	781 245 6996 x227
	> -----Original Message-----
	> From: Yassir Elley - Sun Microsystems [mailto:Yassir.Elley@sun.com]
	> Sent: Friday, January 18, 2002 4:49 PM
	> To: stephen.farrell@baltimore.ie; Yassir.Elley@sun.com;
	> pbaker@verisign.com
	> Cc: www-xkms@w3.org
	> Subject: RE: Question about Locate Service
	> Phill,
	> I am not sure this is a very compelling use case. This would 
	> only be useful if 
	> the signature did not verify with the public key in the 
	> certificate, because
	> then the client would save the performance (and monetary) 
	> cost of a validation.
	> However, in the common case, the signature probably will 
	> verify. So, in the
	> common case, the client will be making two calls (a Locate 
	> followed by a 
	> Validate) and suffering the performance penalty of two calls, 
	> two round trips, 
	> etc, rather than just making a single Validate call. 
	> -Yassir.
	> 	Resent-Date: Fri, 18 Jan 2002 11:16:42 -0500 (EST)
	> 	Resent-Message-Id: <200201181616.LAA04603@www19.w3.org>
	> 	From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
	> 	To: "'stephen.farrell@baltimore.ie'" 
	> <stephen.farrell@baltimore.ie>, 
	> Yassir Elley - Sun Microsystems <Yassir.Elley@sun.com>
	> 	Cc: www-xkms@w3.org
	> 	MIME-Version: 1.0
	> 	Subject: RE: Question about Locate Service
	> 	Resent-From: www-xkms@w3.org
	> 	X-Mailing-List: <www-xkms@w3.org> archive/latest/53
	> 	X-Loop: www-xkms@w3.org
	> 	Resent-Sender: www-xkms-request@w3.org
	> 	List-Id: <www-xkms.w3.org>
	> 	List-Help: <http://www.w3.org/Mail/>
	> 	List-Unsubscribe: 
		In some circumstances a client may have a key that is 
		(or whose trustworthiness is not the issue) and merely want to
		have the locate service provide the key information.
		For example a transaction processor may receive a signed message
		with an attached X.509v3 certificate and query the locate 
		to obtain the public key parameters so that the signature
		can be performed.
		It is very likely that you would want to check the signature 
		you do the validation if you are paying a per validation fee.
		> -----Original Message-----
		> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
		> Sent: Friday, January 18, 2002 11:04 AM
		> To: Yassir Elley - Sun Microsystems
		> Cc: www-xkms@w3.org
		> Subject: Re: Question about Locate Service
		> Yassir,
		> I can see two functions that locate can perform. The one you
		> > I could understand if the client asked the Locate service 
		> to return an
		> > X509 certificate or chain of certificates, and then the 
		> client did the
		> > validation himself. Is that the intended usage of the 
		> Locate service?
		> one variant of which is called DPD in the IETF PKIX context 
		> and secondly
		> I can also imagine a client using a locate on a name, getting 
		> a (set of)
		> KeyInfo elements, picking one, and then doing a validate (say
	prior to
		> encryption). I'm not sure if others are considering this 
		> but I think it might be useful.
		> Stephen.
		> -- 
		> ____________________________________________________________
		> 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 Tuesday, 22 January 2002 17:24:01 UTC

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