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: Andrew Sciberras <[email-masked]>
Date: Tue, 16 Nov 2004 12:49:30 +1100

Hi,

Do you have any concerns about the fact that the Serial Number
attribute (section 5.1.2) does not contain an ordering matching rule?

Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?

Section 5.2.3  Key usage Extension
If you have a certificate with a keyUsage extension present with a
value of zero (i.e. none of the bits are set) what do you do? Do you
simply omit using the x509keyUsage atribute? If not, how does the BNF
represent such a value?

Thanks,
Andrew Sciberras

---

From: Andrew Sciberras <[email-masked]>
Date: Tue, 16 Nov 2004 12:49:30 +1100

Hi,

Thanks,
Andrew Sciberras

---

From: Peter Gietz <[email-masked]>
Date: Thu, 18 Nov 2004 10:14:02 +0100

Hi Andrew,

Thanks for your comments:

>Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?
Yes that was intentional, since the attribute is used as multivalue in 
the CRL document. I quote David Chadwick:

"serial number became multivalued because CRLs contain lists of revoked 
serial numbers. So in order to use the same attribute in PKC and CRL 
entries, we made it multivalued. Which is not actually a problem for a 
PKC entry in reality, cos a PKC can never hold more than one value. If 
it was made single valued then we would need to define a new attribute 
to hold exactly the same information in a CRL."

>simply omit using the x509keyUsage atribute? If not, how does the BNF
I will include Norbert's proposed text into the draft to get this one 
straight.

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: Steve Hanna <[email-masked]>
Date: Thu, 18 Nov 2004 14:26:02 -0500

Here are my comments on draft-ietf-pkix-ldap-*schema.

These schemas are too complex and incompatible with
existing clients. The costs exceed the benefits.

The main supposed benefits of your solution are:

1) Easier to search for certs

    Since certificate fields are stored as attributes
    of LDAP entries, clients can easily search for
    certificates by certificate field values. However,
    there are already two good ways to do this: the
    CertificateAssertion (defined in X.509 and
    draft-zeilenga-ldap-x509-00.txt) and Component
    Matching (RFC 3687). You argue that these will
    take a while to be deployed, but so would your
    solution. We don't need a third option.

2) Easier to download just matching certs

    Some users (or CAs) have many certificates.
    Your solution stores each cert as a separate
    directory entry which makes it easy to download
    just the ones you want. But there is already a
    way to do this with the existing schema: the
    Matched Values Return Filter control (RFC 3876).
    Again you argue that these will take a while to
    be deployed, but so would your solution. Also,
    it's quite rare to have many certificates. Why
    optimize for this rare case?

The main costs of your solution are:

1) Many more directory entries (>2x)

    Your solution requires a separate directory entry
    for every certificate. If each user has an average
    of one cert, this will double the number of entries
    in the directory. That's bad enough, but your solution
    has no value unless each user has many certificates.
    In that case, the number of entries will more than
    double.

2) Client changes needed

    You complain that the Matched Values Return Filter
    control will require servers to be upgraded. But
    your solution will require all clients to be upgraded
    to look for certificates and CRLs in a new place.
    Upgrading all clients is much harder than upgrading
    a few servers.

The schema described in RFC 2587 and updated by
draft-zeilenga-ldap-x509-00.txt seems much more
reasonable than yours. I understand that the
zeilenga I-D is actually a product of the ldapbis
efforts and will probably advance with them.
Therefore, I suggest that document be advanced in
lieu of yours.

I have heard that your drafts are only intended to
report on some experiments you conducted. That's why
the documents are going Informational and not Standards
Track. If that's true, the documents should say so
clearly and they should go Experimental not Informational.

In conclusion, it's my view that these documents are
not useful. In fact, they may cause harm to people
who implement them without understanding that they
are purely experimental. I recommend that they not
be published at all by the IETF. If they are published,
they should only be published with Experimental status
with an Applicability Notice describing the problems
noted above and suggesting that the standard schemas
be used instead.

Thanks,

Steve

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 2004 13:54:15 -0800

Just to clarify a few non-technical points.  (I intend
to offer my technical comments after I complete my
review of the I-Ds).

At 11:26 AM 11/18/2004, Steve Hanna wrote:
>draft-zeilenga-ldap-x509-00.txt [...]. I understand that the

draft-zeilenga-ldap-x509-00.txt is presently an individual
submission to the IETF.  Hence, it is not a product of
the LDAPBIS WG.

