Subject: some comments on draft-chadwick-pkixldap-v3-00.txt

From: Mark Wahl <[email-masked]>
Date: Tue, 13 Jul 1999 11:22:17 -0500

Section 2

In the first paragraph of this section you write:

> Other attribute description options SHOULD NOT be supported by clients. 
> Servers MAY choose to support them at their discretion.

This is problematic: if a server does support them but a client does not, then
that client cannot read an attribute with an option returned by that server.
I suggest your intent might be closer to the following statement:

> Other attribute description options SHOULD NOT be generated by clients, 
> since servers MAY choose to support them at their discretion.

In the last paragraph of this section you write:

> 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 MUST is redunant as this is the only location where the altServer
attribute has been suggested.  Second, what I think you are trying to say is
that it can't be filtered out by the server's access control policy.  The 
next sentence however I disagree with: I don't see the value of a attribute
pointing to itself.  I would propose replacing this with

> Deployments SHOULD provide for high availability of the directory, and this 
> attribute of the root DSE MUST when present be visible to properly 
> authenticated clients following this profile.

Section 3

> Servers SHOULD be able to return referrals to clients. 
> Clients SHOULD be able to receive referrals, although they are not required 
> to automatically process them and support multiple asynchronous outgoing 
> connections. 

The statement

> As a minimum, clients SHOULD be able to ask the user if the referrals are be
> cached locally and added to the set of servers known to the client. 

First, there is a typo "are be".  Second, it is not always the case that a
'user', presuming human user, is available to be asked.  The PKIX application
may be part of an automated system.  Third, I don't see the relationship 
between caching and automatically following referrals: I may want to have a 
client automatically follow referrals without caching them.   I propose that
this sentence be removed as it is not necessary to the protocol between the
client and the server.

Section 4

> 4. Features Of Ldapv3 That SHOULD NOT Be Supported

I don't like the title of this section.  It implies that it will limit 
interoperability should a client abandon an operation.  Furthermore, it is 
quite likely that a client will implement NOT ONLY this profile but others: 
a white pages profile, an access control profile, etc. I would prefer this
section to be:

> 4. Features Of Ldapv3 That Are Not Used by this Profile

In the first paragraph

> The client SHOULD NOT support the ModifyDN, Compare and Abandon 
> operations. The server MAY choose to support these operations at its 
> discretion.

The former sentence implies an interoperability problem with Compare and 
Abandon.  I think instead you are wanting to say that you are not using them. 
I don't see that the second sentence is needed.  I would suggest replacing this
paragraph with

> A client following this profile need not send the ModifyDN, Compare and 
> Abandon operations.

The second paragraph:

> The LDAPv3 protocol is infinitely extensible via two mechanisms: 
> extended operations and controls on existing operations. The client 
> SHOULD NOT generate any LDAPv3 protocol extensions (extended 
> operations or controls).  The server SHOULD NOT return any LDAPv3 
> protocol extensions (extended operations or controls).

Some control defintions are useful and are non-critical.   Furthermore, a 
client which DOES send a control (remember SHOULD NOT allows situations where
it is useful) needs a response.  I would suggest something more along the 
lines of: 

> The LDAPv3 protocol is infinitely extensible via two mechanisms: 
> extended operations and controls on existing operations. The client 
> does not need to generate any LDAPv3 protocol extensions (extended 
> operations or controls) when following this profile.  The server 
> SHOULD NOT return any LDAPv3 protocol extensions (extended operations 
> or controls) marked as critical except when requested by the client.

The third paragraph:

> LDAPv3 has the concept of unsolicited notifications that can be sent 
> from the server to the client. The server SHOULD NOT generate any 
> unsolicited notifications.

This contradicts the recommendations of the IETF operations area director, 
who requests that LDAP servers return an unsolicited notification to indicate
that they are going down, so that a client can distinguish between a server 
failure and a network failure.  I propose that this paragraph be replaced with:

> LDAPv3 has the concept of unsolicited notifications that can be sent 
> from the server to the client. A client MUST be prepared to accept
> unsolicited notifications defined in RFC 2251.

Next paragraph:

