[xmlsec] Verify signature after certificate expired

[Igor Zlatkovic]

Hi there,

You are basically right, but first let us clear something: I don't use 
Visual Studio .NET :-) I tried, but it gave me trouble with its sick 
C-runtime, so I vetoed its further existence on my hard drive. I use MS 
compiler which is a part of Windows XP Driver Development Kit, all of it 
from the command line. I have no IDE installed, I use XEmacs for my 
source-editing needs, even for .NET development :-)

Well, my compiler from the DDK has __FUNCTION__ predefined, but is far more 
recent than the one delivered with the Visual Studio 6. It can very well be 
that the VS6 compiler (version 12 and lower) doesn't know about this macro. 
My appologies. I have no way to test compilers with version numbers other 
than my own.

The offending line would then be something like

   #if !defined(__GNUC__) || (_MSC_VER >= 1300)

and that should solve it. I'm now hacking something on Linux and will do 
this line myself when I boot Windows again, unless done by then allready :-)

By the way, Ferell, could you please, please test the above line with your 
compiler and confirm it is okay?

Ciao
Igor


Aleksey Sanin wrote:
> Igor made changes in the Win32 build and forgot that not everyone uses
> Microsoft .Net Visual Studio :) MS VC 6.0 has no __FUNCTION__ and
> this caused problems. I guess the correct path is:
> 
> 326c326,327
> ! #if !defined(__GNUC__) && !defined(_MSC_VER)
> ---
> ! #if !defined(__GNUC__) && (!defined(_MSC_VER) || (_MSC_VER < 1300))
> 
> 
> What do you think, Igor?
> 
> Aleksey.
> 
> 
> 
> Moultrie, Ferrell (ISSAtlanta) wrote:
> 
>>Aleksey:
>>  Thanks for making these changes. I've pushed aside what I was working
>>on in my application so that I can work with this change. I pulled the
>>XMLSec tips with your changes from CVS and built it on Win32. With one
>>minor problem it builds and runs without any regression errors. I
>>haven't yet tried the new function bit but that is next. As for the one
>>build problem I had, I don't really understand the change you made but
>>if I put it back like it was before, everything is fine. Here's the
>>diff's:
>>
>>diff -b backup/errors.h errors.h
>>326c326,327
>>< #if !defined(__GNUC__) && !defined(_MSC_VER)
>>---
>>  
>>
>>>#if !defined(__GNUC__)
>>>    
>>>
>>
>>Without removing the !defined(_MSC_VER) and allowing the following line
>>...
>>#define __FUNCTION__
>>... to be compiled, I get zillions of errors complaining about
>>__FUNCTION__ being undefined.
>>
>>If this isn't the correct change, please let me know what I'm missing
>>and I'll try that instead. More on the cert verification as soon as I
>>can figure out your example and make the appropriate changes in my code
>>to do something similar.
>>Thanks!
>>  Ferrell
>>
>>-----Original Message-----
>>From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
>>Sent: Thursday, October 10, 2002 3:53 AM
>>To: Moultrie, Ferrell (ISSAtlanta)
>>Cc: xmlsec at aleksey.com
>>Subject: Re: [xmlsec] Verify signature after certificate expired
>>
>>
>>I understand the problem with using 0.9.7 and I am waiting for it
>>for a very long time myself :) I've changed XMLSec library so now
>>this "expired certs feature" is supported for both 0.9.6 and 0.9.7.
>>Also I added a test case to my suite to test it. The code is not
>>complicated but it's new code and I would appreciate if you will
>>try this new feature in your environment. I would be glad to help
>>you and fix any bugs you find. The fixed XMLSec version should
>>be in tonight's snapshot or you can get it from GNOME CVS.
>>
>>Thank you in advance,
>>Aleksey
>>
>>Moultrie, Ferrell (ISSAtlanta) wrote:
>>
>>  
>>
>>>Aleksey:
>>> I *must* have this stuff -- there's not really another way to do this
>>>without using a never-expiring cert from a private CA -- and that has
>>>it's own set of risks and hazards that are commisurate with, or greater
>>>than, the risk you point out of not expiring a signature after it's
>>>released. For a code and/or data signing application intended *only* to
>>>say that the data was valid at the time it was signed -- and should
>>>remain valid forever -- not having a signature expire is the
>>>proper/desired/required behavior. 
>>>For your notes below:
>>> (1) My XML has a timestamp in a predictable format that correspond
>>>precisely to the time of signing so this isn't an issue in my case. Not
>>>a problem.
>>> (2) Yucky because this is extra work in the application which I was
>>>avoiding -- but that's still not a big problem since verification setup
>>>time isn't absolutely critical to my application.
>>> (3) I believe I understand your POV and the tradeoffs -- they just
>>>don't change how my application *must* behave.
>>>
>>> If you can either prototype the required code for 0.9.6g or give me
>>>    
>>>
>>as
>>  
>>
>>>good a pointer as you can to what should be done and where, I'll check
>>>it out and test it with my application. I'm very appreciative of what
>>>you've done so far -- but I just can't use 0.9.7 in our general-release
>>>applications at this time. Too much testing -- too many unknowns -- too
>>>hard to explain if it turns out to have a critical security
>>>issue/bug/etc. Thanks again for whatever you can do to help me move
>>>forward. Finding out about this today is painful/inconvenient -- but
>>>much better than finding out about it next year when all our
>>>applications suddenly shut down. Hopefully QA would have found this
>>>    
>>>
>>soon
>>  
>>
>>>(I just turned the X509 stuff over to them) but if we'd missed it, it
>>>would have been very painful. 
>>>Ferrell
>>>
>>> 
>>>
>>>    
>>>
>>
>>  
>>
>