[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-zeilenga-ldap-user-schema

Harald:


I am likely to vote DEFER on this document.  I really want to put a
longer hold on it, but I guess I will do that with a DISCUSS if needed.

Here is the political situation.  The LDAP folks have been trying to
figure out the best way to store certificates and CRLs.  This document is
the winning proposal, but the other proposal is not going away quietly.
I really want there to be only one answer.  The alternate proposal wants
to publish their solution as either Informational or Experimental.  I am
strongly opposed.
could you go into a little more detail here, please?
I scanned draft-zeilenga-ldap-user-schema-06 several ways, and could find no references (nil, nada, zero, none) to certificates and CRLs.

If you quote the names of the drafts (both!) that talk about certificates and CRLs, I can probably figure out what you're talking about, having helped muddy those waters before, but at the moment I just can't figure out the linkage.
There are some companion documents:
draft-klasen-ldap-x509certificate-schema-01
draft-legg-ldapext-component-matching-10
rfc3377

There may be more, too. I am having a real problem getting my hands around all of the parts. It would help me if the working group had requested publication of the block of related documents at one time, but of course, to the LDAP folks, certificates and CRLs are a small portion of the overall problem.

One aspect that I failed to mention in my original note is a change that was made from LDAPv2 to LDAPv3 in the use of ";binary". This was very poorly specified, and it had two uses. One a transfer syntax and the other as in indicator that the directory should not alter the object in any way between posting and retrieval. This later aspect is important for certificates. If the server applies the basic encoding rules (BER), then the client must decode it and re-encode it with the distinguished encoding rules (DER). It is far better for the original DER to be preserved.

I am getting quite frustrated about this issue. When everyone agrees on the long-term solution, I am reluctant to let alternative short-term solutions achieve RFC status that will cause bloat in clients, interoperability hassles for users, or, more likely, both.

I suspect that this note is not providing all of the clarity that you would like. I really want the working group to solve this issue. They understand this protocol much better than me.

One reason that I think a DEFER vote is appropriate is that it will allow the IESG to discuss this issue at the upcoming retreat, where we will have a much higher bandwidth channel. A face-to-face dialogue is probably desireable.

Russ