> LDAPv3 allows the subschema supported by the server to be published 
> in a subschema subentry. Subschema publishing is not needed for 
> normal PKI use, therefore the client SHOULD NOT try to retrieve 
> either the contents of the subschema subentry or the pointer to it 
> (held in the subschemaSubentry attribute of the root DSE) from the 
> server. The server MAY publish its subschema at its discretion.

Again, the term "SHOULD NOT" contradicts the text of 2251-2256: which says
that LDAP clients MAY.  And the last sentence contradicts 2251-2256 which 
makes schema requirement a mandatory aspect.  Furthermore, a client does
need to access the subschema in order to determine the supported matching
rule and matching rule use statements of the server to provide the check
for the extensibleMatch functionality in the end of section 5. 
I would propose replacing this with:

> 
> LDAPv3 allows the subschema supported by the server to be published 
> in a subschema subentry. Clients following this profile which support
> invoking a search containing an extensible matching rule SHOULD use the
> subschemaSubentry attribute in the root DSE and retrieve the subschema
> to determine whether the server supports the matching rule described in
> section 5.  

Final paragraph:

> Operational attributes are attributes stored by the server that hold 
> administrative information. Clients SHOULD NOT request any 
> operational attributes from the server other than the altServer 
> attribute, and the server need not store any operational attributes 
> other than altServer.

This contradicts X.500 and 2251-2252 which requires servers to maintain
operational attributes.  Again, this can be fixed in this document by
changing the statement of client behavior and removing the requirement
on server behavior.

> Operational attributes are attributes stored by the server that hold 
> administrative information. Clients following this profile do not need
> any operational attributes from the server, other than the altServer 
> attribute of the root DSE.

Section 5

First paragraph:

The term 'CPS' is not defined: an acronym expansion or reference to the 
defining text would be helpful for readers.

This draft uses "MUST" twice in the first paragraph for anonymous access,
but uses "SHOULD" for password protection and certificate-based authentication.
Could you explain why this is different?

Also, there needs to be a statement that support for TLS SHOULD be present 
when the client and servers are operating in environments where a CPS may 
state that information is not publically available.  BTW, I assume that a 
CPS is machine readable?  How does a server know when about to return a 
certificate or CRL that the CPS governing it requires confidentiality?

Second paragraph:

There is a "may" which is not capitalized.

Last paragraph:

> The parameters of the Search operation for "read" or "search" type 
> queries will usually be set as specified in RFC 2559. 

Not quite, as a client will be using userCertificate;binary,
caCertificate;binary, certificateRevocationList;binary, 
authorityRevocationList;binary etc as described in RFC 2256.

> However, X.509(1997) [9] supports flexible certificate matching by the 
> server, via the certificateMatch MATCHING-RULE. 

The OID and string representation of this matching rule should be given 
by this section, since the reference [9] is not suitable for a client to
be able to implement it.  AFAIK it is not yet published.  If X.509(1997)
is not expected to be published before this document goes into last call, 
perhaps this paragraph should be replaced by a statement that "Future
revisions of this specification may take advantage of the extensibleMatch
search filter item to locate certificates that match a particular pattern,
as defined in forthcoming revisions of X.509."

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 14 Jul 1999 20:39:24 +0100

Mark

Thankyou for your detailed comments.
In the test below, >> represents my original text and > represents 
Mark's comments and revised text

> This is problematic: if a server does support them but a client does not,
> then that client cannot read an attribute with an option returned by that
> server. I suggest your intent might be closer to the following statement:

My intent was to limit the coding effort of both clients and certificate 
servers. However I had only considered the case of requests with 
;options being sent from clients  to a server, and not vice versa as 
you had done. 

> Other attribute description options SHOULD NOT be generated by clients,

Agreed.

> since servers MAY choose to support them at their discretion.

We dont need the since. Keep it as a separate sentence.

In fact ;options are only used for attribute hierarchies (attribute 
subtyping) and in the case of X.509 attributes (certs, CRLs, ACs 
etc) I believe we do not have any supertypes and subtypes so in 
reality the situation should not arise. However we should still cater 
for the possibility in the draft as above. 

> The first MUST is redunant as this is the only location where the
> altServer attribute has been suggested. 

