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

Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)




Peter:


Sorry that I didn't join into this thread earlier.

I agree with Michael that implementation-wise the child entry approach is very lightweight (only configuration in most of the clients, and no implementation issues in the server).

To sum up the discussion, the opinion in this group seems to be biased, and I can make out 4 different statements:

1. we should keep the current way of storing certificates and handel the
   problem of multiple certs via componentMatching if this is a problem
   at all.

2. we should change to the child entry approach because that will solve
   the problem of multiple certs (yes it is a problem) and will be far
   easier to implement.

3. we should propose both solutions in a way that they don't interfere
   with each other and let the implementers decide whether to implement
   one or both of the proposed solutions.

4. I don't care which one we choose, but we should definitey not have
   two different solutions.

We heard arguments for all 4 directions on this mailing list. I for one, as you can guess would prefer 2 or 3. I do understand 4 though, especially if I think about the cert validation proposals. Nevertheless two different solutions to one problem might be preferable here.

The client must include different code to implement #1 and #2. For #1, the client must pass the selection criteria to the server, and the server must implement componentMatching, which is far from ubiquitous today. For #2, the client must know to look for certificates in the subordinate entries. There are no mechanisms to keep these subordinate entires aligned with certificate content. So, both have their issues. I do not want to live with both sets of issues. Let's pick one solution, then work on that set of issues.


Since I am planning to publish a new version of the x509certificate draft some time in January, I would like to have some guidance from this group as to following questions:

- should the next version be published as a pkix draft?
- should the paragraphs discussing the alternative approaches stay in the draft?
- should the RFC track be specified and if so: proposed or experimental?

I would prefer to pick one solution, and publish the RFC on the standards track. It does not matter to me which working group sponsors the document.


Russ