It is my hope that after appropriate review by the PKIX WG,
the LDAPBIS WG, and other parties, to submit this document
to the IESG for Standard Track consideration.  Precisely
how it will be forwarded (by me as Individual, by Bob as
LDAPBIS WG co-chair, or by an PXIX co-chair) to the IESG
is yet to be determined, but certainly will be coordinated
with the chairs of both PKIX and LDAPBIS WGs.

It is my hope that this I-D will be published in conjunction
with the revised LDAP TS being prepared by the LDAPBIS WG.

Kurt

---

From: Steven Legg <[email-masked]>
Date: Fri, 19 Nov 2004 10:00:02 +1100

And likewise for draft-legg-ldap-binary-xx.txt, upon which
draft-zeilenga-ldap-x509-00.txt depends.

---

From: Andrew Sciberras <[email-masked]>
Date: Fri, 19 Nov 2004 14:38:49 +1100

Hi

> the CRL document. I quote David Chadwick:
 
Not a problem. :) 
I do have a some comments about this, but I'll do it in a subsequent email. 

> I will include Norbert's proposed text into the draft to get this one

Excellent. 

> Peter

Cheers,
Andrew.

---

From: Andrew Sciberras <[email-masked]>
Date: Fri, 19 Nov 2004 14:47:45 +1100

Hi,

I'm looking at the x509userCertificate Object Class...

( 1.3.6.1.4.1.10126.1.5.4.2.4
         NAME 'x509userCertificate'
         SUP x509PKC
         STRUCTURAL
         MUST userCertificate
         MAY  x509subject )

This definition is followed with the statement:
"   The attribute type x509subject is specified here as a MAY attribute.
   Nevertheless if this attribute is not used at least one of the
   following attributes MUST be filled in: x509subjectRfc822Name,
   x509subjectDnsName, x509subjectDirectoryName, x509subjectURI,
   x509subjectIpAddress, or x509subjectRegisteredID."

This is either problematic or not specified clearly enough. 
In order for one of these attributes to be present in the entry then
they should be an optional attribute within the x509userCertificate
object class.
If there is a reason why they shouldn't be in the optional list, then
I think text that makes reference to the use of  DIT Content Rules to
permit this.

Regards,
Andrew Sciberras
eB2Bcom Pty Ltd

---

From: Peter Gietz <[email-masked]>
Date: Fri, 19 Nov 2004 13:33:04 +0100

Steve,

Thanks for your comments although our opinions differ. Here is my reply:

> existing clients. The costs exceed the benefits.

I don't think so and will try to explain why.

>    solution. We don't need a third option.
The advantage of our solution is that you don't have to change any 
software, provided clients support configurable search filters,
and that should be standard anyway and most generic ldap clients support 
that.  Implementation of Component Matching will be much more burdensom 
since ASN.1 parsing is far more complicated and AFAICS only one server 
product is ASN.1 aware today. With all other products a redesign would 
have to be done to support Component Matching.

May be some vendors could make a statement about their plans for 
supporting Component Matching to get a better view on this.

>    optimize for this rare case?

We expect this case to be less rare in the future. Especially we expect 
that users will have different certificates for encryption and for 
signing. It also will be more common that users will have certificates 
from different CAs.

>    In that case, the number of entries will more than

I agree, but don't see that this is a big problem even for large 
databases. All LDAP-servers are capable of storing great amounts of entries.

>    Upgrading all clients is much harder than upgrading

Since we decided to use the standard attributes usercertificate and 
cacertificate within our schema, the certificates should be retrievable 
by standard clients that perform subtree searches. We are thinking about 
publishing another object class for additional metadata not extracted 
from the certificate but, e.g.,  extracted from a peron entry or from 
the single parts of the subjectDN (email, cn, o, ou, etc.) which are 
used as search items by clients not aware of our  x509xxx attributes.

> Therefore, I suggest that document be advanced in

As you can see in our draft, we never said that our schema is the only 
valid solution. We only say that with today's software our solution is 
better deployable and that they are an ideal solution for indexing systems.

> clearly and they should go Experimental not Informational.

I agree with the ADs that there should only be one standard solution. If 
in the future we will see that our solution is  implemented  far more 
often than others, I will make an attempt to reissue our proposal for 
Standards Track. For now I would be very happy with Informational 
status. I know of at least 4 implementations of our draft. Thus it is 
more than just an experiment of one project. Since you don't want to 
have our drafts published at all, I cannot see your point here. If 
Experimental Track leads to more consensus, then it is ok with me, but 
still I think Informational is more appropriate. Nothing in the 
definition of Informational in RFC2026 Par 4.2.2. seems to be against that:

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

