Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 3 Jan 2003 11:28:52 +1100

Actually, it may not matter whether it is widely implemented. Because we wish to use component matching in matched-values, it will probably require any servers implementing matched-values to be rewritten to allow component-match in matched-values.

-----Original Message-----
From: Ramsay, Ron 
Sent: Friday, 3 January 2003 10:33
To: Kurt D. Zeilenga
Cc: Peter Gietz; [email-masked]
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

I know, but is it widely implemented?

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Friday, 3 January 2003 04:01
To: Ramsay, Ron
Cc: Peter Gietz; [email-masked]
Subject: RE: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

At 11:11 PM 1/1/2003, Ramsay, Ron wrote:
>Component matching, however, does not address the problem of returning multiple certificates.

We have a general solution to that general problem in the LDAP
matched values control extension [draft-ietf-ldapext-matchedval]. 

Kurt

>Ron.
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:[email-masked]]
>Sent: Tuesday, 31 December 2002 18:38
>To: Peter Gietz
>Cc: [email-masked]
>Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)
>
>
>
>
>>Nevertheless two different solutions to one problem might be preferable here.
>
>My primary objection to standardizing the child entry approach
>for PKI is that it is a PKI-specific solution to a general problem,
>component matching of complex attribute values.   We should be
>looking for general solutions to our general problems.  Steven's
>component matching I-D details a general solution which I believe
>is suitable for standardization.
>
>My recommendation is that the PKI "child entry" approach be
>pursued individually as an Experimental (or possibly Informational)
>solution to the PKI component matching problem with a note that
>a more general solution, component matching, is being standardized.
>
>Kurt

---

From: Timothy Hahn <[email-masked]>
Date: Mon, 6 Jan 2003 15:14:45 -0500

Hello all,

After listening to the different view-points on this topic, it seems to me
that there are multiple valid approaches.  These approaches include, but
are not limited to:
  - leveraging the general solution of component-matching
  - new schema to support application-managed componentization of
information to make things searchable
as well as others (additional matching rules, for example).

It occurs to me that perhaps we have a situation where "one size does not
fit all".  Why not accept this and define a way for applications to
determine which (of possibly multiple) format(s) has been used to place the
information into the directory?  We could define some small bit of schema
which indicates the way in which the certificate information is placed into
the directory, then different applications could query this and determine:
  - whether they can use the data at all
  - if they can use the data, how they can best use it (if there are, for
example, multiple mechanisms employed).

Just a thought to get us through this discussion.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Durham/IBM@IBMUS
phone: 919.224.1565     tie-line: 8/687.1565
fax: 919.224.2540

---

From: [email-masked]
Date: Mon, 13 Jan 2003 10:10:33 +0000

> The "let the market decide" has
> lead to camps that implement the alternatives, but do not interoperate with
> each other, even if they know why they do not interoperate.  I do not want
> to repeat this mistake.

Amen.

Any chance of coming up with a procedure that de-engineers these
standards ? We are failing in the 'Review' stage of the project
life-cycle :-)

Chris

---

From: Sharon Boeyen <[email-masked]>
Date: Tue, 14 Jan 2003 11:01:38 -0500

Russ I want to add my support to your comment about interoperability. In
particular
I think we need to be careful about anything that would require
changes/additions to 
clients. Existing deployed PKIX clients will be around for quite some time
and need 
to be accomodated in anticipated environments. The only way to do that with
this proposal 
would be to require that all servers follow the traditional userCertificate
schema and 
some could, in addition to that, add these child entries for enhanced
clients. Even that 
approach would require some way for the enhanced client to know which
servers support the 
enhancements. otherwise they'd be sending a lot of requests that wouldn't
succeed and they'd 
need to re-request the old way. Its also not fine for the PKI application to
say that clients 
and servers will figure out which ones they are compatible with and work
with those alone.  
That model is limited to closed environments and creates isolated islands of
interoperability. 
PKIX requires a mechanism that enables clients to be able to access the data
they need to build
and validate cert paths and separating servers into some that follow a
compatible schema and others 
that don't would significantly hinder that ability. 

