Subject: RE: Returning single values from multivalued attributes

From: "Miklos, Sue A." <[email-masked]>
Date: Fri, 6 Aug 1999 13:11:31 -0400

David,

I see a real need for this capability, as well.  However, if a user only has
selected pieces of information with which to construct a match, a
matchedValuesOnly may not be sufficient.  I'm not sure I'm knowledgeable
enough to comment, but I'd be willing to try.

Sandi Miklos

-----Original Message-----
From: Chris Apple [mailto:[email-masked]]
Sent: Thursday, August 05, 1999 3:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Returning single values from multivalued attributes

I already have a need for such a feature. I was considering use of an
extensible matching rule to implement the same sort of thing.
Unfortunately, I don't have time to contribute to the document.

Chris.

David Chadwick wrote:

> This topic has been briefly discussed on this list before (30 July),
> but no conclusions were reached. Briefly the situation is that X.500
> DAP allows a user to search an entry and only request that matched
> values are returned from a multi-valued attribute rather than all
> attributes. LDAP only allows all or no values to be returned.
>
> There has also been a request in the PKIX group that LDAP should
> allow a single user certificate to be returned (the one that matches
> the users filter), rather than all the users certificates.
>
> I believe that once clients start to retreive schema definitions they
> will also want matched values only to be returned.
>
> There are a couple of approaches this group can take
>
> i) say that this is not a significant problem and ignore it. Let the
> client sort out the value it wants
>
> ii) say that it is a significant problem and try to fix it via a new
> matchedValuesOnly control ID. (I can volunteer to write the ID if
> people are interested in it)
>
> What do people think about this?
> 
> David
>
> ***************************************************
>
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351  Fax +44 161 745 8169
> Mobile +44 790 167 0359
> *NEW* Email [email-masked] *NEW*
> Home Page  http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
>
> ***************************************************

--
------------------------------------------------------------------------
Chris Apple                     Business Site: AnyWho Directory Service
Internet Directory Group                       http://www.anywho.com
AT&T Labs
[email-masked]
+1 973 236 6470                 Tired of slow directories?  Try AnyWho.
------------------------------------------------------------------------

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 9 Aug 1999 09:42:50 +1000

I agree with below. Certainly the component matching rules for complex
attributes such as certs, CRLs, mail lists, etc is being implemented by
some in their DSAs. Therefore LDAP should apply this capability. It is
worthy to note that LDAP serves should provide a generic component
matching capability for complex attributes. 

For client access though, its a question of the application concerned on
what (eg.) cert/crl it uses and how it wants to find it. Generally the
first client app off the rank wanted by most will be a CA management
application - which is requred to find certs based on validity, etc. In
addition OCSP servers that are directory capable could use component
matching for finding CRL entries (if the directory is trusted).

regards alan

> From:	Ella Paton Bassett 
> Sent:	Saturday, August 07, 1999 2:29 AM
> To:	Sean Mullan
> Cc:	[email-masked]; [email-masked]
> David:
> We would like to see these drafts written. Thanks for pointing out
> that
> we need the matched values only feature in addition to the certificate
> matching rule to select a particular value of a certificate using
> LDAP. 
> 
> We are also curious to know if client vendors intend to implement
> attribute types other than userCertificate to retrieve certificates
> from
> the directory using LDAP v3.
> 
> Ella
> 
> Sean Mullan wrote:
> > 
> > Hi David,
> > 
> > I'd like to work on an LDAP draft with you as I believe this is very
> > important. (Actually, I was planning to write a draft but I was a
> > bit discouraged by the lack of response to my message on 7/30).
> Please
> > let me know how you want to coordinate this.
> > 
> > I think that 2 drafts are probably needed, one describing a control
> for the
> > matchedValuesOnly feature and another for describing the X.509
> certificate
> > and CRL matching rules as new LDAP matching rules.
> > 
> > Thanks,
> > --Sean
> > 
> > David Chadwick wrote:
> > >
> > Sean Mullan                     Email: [email-masked]
> > Sun Microsystems Laboratories   Tel:   (781) 442-0926
> > One Network Drive               Fax:   (781) 442-1692
> > Burlington, MA 01803-0902 << File: Card for Ella Paton Bassett >>

---

From: "Miklos, Sue A." <[email-masked]>
Date: Tue, 10 Aug 1999 12:41:56 -0400

In the early days of a program called "MISSI", we defined a different
attribute type (with a single value) for every permutation of algorithm
used, and subsequently named it (for example) FortezzaKMandSigCertificate;
SNDSSuiteACertificate, ad nauseum with a different oid for each type.  We
found it to be a minimally functional design, that did not allow for
extensibility, unless we had a mechanism to disseminate changes to all of
the client and crypto service provider software already deployed.  I believe
you've already run into that issue with schema discovery.

It is not out of the realm of possibility again, in the certificate
mindset)to have products allowing us to 1) store many (where I believe an
order of 10-25 per entry is possible) values for any given attribute type
and 2) allow either the user interface or the CSP software interface to
provide selected pieces of information (CA issuer's name?  algorithm
identifier?) to speed up the information retrieval process, without being
required to know, in advance, what is actually stored in the repository.

I'm not sure that I am helping your discussion, but I do have to integrate a
variety of user skills (some can surf a DIT, others can barely create
powerpoint briefings) and a variety of crypto service providers (some have
hard-coded, others are implementing modular capabilities).  Having a
mechanism to selectively retrieve information on a reasonable set of
criteria would be extremely beneficial.  That set of criteria can be (as in
X.500) on an attribute by attribute basis.  The exact match criteria may be
problematic if it's a human who makes errors in the entry of the criteria...

Sandi Miklos
-----Original Message-----
From: Bruce Greenblatt [mailto:[email-masked]]
Sent: Tuesday, August 10, 1999 11:20 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Returning single values from multivalued attributes

I'm a little confused by this.  My perspective is that the requirements for
this new functionality arise almost entirely from poor Schema/DIT design.
I certainly agree that if you put 1000s of certificates in a single
attribute, you will have difficulty retrieving a single certificate
instance from the entry inquestion.  The obvious solution to this problem
is NOT to enhance LDAP (or DAP for that matter).  The obvious solution IS
"don't put 1000s of certificates in a single attribute".

Bruce
==============================================
Bruce Greenblatt
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 10 Aug 1999 22:03:06 -0700

>In the early days of a program called "MISSI", we defined a different
attribute type (with
>a single value) for every permutation of algorithm used, and subsequently
named it (for 
>example) FortezzaKMandSigCertificate; SNDSSuiteACertificate, ad nauseum
with a different 
>oid for each type.  We found it to be a minimally functional design, that
did not allow for 
>extensibility, unless we had a mechanism to disseminate changes to all of
the client and 
>crypto service provider software already deployed.  I believe you've
already run into that 
>issue with schema discovery.
>
mindset)to have
>products allowing us to 1) store many (where I believe an order of 10-25
per entry is 
>possible) values for any given attribute type and 2) allow either the user
interface or 
>the CSP software interface to provide selected pieces of information (CA
issuer's name?  
[snip ...]

Sandi,

I still don't think that this is really a requirement.  If you only have
around 10 attribute values, you're better off getting them all from the
server, and tossing the ones that you don't want.  This is easily done
using a client API...  You'll be doing the exact same thing on the client
side that the server would be doing.   On the other hand, if you have in
the range of 1000 attribute values, I would definitely urge you to abandon
whatever scheme has let you here, and redesign the application.  I know of
at least one firm that will help you do this (for a small fee :))...

Bruce

---

From: "Miklos, Sue A." <[email-masked]>
Date: Wed, 11 Aug 1999 11:35:58 -0400

One of the larger system integration challenges include evaluating every
component and aspect of the system and selecting those elements that lead to
efficient, effective and secure communications.

If the engineering branch does their job correctly, they will select
protocols and applications that lend themselves to meeting those needs.  