> noted above and suggesting that the standard schemas
We already wrote that there is a standard way for storing LDAP 
certificates in place that might in the furure also solve most of the 
problems addressed by us. Current implementations do not solve them with 
that standard. In addition our schema provides the only solution for 
large scale certificate index systems.

An Applicability Notice saying "This spec is bad and crap, don't 
implement it" seems to be nonsens to me, since if it is only bad and 
crap it shouldn't be published at all. I for one, but AFAICS besides you 
all other commentors in this last call  don't think that it is crap.

There might be a formulation of an Applicability Notice that makes more 
sense.

Cheers,

Peter

> Thanks,
>
> Steve
>
> Tim Polk wrote:
>
>>
>>
>> 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.
>>
>> 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
>
>
>
>

Peter Gietz (CEO)

---

From: Peter Gietz <[email-masked]>
Date: Fri, 19 Nov 2004 13:49:22 +0100

>I'm looking at the x509userCertificate Object Class...
We had made the design decision to have a separate object class for the 
certificate extensions which is defined in the same document. I am 
willing to include a reference to that object class  here , e.g. :
"... or x509subjectRegisteredID. These attributes are provided by the 
auxiliary object class x509PKCext specified in 4.5. which in this case 
is mandatory."

We could additionally specify a DIT content rule for this, if it makes 
things clearer. But I don't see a way to specify the condition "if 
x509subject is empty then" in such a rule.

Cheers,

Peter

 
Peter Gietz (CEO)

---

From: Steve Hanna <[email-masked]>
Date: Fri, 19 Nov 2004 12:02:53 -0500

Peter,

First, I should apologize if I came across
as saying that your drafts are crap. That's
not what I wanted to say. They're interesting
ideas and research but I don't see that the
benefits exceed the costs.

Second, thanks for your responses. Thanks
especially for responding in a constructive
and helpful manner to my criticisms. That's
very helpful. I'll respond below.

> supporting Component Matching to get a better view on this.

I agree that Component Matching is complex. What about
the CertificateAssertion? That seems fairly simple.

And I'm not sure that the problem is a critical one
to solve, as described in the next bullet. I expect
that most clients won't use any of these techniques
but will simply download all the certificates in a
directory entry and sort them out on the client.
See below for more on this theme.

> signing. It also will be more common that users will have certificates 

Yes, some users have two certificates, one for encryption
and one for signing. But it's much simpler to download
the two certificates and then decide which one you want
than to go through all this complexity to identify the
single certificate you want. Users with certificates from
a large number of different CAs stored in their directory
entry will probably be unusual. People who are storing
certificates in an LDAP directory are part of some organization
that runs the directory. That organization probably only
issues one set of certs per user. Don't you agree?

When I wrote a path builder, I tended to download all the
certs in a directory entry and sort them out in the builder.
The request latency far exceeded the extra cost of downloading
a few extra bytes. I recognize that this may not be the best
approach if you're on a very slow link or have little memory
but such a client won't have much success building paths anyway.
They're much better off using DPD (SCVP/XKMS) or getting full
paths in the TLS or other protocol handshake.

So I still don't think this is an important problem to solve.

> databases. All LDAP-servers are capable of storing great amounts of 

Maybe. I don't think administrators will be pleased with
doubling the number of entries.

> used as search items by clients not aware of our  x509xxx attributes.

As you point out in your draft, storing certs using
both the standard schema and your own is error-prone
and inefficient (storing every cert twice). This should
only be a transitional measure. Clients will need to
be upgraded to use your schema. But I'm glad you are
planning for a gradual upgrade process not a red letter day.

> more than just an experiment of one project. 

If the community believes this is a valid approach that
should be pursued further, then Informational seems
appropriate. If it believes that this approach should
not be pursued, then you are probably right that the
documents should not be published as RFCs. Experimental
status would be an intermediate position.

I should note that this is not the first time
I have objected to your proposal. I objected once
at an IETF meeting and (I believe) once before on
the PKIX list. I agree that if I'm the only person
objecting, then the documents should be approved.
But I want to make sure that my arguments are stated
so that others can consider them carefully and not
simply approve the documents without understanding
the tradeoffs involved.

If others share my concerns, I encourage them to speak
up. We all have a duty to try to make PKI work, for
the sake of our employers and customers. I think these
documents are a step in the wrong direction.

Of course, I concede that these documents are not
Standards Track at this time but I think that if we
publish them as RFCs without an Applicability Statement
or other guidance, people will perceive them as a
statement of future direction.

Thanks,

Steve

---

From: Andrew Sciberras <[email-masked]>
Date: Mon, 22 Nov 2004 08:28:47 +1100

