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

From: Russ Housley <[email-masked]>
Date: Mon, 06 Jan 2003 16:28:47 -0500

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

---

From: Timothy Hahn <[email-masked]>
Date: Tue, 7 Jan 2003 08:40:13 -0500

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

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

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

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Jan 2003 14:31:12 -0500

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

---

From: Timothy Hahn <[email-masked]>
Date: Mon, 13 Jan 2003 07:59:59 -0500

Russ,

I agree with you in not wanting two standards for accomplishing the same 
goal.

But I still assert that the (currently) two proposed models do not have 
exactly the same goals, hence a possibility that the different goals 
require different solutions.

Option 1: single entry, containing possibly multiple userCertificate 
attribute values
Goals: (primary) support existing deployments which assume this model, 
(secondary) support attribute-within-certificate searching, (secondary) 
support single userCertificate retrieval.

Option 2: multiple entry, containing single userCertificate attribute 
value per entry, entries related by sub-tree layout
Goals: (primary) support attribute-within-certificate searching with 
existing and widely available directory technologies, (primary) support 
single userCertificate retrieval, (non-goal) support existing deployments 
which assume a single entry model.

I accept the desire to not have this situation, but I also believe it is 
going to occur - so why wouldn't we try and infuse at least some order 
into this situation?

Regards,
Tim Hahn

Russ Housley <[email-masked]>
Sent by: [email-masked]
01/10/2003 02:31 PM
 
        To:     Timothy Hahn/Durham/IBM@IBMUS
        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

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Jan 2003 15:37:34 -0500

Tim:

I do not agree.  These are two cases associated with the same goal.  The 
client wants to locate the appropriate certificate.  The subject may have 
one, two, or more certificates, but the client does not know this until it 
starts looking.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 14 Jan 2003 15:22:44 -0800

All,

Apologies for being a bit late on this.  Compliance statements
per Tim's direction attached.

Mike