No its not redundant, because the LDAPv3 spec makes it optional 
and I wanted to make it mandatory. Hence the MUST was over 
storage, and not about the location. This same issue was raised by 
Rob Weltman of Netscape and this was my response to him

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.

> Second, what I think you are
> trying to say is that it can't be filtered out by the server's access
> control policy.  

As you can see from the rationale above this was not my primary 
concern. But you are correct. If a relying party or subscriber has 
access to the CRLs then he should also have access to the altServer.
How about if we add the following text

The access controls on this MUST BE the same or less than those 
on the certificates and CRLs. 

>The next sentence however I disagree with: I don't see
> the value of a attribute pointing to itself. 

It tells the client that backup servers dont exist anywhere else.

> I would propose replacing
> this with
> 
> Deployments SHOULD provide for high availability of the directory, and
> this attribute of the root DSE MUST when present be visible to properly

I like your text as well as mine, but I think mine is slightly stronger. 
We are at the wordsmithing approach now I think, since we broadly 
agree on aims.

> > Clients SHOULD be able to receive referrals, although they are not
> > required to automatically process them and support multiple asynchronous
> > outgoing connections. 
> 
> The statement
> 
> > As a minimum, clients SHOULD be able to ask the user if the referrals
> > are be cached locally and added to the set of servers known to the
> > client. 
> 
> First, there is a typo "are be". 
Thanks

> Second, it is not always the case that a
> 'user', presuming human user, is available to be asked. The PKIX
> application may be part of an automated system.   

Agreed.

>Third, I don't see the
> relationship between caching and automatically following referrals: I may
> want to have a client automatically follow referrals without caching them.

I see the relationship as follows. A client that always automatically  
follows referrals by parallel processing does not need to cache 
them. The user (human or application) always contacts the same 
directory server and always gets a response. Clients that are not 
able to automatically follow referrals in parallel have to cache one of 
more of them at least temporarily (even if its only in memory), and 
then follow them in sequence. Therefore in order to speed up 
subsequent requests it would be preferrable if the client made a 
more permanent cache of remote servers and then asked the user 
which one to contact, so as to avoid subsequent sequential referral 
processing. Finally clients that cannot support automatic processing 
of referrals (either in parallel or sequentially) must be able to support 
caching of the user would not get a proper service. This is what I 
was trying to get at in my badly worded text.

>   I propose that this sentence be removed as it is not necessary to the
> protocol between the client and the server.
> 

However if we remove it we will need to alter the preceding sentence 
which states "they are not required to automatically 
process them"
If a client is not required to automatically 
process a referral, nor cache it, then the user 
would not be able to obtain a distributed service.

> quite likely that a client will implement NOT ONLY this profile but
> others: a white pages profile, an access control profile, etc. I would
> prefer this section to be:
> 

Completely agree with you. Done

> Abandon.  I think instead you are wanting to say that you are not using
> them. I don't see that the second sentence is needed.  I would suggest
> replacing this paragraph with
> 

Agreed. Done. But I have kept the second sentence for 
completeness sake.

> > SHOULD NOT generate any LDAPv3 protocol extensions (extended operations
> > or controls).  The server SHOULD NOT return any LDAPv3 protocol
> > extensions (extended operations or controls).
> 
> client which DOES send a control (remember SHOULD NOT allows situations
> where it is useful) needs a response.  I would suggest something more
> along the lines of: 
> 
> extended operations and controls on existing operations. The client does
> not need to generate any LDAPv3 protocol extensions (extended operations
> or controls) when following this profile. 

I am quite happy with this re-wording. However, if we consider 
making the server implementation easier, your rewording does not 
actually help does it.

> The server SHOULD NOT return
> any LDAPv3 protocol extensions (extended operations or controls) marked
> as critical except when requested by the client.
> 

This one is more difficult. I dont like your rewording. Firstly some 
controls are always critical and some are chosen to be so by the 
client. Extended operations are never marked critical. So I would 
propose the following re-wording

The server SHOULD NOT return any LDAPv3 protocol 
extensions (extended operations or controls) 
apart from supported controls which were marked 
as critical by the user.