The payoff for the Operations and Maintenance budget exercise includes
ensuring that the (ever diminishing supply of) highly trained system
administrators do not have to manage an excessive number of permutations.
Configuration management is very expensive.

I have no 'vested' interest in how it ends up being done.  I do have a
vested interest in deploying a workable, manageable system.  And I am
further constrained (or blessed - ) that I can guarantee that I will not end
up with a homogenous environment.

Sandi Miklos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 11, 1999 11:12 AM
To: [email-masked]
Subject: Re: Returning single values from multivalued attributes

> "Miklos, Sue A." wrote:
> 
> Bruce, with enough time and money, we could solve any problem...
> 
>  however, I am constrained by crypto service providers that may take
> up to 1+ second to go through each variant of a certificate recieved,
> in addition to any other non-security-related processing that has to
> occur.  This leads to unacceptably slow performance.  Any streamlining
> at any point in the process is a good thing.

First thought which comes into my mind is that it
has to be easier and cheaper for the human species
as a whole, to fix the broken clients rather than
extend the LDAP protocol for everyone.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 12 Aug 1999 12:50:30 +0200

At 10:42 11.08.99 -0400, Miklos, Sue A. wrote:

>  however, I am constrained by crypto service providers that may take up 
> to 1+ second to go through each variant of a certificate recieved, in 
> addition to any other non-security-related processing that has to 
> occur.  This leads to unacceptably slow performance.  Any streamlining at 
> any point in the process is a good thing.

if you have eval times of 1+ seconds on a cert, this probably means that 
the service provider is doing real crypto - verifying signatures.

You don't need real crypto to do the kind of rejection of values that the 
MatchedValues control would provide - you only need to look at the cert.

Certs aren't encrypted.

                           Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: "Miklos, Sue A." <[email-masked]>
Date: Thu, 12 Aug 1999 11:48:21 -0400

My apologies to the ldap list members who are not even remotely interested
in this discussion.  

When I say "crypto service provider" (or you refer to 'crypto') I aggregated
all the functionality associated with accepting an object, creating a hash
value for comparison, comparing the certificate id to a known valid crl
(which also has a signature applied, which needs the same 'checking' as the
certificate) on a certificate (attribute value) by certificate (attribute
value) basis. The process repeats itself for each level in the certificate
hierarchy. 

This is independent of location (client or server) except the performance
overhead is likely to be higher on a server (validate up to 100 simultaneous
signed operations concurrently?) if the transactions themselves are
digitally signed (binds, modifies,etc.)

So what I wanted to do was maximize effectiveness when the client goes to
get a certificate (as in, please retrieve the certificate who's oid maps to
a given algorithm or a given validity period ONLY). My concern is that if
the server returns ALL the values of a given attribute type (certificate in
this case) and the client passes all of them off to the "CSP", then my
performance has just gone way down.

If we wish to continue this dialog, let's remove it from the list so that I
don't further annoy list members who are not interested in this particular
issue.

Regards,
Sandi Miklos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 12, 1999 11:17 AM
To: Miklos Sue A.
Cc: 'Harald Tveit Alvestrand'; 'Bruce Greenblatt'; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Returning single values from multivalued attributes

> In an attempt to clarify my statement, I consider the entire
> certificate path processing (up to 3 levels in a hierarchy?) to
> include all the necessary elements of signature and hash
> validation/comparison as well as crl checking (which I believe to be
> the proper behavior). This entire process should occur whenever the
> 'retrieving protocol" conveys its "payload" to the crypto service
> provider module.
> 
> The CSP module is going to cycle through whatever it's given until it
> reaches some state of completion (no more certificates to check).
> 
> I would like the ability for the data repository to selectively return
> information through an application/protocol exchange that can request
> specific information, narrowing the processing time.  This "rejection
> of values" should, in my view, occur prior to handing the 'payload' to
> a CSP module.  That was all I was trying to convey.

I'm lost now. If the crypto needs to be done, and takes
much work, it'll take much work whether you do it on the server
or the client (clients are typically faster than servers these
days). If the crypto doesn't need to be done to pick the right
cert, then you don't need your 1 second thinking time.