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

[Timothy Hahn <hahnt@xxxxxxxxxx>]

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

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@xxxxxxxxxxxx> Sent by: owner-ietf-pkix@xxxxxxxxxxxx 01/10/2003 02:31 PM

To:        Timothy Hahn/Durham/IBM@IBMUS         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
>
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature