Subject: Fwd: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 15 Jun 1999 12:51:36 -0700

Another new draft of possible interest to the group.

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-chadwick-pkixldap-v3-00.txt
>Date: Tue, 15 Jun 1999 14:56:36 -0400
>Sender: [email-masked]
>
>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:
>         [email-masked].
>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:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-chadwick-pkixldap-v3-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-chadwick-pkixldap-v3-00.txt>

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 16 Jun 1999 20:26:46 +0100

Date sent:      	Tue, 15 Jun 1999 20:41:37 -0700
From:           	[email-masked] (Rob Weltman)
Organization:   	Netscape Communications Corp.
To:             	[email-masked], [email-masked]
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:
> 
>   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
> 
> 
> [email-masked] wrote:
> 
> > 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
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
> >         readers exhibit different behavior, especially when dealing with
> >   ----------------------------------------------------------------------
> > Content-Type: text/plain

***************************************************

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 [email-masked]
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

***************************************************