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
- Re: operational protocols Housley, Russ
- Re: operational protocols Housley, Russ
- Re: operational protocols Patrick Richard
- Re: operational protocols Reginald Carey
- Re: operational protocols Stef Hoeben
- RE(2): operational protocols T.A.Parker
- Re: operational protocols Mike Smith
- Re: operational protocols Mike Smith
- Re: operational protocols Stef Hoeben
- Re: operational protocols David Boyce
- Re: operational protocols Stef Hoeben