Joe Gluck wrote:
> I did not bother to check the performance, just because
> it is obvious that it is more time,


You might be surprized to discover that the obvious thing
is not true.

http://www.faqs.org/docs/artu/optimizationchapter.html

http://www.cookcomputing.com/blog/archives/000084.html
http://www.flounder.com/optimization.htm
http://www.petefreitag.com/item/509.cfm

> and even if it is not a lot, why not be better
> while I know that performance is a major issue on our system.


I am willing to bet $20 bucks that if you do it with string parsing and
comparison, it won't even be in the top 10 issues affecting the
performance of your application in its steady normal operation.

Please consider trying it out.

> Any way, thank you every one, who participated on this thread.


Thank you for raising this issue.

> On 1/31/06, Lev Walkin wrote:
>> Joe Gluck wrote:
>>> 1. I don't expect any thing developed specilay for me, I was just
>>> wondering if there is any one out there that knew about a function
>>> that already exists and does it.
>>>
>>> 2. I am not designing a system to break in 10 years, I am thinking of
>>> better performance for the time until we need to find a better
>>> solution.

>> Have you measured that performance and found the simple string
>> comparison (coupled with optional parsing) to be the main contention
>> point in your application?
>>
>> Have you used profiler to confirm your performance suspicions?
>>
>> If not, please do. You'll be thoroughly surprized.
>>
>>> BTW why will I run into trouble at 2015 it should be good up to 2037?
>>> Am I missing some thing?

>> In 2015 there will be certificates which will break in 2037, like
>> now there are these which break in 2015.
>>
>>> Thanks,
>>>
>>> Joe
>>>
>>> On 1/31/06, David Schwartz wrote:
>>>>> I will not get certificates today for after 2045 because the
>>>>> certificates that I am checking are certificates that already past a
>>>>> validation check and have been inserted into my cache system, therefor
>>>>> it is a certificate signed by our own system which does not sign for
>>>>> more then 25 year. most are 1 year.
>>>>>
>>>>> Thanks Joe
>>>> You may have a special case, but you can't expect the library to be
>>>> designed for your special case. You'll run into trouble after 2015 anyway --
>>>> any special reason you're designing things to break in 10 years?
>>>>
>>>> DS
>>>>
>>>>
>>>> __________________________________________________ ____________________
>>>> OpenSSL Project http://www.openssl.org
>>>> Development Mailing List openssl-dev@openssl.org
>>>> Automated List Manager majordomo@openssl.org
>>>>
>>> __________________________________________________ ____________________
>>> OpenSSL Project http://www.openssl.org
>>> Development Mailing List openssl-dev@openssl.org
>>> Automated List Manager majordomo@openssl.org
>>>

>> __________________________________________________ ____________________
>> OpenSSL Project http://www.openssl.org
>> Development Mailing List openssl-dev@openssl.org
>> Automated List Manager majordomo@openssl.org
>>

> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majordomo@openssl.org
>


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org