Thanks Peter,

I think that the clarification is sufficient, as it would remove a
level of ambiguity within the text.

Cheers,
Andrew.

---

From: Andrew Sciberras <[email-masked]>
Date: Mon, 22 Nov 2004 09:27:18 +1100

Hi Peter,

I actually agree with Steve since we support Component Matching,
however I am a bit confused about your response...

On Fri, 19 Nov 2004 13:33:04 +0100, Peter Gietz <[email-masked]> wrote:
> that.  

What do you expect will be creating the entries and populating the
attributes defined within this schema? Client applications are going
to have to intelligently rip apart a certificate into its ASN.1
components and populate the Directory with information. This, as I see
it, would require changes to software. Unless of course the entry
modifications will be done as a manual process by a person every time
a certificate is stored within the directory.

> Implementation of Component Matching will be much more burdensom

Only 1 ASN.1 aware server... this doesn't quite sound right to me. 

> supporting Component Matching to get a better view on this.

Our server, the eB2Bcom View500 server, supports component matching. I
also think that OpenLDAP can or intends to support it, although Kurt
Z. could probably comment on this more accurately.

Cheers,
Andrew Sciberras.

---

From: Peter Gietz <[email-masked]>
Date: Mon, 22 Nov 2004 14:29:07 +0100

>a certificate is stored within the directory.
Ok I was only talking about the LDAP server-client  communication, not 
about data management. But there are several possibilities how to 
implement our schema.

- We have a perl-Script that analyses certificates and creates an LDIF 
file with the appropriate schema. This can and will be published as Open 
Source

- David Chadwick has developped an OpenLDAP proxy that does such a 
conversion totally transparent: add a usercertificate to server 1 and an 
entry with our schema will be automatically created on Server 2.

- I know of at least two other parties that have  developed similiar 
software  to create apropriate LDIFs.

- you can quite easily develop similiar software that, e.g. parses the 
output of OpenSSL

- if you have little data amounts, the manual creation is also an option.

>Only 1 ASN.1 aware server... this doesn't quite sound right to me. 
Well lets put it that way ASN.1 awareness would help a lot for 
implementing Component Matching.
My information about the development status of Component Matching might 

>Z. could probably comment on this more accurately.
I only know about a project that had tried to implement component 
matching in OpenLDAP, but that changed to our solution, before getting 
it done, because it was too difficult. May be Kurt knows more.

Cheers,

Peter

 
Peter Gietz (CEO)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 22 Nov 2004 08:35:25 -0800

At 05:29 AM 11/22/2004, Peter Gietz wrote:
>I only know about a project that had tried to implement component matching in OpenLDAP, but that changed to our solution, before getting it done, because it was too difficult.  May be Kurt knows more. 

Too difficult to be done by those who are not closely
working with server developers...  we had a research intern
(who previously had no LDAP/OpenLDAP experience), working
under the direction of a research engineer (who has solid
LDAP/OpenLDAP experience) and myself, implement GSER &
component matching support in OpenLDAP Software over the
summer.  We're presently finishing the indexing support for
component level searches.

As the implementation is open source, including the ASN.1
compiler, any vendor who chooses to support GSER and
component matching can leverage the existing running code.

Implementing component level matching in the server, I
would argue, is on the same level of complexity as
implementing a "general-purpose parsing server", as both
require ASN.1 awareness.  Implementing in an existing
DSA is a bit harder, just because of integration issues
Now, if your DSA is already ASN.1, such as many which
support DAP, then most of the hard work is already done.

Client libraries need no special code to handle component
matching.  The client just needs to pass in an RFC 2254
filter string which expresses the assertion.  And, if
return of matched values is desired, the client can use
the library support for generating and attaching the
necessary control.

And while client libraries don't need any special support
to handle the value extraction approach, clients must be
specifically designed for the value extraction approach.
Managing (for both read and write) multiple entries for a
user and her certificates is far more complex than managing
a single entry.  And, given that existing applications
expect there to be only a single entry, this approach may
lead to some breakage, especially given this:

>   If certificates are stored redundantly in person entries and in
>   certificate entries below the person entries, maintainers of
>   repositories MUST make sure that the same certificates are stored in
>   the person entry and the respective certificate entries and keep this
>   consistency.  Alternatively, they MUST leave out any certificates in
>   the person entry.

I would argue that if maintainers cannot ensure consistency,
they should not create the value extraction entries.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Thu, 25 Nov 2004 19:57:29 +0000

Dear Steve

what ever happened to the concept of let a thousand flowers bloom?
Or let the best man win? It seems to me that you would like to gag these 
  IDs because you fear that they will be more successful than component 
