Harald,
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.
Sandi
-----Original Message-----
From: Harald Tveit Alvestrand [mailto:Harald@Alvestrand.no]
Sent: Thursday, August 12, 1999 6:51 AM
To: Miklos, Sue A.; 'Bruce Greenblatt'; mcs@netscape.com;
d.w.chadwick@salford.ac.uk
Cc: ietf-ldapext@netscape.com
Subject: RE: Returning single values from multivalued attributes
At 10:42 11.08.99 -0400, 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.
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
Harald.Alvestrand@maxware.no