Subject: Re: draft-ietf-pkix-ldap-*-schema WG LC comments

From: David Chadwick <[email-masked]>
Date: Thu, 02 Dec 2004 17:04:15 +0000

Kurt D. Zeilenga wrote:
> David,
> 
> We obviously have different recollections of the prior
> conversations.  This may in part due to the fact that there
> were many different conversations involving different
> participants.  I recall reaching a general consensus (amongst
> the participants) that these I-D were to progressed to the RFC
> Editor on an Individual basis as either Informational or
> Experimental.

Kurt

We obviously have different recollections here. The IDs have always 
contained a status note saying they were from the PKIX working group 
along with a request to send email comments to the PKIX list. I am sure 
the PKIX chairs would not have countenanced this or WG time to present 
them, or the ID names they have had, if they were meant to be individual 
submissions. On the contrary, by making them WG drafts, we were meant to 
tease out all the issues that you are raising now during the last call. 
So really it would have been more beneficial to everyone if you had said 
something earlier. And given that you were acting as a consultant on the 
project that actually implemented the extraction IDs, you cannot 
actually plead ignorance of them. Could it be that because you have only 
just recently implemented component matching in OpenLDAP that you are 
now happy for the attribute extraction IDs to be forgotten, but prior to 
this, you were happy to have them?

Finally, once they are published as information RFCs, what is the 
difference between a WG or individual submission? Is there a note to say 
that it is or is not the product of a working group? Or is the only 
difference in the procedure used to get publication? And since we are at 
the end of one procedure there is little point in switching horses to 
another procedure now, unless of course you would like to slow down 
publication (which of course you do)

regards

David

> 
> Anyways, the reason why I noted my understandings of the prior
> conversations was to lead into my comments regarding IESG notes,
> as well as to serve as a basis for my recommendation that you
> withdraw the I-Ds from WG consideration and take these directly
> to the RFC Editor.  I recommend this approach because I do not
> believe consensus exists to progress as products of this WG,
> or of the IETF.
> 
> Please note that I don't dispute that the documents are
> presently WG documents and that this is a WG LC.  I personally
> don't put any weight in these facts towards the issue of
> whether the WG should or should not progress these documents.
> 
> At 10:51 AM 11/29/2004, David Chadwick wrote:
> 
>>Your objections really do sound like those of someone who is frightened that the component matching approach will not be adopted and that the the current approach will kill it off.
> 
> 
> I believe that component matching will become widely implemented,
> regardless of the proposed extraction approach is published or not.
> However publishing these documents without appropriate caution (which
> I believe they currently do not) they offer an alternative approach
> to standard track approaches, and that these standard track approaches
> should be favored, may not only cause confusion in the community,
> but may lead to interoperability problems.
> 
> 
>>I hope this is not the case, because I would like to see component matching approach ubiquitously supported. However, many people need LDAP search support today for PKIs, and the current approach provides the simplest and quickest fix for this, though as we all agree, not the most elegant.
> 
> 
> The problem with value extraction is that the fix brings far more problems
> than it purports to resolve.  You have completely glossed over the complexity
> this approach pushes onto clients.   Dealing with multiple entries is simply
> not as simple as dealing with one entry.
> 
> 
>>regards
>>
>>David
>>
>>p.s your technical argument below is flawed. People are not the only entities that possess certificates, and so the object class person is not necessary nor required for the search.
> 
> 
> I fully realize that persons are not the only entity that might
> possess a certificate.  My point is that the object representing
> the entity is not returned by the certificate search.
> 
> 
>>The user is only interested in obtaining the certificate containing the subject name with a particular RDN, and the current approach supports this kind of search.
> 
> 
> There are a wide range of applications which need to acquir
> non-certificate information about the user based upon information
> they know about the user's certificate.
> 
> 
> 
>>Kurt D. Zeilenga wrote:
>>
>>>It was my understanding after previous discussions (involving
>>>the authors, chairs, ADs, myself, and others) that these I-Ds
>>>would be individually submitted to the RFC Editor for
>>>consideration.  I am a bit surprised that they are now being
>>>last called in PKIX WG as I was under the impression that the
>>>WG has already reached consensus that these I-Ds would not be
>>>progressed as products of the PKIX WG.
>>>If these had been submitted directly to the RFC Editor, I
>>>would have recommended to the IESG that an "IESG note" be
>>>added to each I-D that clearly stated the I-D was not a
>>>product of the IETF, provided an alternative to a standard
>>>track approach, and that the standard track approach
>>>should be favored by implementors and deployers.
>>>However, as these I-Ds have been submitted to the PKIX WG
>>>for consideration, the PXIX WG must reach consensus that the
>>>I-Ds are technical sound and appropriate for publication as
>>>a products of this WG.  I seriously doubt this WG will now
>>>reach consensus that these I-Ds should be published as
>>>products of the PKIX WG.
>>>I do not believe the value extraction approach to be sound as
>>>it doesn't actually address the key problem: matching against
>>>arbitrary component values of a certificate (or other complex
>>>structures).  For instance, say the application wanted to match
>>>all person objects containing a certificate whose subject DN
>>>contained an RDN containing an AVA with a common name of X.  This
>>>schema simply doesn't support that kind of matching because only
>>>select values of the certificate, some of which are themselves
>>>complex structures, have been extracted AND, even if they had
>>>been, the operation would not find the person object holding
>>>the certificate, but a certificate object.
>>>I believe the existing standard track approach more than
>>>adequately addresses application needs in this area, and that
>>>it can and will be implemented.  Not only are there two
>>>existing implementations today, one is open source (and available
>>>for reuse under non-restrictive terms).  While I cannot speak for
>>>the plans of other vendors, I can say that I have been contacted
>>>by a number of vendors who made it clear to me that they intend
>>>to put implementation of the standard track approach into their
>>>product plans.
>>>Hence, I oppose progression of the I-Ds as products of the PKIX
>>>WG (regardless of track).  I encourage the authors to withdraw
>>>the I-Ds from IETF consideration and to submit them directly to
>>>the RFC Editor for consideration.
>>>I note that I found a number of other issues in the I-Ds.  I will
>>>separately provide the WG with my review notes.
>>>Regards, Kurt
>>
>>-- 
>>
>>*****************************************************************
>>
>>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
>>
>>*****************************************************************
> 
> 
> 
> 