> who requests that LDAP servers return an unsolicited notification to
> indicate that they are going down, so that a client can distinguish
> between a server failure and a network failure. 

I submit to a higher authority. I was not aware of this.

> I propose that this
> paragraph be replaced with:
> 

DONE, and moved to the Must Support section

> Next paragraph:
> 
> > LDAPv3 allows the subschema supported by the server to be published in a
> > subschema subentry. Subschema publishing is not needed for normal PKI
> > use, therefore the client SHOULD NOT try to retrieve either the contents
> > of the subschema subentry or the pointer to it (held in the
> > subschemaSubentry attribute of the root DSE) from the server. The server
> > MAY publish its subschema at its discretion.
> 
> that LDAP clients MAY.  

Conformance wise, I dont believe this is a problem, as a profile can 
always say it wont use a particular optional feature. So the issue is 
one of whether it is needed or not for PKIX.

>And the last sentence contradicts 2251-2256 which
> makes schema requirement a mandatory aspect.  

I am aware of this, but again, a profile can decide not to use a 
mandatory feature (I believe so, but I may be wrong),

>Furthermore, a client does
> for the extensibleMatch functionality in the end of section 5. I would
> propose replacing this with:
> 

I agree that a skilled client implementation could make use of 
matching rule schema definitions and configure itself to use them or 
not with each server it talks to. I dont want to rule this out.

>  
> LDAPv3 allows the subschema supported by the server to be published in a
> subschema subentry. Clients following this profile which support

I prefer MAY here rather than SHOULD. What do you think

> > administrative information. Clients SHOULD NOT request any operational
> > attributes from the server other than the altServer attribute, and the
> > server need not store any operational attributes other than altServer.
> 
> operational attributes.  

Again, I dont think it is a problem for a profile to omit certain 
features. I was trying to limit the complexity of certificate server.

>Again, this can be fixed in this document by
> changing the statement of client behavior and removing the requirement on
> server behavior.
> 

I am happy with this. DONE. But I would still like to keep
"The server need not store any operational attributes other than 
altServer."

> defining text would be helpful for readers.
DONE

> but uses "SHOULD" for password protection and certificate-based
> authentication. Could you explain why this is different?
> 

Relying parties must have access to CRLs or they cannot validate 
the signatures. IF the CPS allows unauthenticated access this must 
be a MUST as it is the only way of doing it. If the CPS allows 
password based access there are several ways of doing it - hashing 
or clear over TLS (recommended therefore SHOULD) or passwords 
in the clear (not recommended but possible, hence we dont have to 
mandate the other two methods).

> CPS is machine readable?  

Unfortunately No. This is the topic of current research projects. So 
dont hold your breath. However, what happens in practice is that the 
CA sets its policy/practice then configures its clients to follow it.

>How does a server know when about to return a

This would be configured into the server by the CA (indirectly)

> There is a "may" which is not capitalized.

DONE, Ta

> authorityRevocationList;binary etc as described in RFC 2256.

I have added

The userCertificate;binary, caCertificate;binary, 
certificateRevocationList;binary, and 
authorityRevocationList;binary attributes, if 
specified, will be set as described in RFC 2256 
[13]. 

> The OID and string representation of this matching rule should be given by
> this section, since the reference [9] is not suitable for a client to be
> able to implement it.  AFAIK it is not yet published. 

Correct. However it is publically available on the BULL server (which 
ironically is better than it being published, because once it is 
published it will no longer be publically available (for free). I checked 
up on other PKIX docs that are RFCs and this is what they 
reference. So I could change the reference to this.

[X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments 
DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, 
DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 
9594-8 on Certificate Extensions, 1 December, 
1996.

I also agree that it would be good to repeat the 
OID in this document, along with the string 
represenation of the matching rule. Here is my 
text
"For convenience the string description of this 
matching rule is produced here:

( 2.5.13.35 NAME 'certificateMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 )"

However I need you to add a new definition to 
LDAP syntaxes as below:

CertificateAssertion  N 
1.3.6.1.4.1.1466.115.121.1.54 

David

> If X.509(1997) is
> not expected to be published before this document goes into last call,

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

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

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