Subject: RE: Returning single values from multivalued attributes

From: "Miklos, Sue A." <[email-masked]>
Date: Thu, 12 Aug 1999 10:02:58 -0400

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:[email-masked]]
Sent: Thursday, August 12, 1999 6:51 AM
To: Miklos, Sue A.; 'Bruce Greenblatt'; [email-masked];
[email-masked]
Cc: [email-masked]
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
[email-masked]

---

From: [email-masked] (David Boreham)
Date: Thu, 12 Aug 1999 08:17:21 -0700

> "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.
> 
> 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.