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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Nov 2004 05:26:56 -0800

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

---

From: David Chadwick <[email-masked]>
Date: Mon, 29 Nov 2004 18:51:29 +0000

Kurt

at the meeting that we all attended, you will recall that these 3 IDs 
were originally standard's track, and that the authors agreed to 
downgrade them to Informational to allow the component matching approach 
to become the only official standards track approach. We did this 
because we knew that it would take a long time for LDAP suppliers to 
implement the latter approach, and we did not want to prejudice this in 
the short time by standardising these 3 IDs, which we know are easier 
for most suppliers to support (ie. they need do nothing except put an 
XPS server in front of their existing LDAP server).

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? Thus I believe your recollection of this is 
wrong. The IDs are and always have been a product of the IETF and the 
PKIX group in particular. The authors wanted it this way to make sure 
that the approach was widely supported (which I believe it is. We 
already know of 4 implementations which Peter has already informed you 
about). Thus I believe that the WG has reached concensus on these IDs.

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 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.

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. 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.

-- 

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

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: David Chadwick <[email-masked]>
Date: Mon, 29 Nov 2004 18:54:56 +0000

P.s. If you are really so concerned with supporting X.509 attributes in 
LDAP, why dont you work on solving a real requirement, such as the 
ability to simply add an attribute certificate to an entry. Even this 
simple feature currently is not possible in LDAP when the entry already 
contains an AC.

regards

David

--

---

From: Peter Gietz <[email-masked]>
Date: Tue, 30 Nov 2004 11:23:55 +0100

>progressed as products of the PKIX WG.
I don't know about such a consensus. David's two drafts had been 
published as WG drafts since quite a while now and I haven't seen any 
protest on the list and at the meetings that I attended. I do know that 
some people on the list opposed our approach, but the longest critical 
threads where about LDAP itself as technology for publishing 
certificates, a discussion that was IMHO rather unfruitful.
[...]

>the certificate, but a certificate object.
As I mentioned before, we have been working on an additional objectclass 
to address the searches for DN parts, which we have already implemented 
to make such searches possible. The PKC draft already contains an 
attribute x509certHolder which contains a DN pointer to the person 
entry.  Our approach makes it possible to store certificate information 
and person information in two separate servers without loosing the 
relation between the two.

>it can and will be implemented.  
>

There is one application, which is not addressed by the standard track 
schema: Indexing. The IETF has published the Common Indexing Protocol as 
Standard Track (RFC 2651 - 2657). To provide CIP indexing objects for 
certificate information stored in LDAP you have to extract the cert 
values. I do see central indexes in the future, where people will search 
for the LDAP servers which have the certificate needed for e.g. 
encrypting an email.  The major motivation for our approach were such 
scenarios. And our approach has helped us setting up such.

>Not only are there two
I do now see that things have changed by now in comparision with the 
time, we started this work. I never opposed the standard track solution. 
In many ways it is much more flexible and not only applicable to 
certificate information. Nevertheless I still am convinced that our 
solution is far easier to implement and that an implementation is 
useful. The two methods component matching and value extraction are in 
some ways complimentary and they are interoperable in the sense that a 
server can provide both without any harm.

>the RFC Editor for consideration.
I had initially have published the pkc document as individual 
submission, I resubmitted it as WG draft after the partner documents had 
been WG dratfs for quite a while without protest. By having made the 
specs WG drafts some very valuable comments had been made which helped a 
lot to improve the documents. As there had been presentation about the 
drafts in so many pkix meetings I do consider them to be WG drafts now.

>separately provide the WG with my review notes.
I am very much looking forward to your comments. The drafts BTW have 
already been influenced by your comments quite a lot already.

I am taking up Steves last proposal to publish them as experimental RFC.

Cheers,

Peter

-- 
_______________________________________________________________________
 
Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114  
D-72074 Tübingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 30 Nov 2004 06:29:06 -0800

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.

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.