Subject: WG Last Call: Certificate Schema

From: Tim Polk <[email-masked]>
Date: Mon, 15 Nov 2004 17:00:22 -0500

This message initiates working group Last Call for the "LDAP Schema for 
X.509 Certificates"
specification. The editors have confirmed that all working group issues 
have been resolved.

The URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt

This specification has also been forwarded to the LDAP Directorate for a 
parallel review.  Assuming successful Last Call and concurrence from the 
LDAP Directorate, this document will be forwarded to the ADs for 
consideration as an Informational track RFC.

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before November 29.

Thanks,

Tim Polk

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 30 Nov 2004 15:43:54 -0000

David,

It seems that we all agree that these documents don't represent the
desired future direction.

If this is the easy fix solution to overcome temporary shortcomings of
current implementation of existing standards, then we shouldn't make
this into a standard, or anything that looks like a standard or guidance
on future direction.

I lack the discussion and insight on the potential harm that may follow
from diversity in applications where some decide to go the component
matching way or do some other tweak to make use of current schema, while
other implementations chooses the attribute extraction path and creation
of separate entries for certificates.

I fear a great mess out of this diversity and it probably won't help us
get to the target we all seems to agree on.

I regret not speaking up on this before, but a document can be
challenged until it has left the WG, and the fact that a document has
been processed as a WG document is not by itself a guarantee that it
will be published as one.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of David Chadwick
> Sent: den 30 november 2004 14:29
> To: Steve Hanna
> Cc: Tim Polk; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: WG Last Call: Certificate Schema
> 
> 
> 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
> >
> >
> >
> 
> --
> 
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: +44 161 295 5351  Fax +44 1484 532930
> Mobile: +44 77 96 44 7184
> Email: [email-masked]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Web site: http://sec.isi.salford.ac.uk
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************