A few years ago I remember participating in discussions about the
crossCertificatePairs attribute and 
how complex that one is. It would be wonderful to replace that single
overloaded attribute with at least
two separate attributes (one for certs issued "to" this CA and a separate
one for certs issued "by" this 
CA). While many of those in that discussion, myself included, agreed that
this would be a great thing to 
do we decided NOT to try to make that change for exactly this same reason.
Existing clients need to be 
accomodated and making such a change can only be done gracefully by
requiring that all CAs publish the old
way and some may also publish the new way. It then becomes very difficult to
determine a point in time 
at which you can turn off the old schema and rely solely on the new one. 

Sharon

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Friday, January 10, 2003 2:31 PM
To: Timothy Hahn
Cc: [email-masked]
Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

Tim:

In the PKIX WG, we have learned a hard lesson about letting two standard 
that accomplish the same goal progress.  The "let the market decide" has 
lead to camps that implement the alternatives, but do not interoperate with 
each other, even if they know why they do not interoperate.  I do not want 
to repeat this mistake.

Russ

At 08:40 AM 1/7/2003 -0500, Timothy Hahn wrote:

>Russ,
>
>Great question.  Simply - it gives the "client" the opportunity to
>establish whether or not it can or cannot support retrieval of the
>information from that data source (directory sub-tree).  Client and server
>implementations choose which protocols and data models they're going to
>"support" all the time.  As long as both support the same model(s), then
>they interoperate.  My proposal is that we define one way to identify which
>data model(s) is(are) employed, so that servers and clients can determine
>whether they are capable of supporting the formats.  If they are not
>capable, they can gracefully fail.
>
>The client can be made as "fat" or as "lean" as the implementer wants,
>because the implementer can decide which formats to support.  If the
>implementer decides to support one while another part of the industry tends
>to support another - well, then that particular implementation will get
>"fatter" because it will wind up supporting both.
>
>My premise is that there is not a single data model that "fits" for ALL
>applications/deployments.  And because of that, multiple data models can
>and will (in real-world scenarios) exist.  So why not accept this, define a
>(singular) way of identifying which model is used, and move on.  At least
>in this way, if a particular implementation/application has a need to store
>things in a different way, it can, and we can still hope for
>interoperability through IETF documents.
>
>Regards,
>Tim Hahn
>
>|+-----------------------+------------------------------------------------|
>||   Russ Housley        |                                                |
>||   <[email-masked]|           To:        Timothy                   |
>||   m>                  |   Hahn/Durham/IBM@IBMUS                        |
>||                       |           cc:        [email-masked]         |
>||   01/06/2003 04:28 PM |           Subject:        Re: LDAP PKI Schema  |
>||                       |   (was Re: No-op LDAP ;binary option)          |
>||                       |                                                |
>||                       |                                                |
>|+-----------------------+------------------------------------------------|
>
>
>
>
>
>Tim:
>
>I do not understand how a client is better off with multiple ways to put
>the same information in the Directory.  Doesn't this approach just make the
>client fat?  It seem to me that the client would have to support all of the
>possible ways that the information could be stored.  It cannot know which
>method it will encounter until it starts looking at data in the Directory.
>
>Russ
>
>
>At 03:14 PM 1/6/2003 -0500, Timothy Hahn wrote:
> >Hello all,
> >

---

From: [email-masked]
Date: Thu, 16 Jan 2003 11:36:24 +0000

> otherwise they'd be sending a lot of requests that
> wouldn't succeed

Unfortunately this is already the way of the world

> That model is limited to closed environments and
> creates isolated islands of interoperability.

Again, this is already the case.

> PKIX requires a mechanism that enables clients to
> be able to access the data they need to build
> and validate cert paths and separating servers into
> some that follow a compatible schema and others

I don't disagree but as you have implied this would
require a very heavy client that can cope with all
currently deployed strategies. I doubt that any vendor
would commit to creating a product that supported
someone else's technical strategy. I would much rather
see the killing off of one of the strategies and a
focus on and a commitment by everyone to the other.
I accept that this is not trivial but I do not believe
that genuine interoperability is achievable until we
bite the  bullet and simplify the mechanisms that
support proof of trust.

> It then becomes very difficult to determine a point
> in time at which you can turn off the old schema and
> rely solely on the new one.

Agreed. But just because something is difficult does
that mean that we shouldn't do it ?

Chris