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: dboreham@netscape.com [mailto:dboreham@netscape.com]
Sent: Thursday, August 12, 1999 11:17 AM
To: Miklos Sue A.
Cc: 'Harald Tveit Alvestrand'; 'Bruce Greenblatt'; mcs@netscape.com;
d.w.chadwick@salford.ac.uk; ietf-ldapext@netscape.com
Subject: Re: Returning single values from multivalued attributes
> "Miklos, Sue A." wrote:
> 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.