-- 

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

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

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Dec 2004 03:39:09 -0800

At 09:04 AM 12/2/2004, David Chadwick wrote:
>Finally, once they are published as information RFCs, what is the difference between a WG or individual submission?  Is there a note to say that it is or is not the product of a working group?

It is general practice for the IESG to add a note to individual
submissions to the RFC Editor of this basic form:
   This RFC itself is not a candidate for any level of Internet
   Standard.  The IETF disclaims any knowledge of the fitness of this
   RFC for any purpose, and in particular notes that it has not had
   complete IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.

Additionally, where an individual submission proposes an alternative to
a standard track approach, the IESG commonly adds additional notes
regarding the applicability of the approaches.

>And since we are at the end of one procedure

These I-Ds are no where near the end of the IETF procedure.

>there is little point in switching horses to another procedure now,
>unless of course you would like to slow down publication (which of course you do)

If I truly wanted to delay publication (which I don't), I would
not have suggested the alternative procedure.  Keeping it in the
WG will be dead slow.

Switching to Individual Submission to RFC Editor procedure would
likely significantly speed up publication.   The IETF process
is much slower, especially in cases where there is significant
contention.

However, I do not recommend Individual Submission because it will
be faster, I recommend it because it is more appropriate given the
significant contention over technical issues.

Regards, Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Dec 2004 03:12:09 -0800

At 09:04 AM 12/2/2004, David Chadwick wrote:
>We obviously have different recollections here.  The IDs have always contained a status note saying they were from the PKIX working group along with a request to send email comments to the PKIX list.  I am sure the PKIX chairs would not have countenanced this 
>or WG time to present them, or the ID names they have had, if they were meant to be individual submissions.

I am sure you meant them to be WG I-Ds.  I am sure that at present
they, in terms of process, are regarded as WG I-D.  You'll note that
I framed my recommendations and comments with this in mind.

However, I doubt that the WG has paid them much mind.  But regardless,
what matters at this time is whether or not the WG believes at present
the document is technical sound and otherwise appropriate to publish.

>On the contrary, by making them WG drafts, we were meant to tease out all the issues that you are raising now during the last call.  So really it would have been more beneficial to everyone if you had said something earlier.

I think I have made evident over the years my general concerns regarding
this approach, and my position that it should not be ordained by the IETF.
Because of the nature of the concerns, no amount of teasing that will
resolve them.

I note that I do have some vague recollection of noting some process concerns
to the chairs in regards to these I-Ds, but I also recollect not wanting to
turn things into a process debate.

>And given that you were acting as a consultant on the project that actually implemented the extraction IDs, you cannot actually plead ignorance of them.

I don't believe I plead ignorance.  I can be regarded as being a consultant
to many projects, even projects which I do not believe are taking the right
approach.  I think I've been vocal regarding my concerns with the value
extraction approach, in the IETF, in the OpenLDAP Project, and in other
projects (such as your TERENA-funded project).

>Could it be that because you have only just recently implemented component matching in OpenLDAP that you are now happy for the attribute extraction IDs to be forgotten, but prior to this, you were happy to have them?

My concerns with the value extraction approach are long standing and
well known.

I will comment to remainder in a separate note.

Kurt