Re: operational protocols

Patrick Richard <patr@xcert.com> Tue, 08 April 1997 20:20 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id NAA00691; Tue, 8 Apr 1997 13:20:39 -0700
Received: from crack.x509.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id NAA00637; Tue, 8 Apr 1997 13:20:25 -0700
Received: (from patr@localhost) by crack.x509.com (8.8.5/8.8.5) id NAA25986; Tue, 8 Apr 1997 13:16:46 -0700 (PDT)
Date: Tue, 08 Apr 1997 13:16:46 -0700
From: Patrick Richard <patr@xcert.com>
X-Sender: patr@crack
To: Stef Hoeben <Stefan.Hoeben@esat.kuleuven.ac.be>
cc: ietf-pkix@tandem.com
Subject: Re: operational protocols
In-Reply-To: <Pine.ULT.3.95.970408115054.783C-100000@dante>
Message-ID: <Pine.SGI.3.91.970408131051.25499C-100000@crack>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

On Tue, 8 Apr 1997, Stef Hoeben wrote:

> you). So (only) authentication (by the CA) of _all_ 
> answers the Directory gives are a solution to this
> spoofing, IMHO again.

Authenticated LDAP (via TLS or your choice of auth mechanism) solves the 
issue that you are describing. In the case of LDAP over SSL, a client 
only needs to accept a single root cert (the issuer of the directory 
server's cert), and can then accept (depending on policy) the remaining 
necessary compenents/information (including _other_ root certs) via the 
directory service.

Any information retreived in this fashion can only be trusted as much as 
the directory server is trusted (and in most cases, probably less).

For all of the requirements of PKIX part II, all of the information 
provided by the directory is already signed, so this really doesn't have 
anything to do with part II. It _does_ have implications if the use of 
LDAP as an OCSP is what you are talking about.

> > 			 Cheers, Stef > 

--
Pat Richard    /    patr@xcert.com
---
Public Key available via LDAP
   http://www.xcert.com