I'm talking about CertificateAssertion, not CertificateExactAssertion. The former allows matching by issuer, subject, subjectAltName, and several other useful fields. The latter only allows matching on issuer and serial number. Of course, you must know all about this if you invented them both. But I want to be clear about what I was talking about.
With respect to your argument that all clients support your schema without code changes, not all clients do a full subtree search. Some just retrieve the certificates directly from the user's or CA's directory entry. Yes, you can work around the problem by storing the certificates in both the old and the new location but that has all the consistency problems that have been described elsewhere.
Steve Hanna wrote:
David,
Thanks for providing some information on server support for your schema and for component matching. I would like to mention that component matching is not the only server-side solution. X.509 and draft-zeilenga-ldap-x509-00.txt (the successor to RFC 2587) include a CertificateAssertion that should be easy to implement on the server side.
Steve
I believe that this matching rule and assertion was first provided by myself in "Additional LDAP Schema for PKIs and PMIs" <draft-pkix-ldap-schema-00.txt> in July 2000. And the exact match was implemented shortly afterwards in OpenLDAP. So exact certificate matching is not difficult. It is when you want to match on arbitrary certificate contents that it gets difficult.
All LDAP clients that allow configuration of the attributes to be searched for support attribute extraction
regards
David
You say that "all clients can naturally support
[your schema] without any code change". This isn't
true.
Sorry, but it is. In your argument below you forget two things. Firstly when searching for an entry you do NOT know the DN of the entry (otherwise a full subtree search is not needed, and a pseudo-read [search base entry only] is used). Thus is makes no difference where the certificate is located with a full search. Secondly, by storing the certificate in both places, which is specifically allowed for, then both sets of clients can be supported ie. ones that know where to read, and ones that dont.
> Any client that tries to retrieve certificates
from an LDAP directory will need to look in a different location. If the client doesn't know which schema is in use (which will often happen since clients are rarely configured with schema information), it must look in both places. Maybe you mean that clients don't need to change if the certificates are stored in both locations, but this is only a transitional situation.
So I would say it's more accurate to say that clients must change for your solution but need not change for the CertificateAssertion or component matching solutions. Could you tell me about any clients that support your solution? I believe it's true that there are many more client applications than server applications so it will be much more difficult to change the clients than the servers.
Thanks,
Steve
David Chadwick wrote:
Steve
we have had the meeting at IETF 56 and the majority agreed that component matching was the best long term solution to aim for. That is on the record. But also on the record is the note that vendors appear to be reluctant to support this, and that support for attribute extraction is a short term pragmatic solution that is much easier for suppliers and users to support. It does not add complexity to clients, on the contrary it makes it easier for clients. Consequently the ADs agreed that component matching should be published as Information RFCs.
Since that time (Spring 2003) suppliers have not moved that far (if at all) towards supporting component matching. Only Steven Legg's Australian company, which had supported component matching prior to publication of the RFCs, and OpenLDAP which I believe can now support it, have done anything in this direction. Attribute extraction on the other hand has double that amount of supporting implementations, plus all clients can naturally support it without any code change.
So whilst we might all like the ideal today, pragmatically we need to recognise that this is not the situation on the ground today. If it were I would happily forget the attribute extraction IDs. My main desire is that we need to provide LDAP support to X.509 users today. We should recognise that it will be many years before the big LDAP suppliers might eventually decide to support component matching. After all, there are several very basic features of LDAP that some large LDAP suppliers dont yet support, even though they have been standardised for over 10 years. As several well known people have already said, LDAP has not done a good job at supporting PKI. So why believe things will miraculously change overnight with component matching. Be realistic, it wont. Unless of course Stefan Santesson can now stand up for his supplier and tell us when they will support component matching. That would indeed be very encouraging to us all.
thanks
David
Steve Hanna wrote:
David Chadwick wrote: > what ever happened to the concept of let a thousand flowers bloom?
Standards work is not about "let a thousand flowers bloom". It's about agreeing on standards that will help systems interoperate and work well together. From my analysis, your proposals do not provide substantial benefit and they do add substantial complexity. I don't think that the Internet community will be well served by publishing these documents. They will only increase confusion for implementors and add complexity for directory clients, which will now need to support several directory schemas.
In a separate email, David wrote:
At no time to my knowledge was it suggested that this work be removed
from the PKIX set of IDs, otherwise why would they have continued to be
published with PKIX IDs instead of individual IDs for more than a year
after the meeting. And why would I have continued to report on their
progress at PKIX meetings?
At IETF 56, there was a discussion about whether to move to your proposed schemas (at that time, an independent submission) or stick with the current schema and use component matching to solve the problem. I raised concerns about your proposal at that meeting. As noted in the meeting minutes, a straw poll favored component matching but it was agreed to take this discussion to the mailing list. I never saw any discussion on the mailing list.
At IETF 57, it was explained that the question had been decided in favor of your schema (with no discussion on the email list). I sent an email to the PKIX list complaining about this and reiterating my concerns about your proposal. Sharon Boeyen sent email supporting my concerns. Nobody sent email favoring the proposals.
Now these documents are in Working Group Last Call. I have seen several emails from experienced PKI and directory folks raising concerns about your proposal and little email supporting it. I think it's clear there's no WG consensus in favor of your proposals. I suspect there never was a consensus in favor of them becoming WG drafts. If anything, the consensus seems to be that these documents are not representative of the IETF's future direction and should only be published with an Experimental status and some sort of warning.
I'm sorry for any confusion caused by the status of your documents as WG drafts. It seems clear to me that they should never have received such a status since there was never rough consensus in the PKIX WG about taking them on as work items. However, it is better to remove this confusion now by publishing them as Experimental with a warning than to expand the confusion by publishing them as Informational without a warning.
Thanks,
Steve