matching.

Lets face it, LDAP has not served PKIs at all well for the last decade. 
We still are not able to search for certificates, CRLs or ACs for 
goodness sake. And most LDAP suppliers dont really care, since this is 
not where their primary market share is. They have enough new 
requirements being requested from existing users to want to do anything 
for the small number of PKI users.

The 3 LDAP schemas that Peter and I have specified, and implemented in 
the XPS server, allow PKI users to sit an XPS server in front of their 
existing LDAP server (from whichever supplier, since none of them allow 
existing clients to search for the X.509 attributes) and to allow 
existing clients to search for them without needing a software change. 
The only thing that is needed is to configure the client with some new 
attribute types to search for. Now this must be good news for PKI users.

Since Peter has already adequately addressed your points in more detail, 
I wont respond to them individually, unless you would specifically like 
me to

regards

David

Steve Hanna wrote:
>> 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 

-- 

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

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: Thu, 25 Nov 2004 19:26:43 +0000

> attribute (section 5.1.2) does not contain an ordering matching rule?

Hi Andrew

yes good idea. It could be useful when searching for a CRL to see if any 
  certificates with serial numbers GE n have been published in a CRL.

Peter, can you add this to the certificate schema ID please.

> Is it intentional that the Serial Number attribute is not 'SINGLE-VALUE'?

See peter's response to this

regards

David

--

---

From: Peter Gietz <[email-masked]>
Date: Fri, 26 Nov 2004 10:58:09 +0100

David Chadwick wrote:

> yes good idea. It could be useful when searching for a CRL to see if 
> any  certificates with serial numbers GE n have been published in a CRL.
>

Yes I will.

Cheers,

Peter

>>> for a

Peter Gietz (CEO)

---

From: Steve Hanna <[email-masked]>
Date: Mon, 29 Nov 2004 15:12:26 -0500

> 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

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 30 Nov 2004 13:29:13 +0000

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

--

---

From: Steve Hanna <[email-masked]>
Date: Tue, 30 Nov 2004 09:50:40 -0500

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.

You say that "all clients can naturally support
[your schema] without any code change". This isn't
true. 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

---

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

David,

While there may have been some in this WG that viewed the
value extraction approach as a pragmatic solution to various
specific issues, I believe there are also many, like myself,
who have never considered the value extraction approach, in
general, to be practical.  And, as I noted in my previous
response, I do not consider the value extraction approach
as applied here to certificates and such to be pragmatic
as it simply does not address requirements I am faced with.

In particular, how does this approach providing for matching
upon components of the subject (or other) DNs in the certificate?

At 05:29 AM 11/30/2004, 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.

I assume s/component matching/value extraction/.

Secondly,, I am not so sure the ADs actually agreed with the
informational track publication of the value extraction I-Ds.
I note that one AD in particular voiced significant concerns
about publication of alternatives here.

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

Given that component matching was published as a Proposed Standard
in Feb. 2004, the fact that we now have two server implementations
is quite good.  We likely can seek progression to Draft Standard
status shortly.

As we understood long ago, it will take time for this to get on
the radar of LDAP server developers.  That seems to be happening
now.

>Attribute extraction on the other hand has double that amount of supporting implementations, plus all clients can naturally support it without any code change.

How does an existing client designed to work with person objects
become aware of, and make use of, subordinate certificate objects
without being changed?

>So whilst we might all like the ideal today, pragmatically we need to recognise that this is not the situation on the ground today.

Pragmatically, we have to realize that the so-called pragmatic
solution will introduce numerous problems which we could have
avoided if we would have stuck with the so-called elegant solution
we knew avoided these problems.

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

To the LDAP community, PKI is just another application of the
directory.  The LDAP community tends to focused on mechanisms
which support a wide range of applications (including PKI).
Component matching does this.

I am not sure the LDAP community as a whole sees the danger
in moving to a value extraction approach generally.  I shutter
at the thought of having components of every complex value
extracted into new values, and them in term extracted into more
values.  I would hope it would be obvious that value extraction
is not a wise approach, and will lead to numerous other problems.

>So why believe things will miraculously change overnight with component matching. Be realistic, it wont.

I don't believe I've ever said that we'd miraculously have wide
adoption of component matching overnight.  I expect it will be
years before we see that.

However, I fear that if we are not careful in how we publish
the value extraction approach, we will be living with the
problems of value extraction long after we have broad server
support for component matching.   By noting, using appropriately
strong language, the standard track approach is to be favored,
we might be able to minimize this.  Of course, we'd likely
suffer regardless.

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