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:housley@xxxxxxxxxxxx]
Sent: Friday, January 10, 2003 2:31 PM
To: Timothy Hahn
Cc: ietf-pkix@xxxxxxx
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
>
>Internet: hahnt@xxxxxxxxxx
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: 919.224.1565 tie-line: 8/687.1565
>fax: 919.224.2540
>
>|+-----------------------+------------------------------------------------|
>|| Russ Housley | |
>|| <housley@xxxxxxxxxxx| To: Timothy |
>|| m> | Hahn/Durham/IBM@IBMUS |
>|| | cc: ietf-pkix@xxxxxxx |
>|| 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,
> >
> >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
>
>