[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt
Date sent: Tue, 15 Jun 1999 20:41:37 -0700
From: rweltman@netscape.com (Rob Weltman)
Organization: Netscape Communications Corp.
To: d.w.chadwick@iti.salford.ac.uk, ietf-ldapext@netscape.com
Subject: Re: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt
> David,
>
> Section 2 seems to contradict RFC 2252 concerning altServer. RFC 2252
> says:
>
> 5.2.2. altServer
>
> The values of this attribute are URLs of other servers which may be
> contacted when this server becomes unavailable. If the server does not
> know of any other servers which could be used this attribute will be
> absent.
>
> while your X.509 draft says:
>
> The altServer attribute is used by servers to point to alternative
> servers that may be contacted if this server is temporarily
> unavailable. This attribute MUST be stored in the root DSE of the
> server and MUST be available to clients for retrieval. If no
> alternative servers exist this attribute MUST point to the current
> server.
>
>
The first thing to note is that this is a profile for certificate and CRL
use of LDAP servers, and not for generic use of LDAP servers
(which is the remit of RFC 2252). Thus there are some special
requirements that the PKIX group will decide upon in due course.
Some of these may make mandatory what are currently optional
features in RFC 2252. I dont see a conflict in this. If you conform to
PKIX your server will always have this particular feature (whatever it
is), whereas if you dont conform to PKIX you may or may not have
this feature. Similarly other PKIX requirements may determine that
some RFC 2252 features are not needed at all for PKIX use. Again I
dont see this as a problem, do you? My draft is a strawman with my
initial thoughts about these issues, but ultimately the PKIX group will
decide collectively what they require from LDAPv3.
My rationale for making altServer mandatory is that CRLs
(especially) should be available 24 hours a day 365 days a year.
Thus a failsafe installation will have backup servers. These might be
at different addresses or at the same address (a cluster for
example), and altServer will say where they are located. Hence the
reason for making it mandatory.
> Also, I don't understand section 4 (Features Of Ldapv3 That SHOULD NOT
> Be
> Supported):
>
> The client SHOULD NOT support the ModifyDN, Compare and Abandon
> operations.
>
> etc.
>
> While it may not be necessary for an LDAP client using PKI to support
> these
> operations, why is it significant for PKI that a client NOT support them?
Here I was trying to simplify (minimise) the number of features that
a client has to implement. We can argue whether they should be
optional or not really necessary. (Note that SHOULD NOT does not
forbid implementation if you really want to, it says that you should
have a good reason for implementing it if you want to, otherwise
dont)
>
> The Abstract of the document says:
>
> This document describes the features of the Lightweight Directory
> Access Protocol v3 that are needed in order to support a public key
> infrastructure based on X.509 certificates and CRLs.
>
> but section 4 seems to list a number of LDAPv3 features which the
> document feels
> are not only not needed, but detrimental to a PKI infrastructure, and it
> does so without explaining why.
The reason is to minimise the implementation effort for both clients
and servers that are PKI specific. (For example there is an LDAPv2
client built into our PKI client, that is not a fully fledged client, but is
limited in its capabilities)
Hope this helps.
BTW, my draft is a stawman to shoot at, so keep on firing.
David
>
> Rob
>
>
> Internet-Drafts@ietf.org wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title : Internet X.509 Public Key Infrastructure
> > Operational Protocols - LDAPv3
> > Author(s) : D. Chadwick
> > Filename : draft-chadwick-pkixldap-v3-00.txt
> > Pages :
> > Date : 14-Jun-99
> >
> > This document describes the features of the Lightweight Directory
> > Access Protocol v3 that are needed in order to support a public key
> > infrastructure based on X.509 certificates and CRLs.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-chadwick-pkixldap-v3-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then
> > "get draft-chadwick-pkixldap-v3-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-chadwick-pkixldap-v3-00.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant mail
> > readers exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> > ----------------------------------------------------------------------
> > Content-Type: text/plain
> > Content-ID: <19990614143828.I-D@ietf.org>
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
*NEW* Mobile +44 790 167 0359 *NEW*
Email D.W.Chadwick@iti.salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************