[xmlsec] Verify signature after certificate expired
Aleksey Sanin
aleksey@aleksey.com
Fri, 11 Oct 2002 08:06:28 -0700
--------------020600080204020505050602
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Thanks for the patch! I'll take a look at it later today. Of course, you
have the information
about the reason why verification failed. I'll try to add the code to
xmlsec to expose
this information to the application.
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
>Aleksey:
> Next step -- I've gotten the new option to build on Win32 which
>doesn't have a strptime() (at least not that I can find in MSVC 6.0).
>So, I've written a quick and not too dirty date/time parser using
>sscanf() that's usable whenever strptime() isn't available. Also, I
>fixed the spelling of the --verification-time option. I hope that
>doesn't break any scripts you have somewhere. I'm attaching the changes
>-- they appear to work for me (tried three cases, very old date, current
>date, very future date). I've now got to go modify my code to grab the
>date/time and pass it into xmlsec. In the meantime, I've got one more
>question: When I run the sample app and it fails due to an invalid date,
>what I get is:
>
>ERROR
>Error: operation failed
>
>(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\keyinf
>o.c:1196): error 31: cert verification failed :
>
>(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\keys.c
>:518): error 17: key not found :
>
>(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\xmldsi
>g.c:1437): error 17: key not found :
>
>(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\xmldsi
>g.c:1175): error 2: xmlsec operation failed : xmlSecSignedInfoRead - -1
>
>(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\xmldsi
>g.c:733): error 2: xmlsec operation failed : xmlSecSignatureRead - -1
>
>I see similar stuff in my application log if I just set the system
>timestamp into the future. The problem is that it says only:
>
>error 31: cert verification failed :
>
>Is there any way to get the reason that cert verification failed into
>the error stack?
>Thanks!
> Ferrell
>
>-------------------------------------------
>
>203,204c203
>< #ifndef XMLSEC_NO_STRPTIME
>< " --verificaiton-time <time> the local time in \"YYYY-MM-DD
>HH:MM:SS\"\n"
>---
>
>
>> " --verification-time <time> the local time in \"YYYY-MM-DD
>>
>>
>HH:MM:SS\"\n"
>206d204
>< #endif /* XMLSEC_NO_STRPTIME */
>517,518c515
>< #ifndef XMLSEC_NO_STRPTIME
>< } else if((strcmp(argv[pos], "--verificaiton-time") == 0) &&
>(pos + 1 < argc)) {
>---
>
>
>> } else if((strcmp(argv[pos], "--verification-time") == 0) &&
>>
>>
>(pos + 1 < argc)) {
>539d535
>< #endif /* XMLSEC_NO_STRPTIME */
>1007a1004,1041
>
>
>>/*
>> ** ParseDateString()
>> *
>> * PARAMETERS: pszDateTime - pointer to date/time string
>> * ptmOut - pointer to struct returning
>>
>>
>parsed time value
>
>
>> *
>> * DESCRIPTION: Parse a date-time string into a struct tm
>> * Input: yyyy-mm-dd.hh:mm:ss (where '.'
>>
>>
>is any character)
>
>
>> *
>> * RETURNS: Zero (success) or -1 (format error)
>> *
>> */
>>#ifdef XMLSEC_NO_STRPTIME
>>int ParseDateString(const char* pszDateTime, struct tm* ptmOut)
>>{ int iStatus = 0;
>> int iCount = 0;
>> memset(ptmOut, 0, sizeof(*ptmOut));
>> ptmOut->tm_isdst = -1;
>> iCount = sscanf(pszDateTime, "%4u-%2u-%2u%*c%2u:%2u:%2u",
>> &ptmOut->tm_year,
>>
>>
>&ptmOut->tm_mon, &ptmOut->tm_mday,
>
>
>> &ptmOut->tm_hour,
>>
>>
>&ptmOut->tm_min, &ptmOut->tm_sec);
>
>
>> if (iCount != 6 ||
>> ptmOut->tm_year < 1900 || ptmOut->tm_year > 2036 ||
>> ptmOut->tm_mon < 1 || ptmOut->tm_mon > 12 ||
>> ptmOut->tm_mday < 1 || ptmOut->tm_mday > 31 ||
>> ptmOut->tm_hour < 0 || ptmOut->tm_hour > 23 ||
>> ptmOut->tm_min < 0 || ptmOut->tm_min > 59 ||
>> ptmOut->tm_sec < 0 || ptmOut->tm_sec > 61) {
>> iStatus = -1;
>> } else {
>> ptmOut->tm_year -= 1900; /* tm relative format year */
>> ptmOut->tm_mon -= 1; /* tm relative format month */
>> }
>> return iStatus;
>>} /* of ParseDateString() */
>>#endif /* XMLSEC_NO_STRPTIME */
>>
>>
>>
>1022a1057,1062
>
>
>>#else /* XMLSEC_NO_STRPTIME */
>> if (ParseDateString(str, &tm) < 0) {
>> fprintf(stderr, "Error: the local system time in \"YYYY-MM-DD
>>
>>
>HH:MM:SS\" is expected isntead of \"%s\"\n", str);
>
>
>> return(-1);
>> }
>>#endif /* XMLSEC_NO_STRPTIME */
>>
>>
>1025,1027d1064
>< #endif /* XMLSEC_NO_STRPTIME */
>< fprintf(stderr, "Error: strptime() function is not supported by
>your system, feature is disabled\n");
>< return(-1);
>
>
>-----Original Message-----
>From: Aleksey Sanin [mailto:aleksey@aleksey.com]
>Sent: Thursday, October 10, 2002 3:53 AM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: xmlsec@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
>>
>>
>>
>>
>>
>
>
>_______________________________________________
>xmlsec mailing list
>xmlsec@aleksey.com
>http://www.aleksey.com/mailman/listinfo/xmlsec
>
>
--------------020600080204020505050602
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
Thanks for the patch! I'll take a look at it later today. Of course, you
have the information<br>
about the reason why verification failed. I'll try to add the code to xmlsec
to expose<br>
this information to the application.<br>
<br>
Aleksey<br>
<br>
Moultrie, Ferrell (ISSAtlanta) wrote:<br>
<blockquote type="cite"
cite="mid121184A7DB1F9143BB5E3FACCB54875706640A@atlmaiexcp02.iss.local">
<pre wrap="">Aleksey:
Next step -- I've gotten the new option to build on Win32 which
doesn't have a strptime() (at least not that I can find in MSVC 6.0).
So, I've written a quick and not too dirty date/time parser using
sscanf() that's usable whenever strptime() isn't available. Also, I
fixed the spelling of the --verification-time option. I hope that
doesn't break any scripts you have somewhere. I'm attaching the changes
-- they appear to work for me (tried three cases, very old date, current
date, very future date). I've now got to go modify my code to grab the
date/time and pass it into xmlsec. In the meantime, I've got one more
question: When I run the sample app and it fails due to an invalid date,
what I get is:
ERROR
Error: operation failed
(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\keyinf
o.c:1196): error 31: cert verification failed :
(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\keys.c
:518): error 17: key not found :
(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\xmldsi
g.c:1437): error 17: key not found :
(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\xmldsi
g.c:1175): error 2: xmlsec operation failed : xmlSecSignedInfoRead - -1
(D:\projects\thirdparty\xmlsoft-org-build-trees\xmlsec-021009\src\xmldsi
g.c:733): error 2: xmlsec operation failed : xmlSecSignatureRead - -1
I see similar stuff in my application log if I just set the system
timestamp into the future. The problem is that it says only:
error 31: cert verification failed :
Is there any way to get the reason that cert verification failed into
the error stack?
Thanks!
Ferrell
-------------------------------------------
203,204c203
< #ifndef XMLSEC_NO_STRPTIME
< " --verificaiton-time <time> the local time in \"YYYY-MM-DD
HH:MM:SS\"\n"
---
</pre>
<blockquote type="cite">
<pre wrap=""> " --verification-time <time> the local time in \"YYYY-MM-DD
</pre>
</blockquote>
<pre wrap=""><!---->HH:MM:SS\"\n"
206d204
< #endif /* XMLSEC_NO_STRPTIME */
517,518c515
< #ifndef XMLSEC_NO_STRPTIME
< } else if((strcmp(argv[pos], "--verificaiton-time") == 0) &&
(pos + 1 < argc)) {
---
</pre>
<blockquote type="cite">
<pre wrap=""> } else if((strcmp(argv[pos], "--verification-time") == 0) &&
</pre>
</blockquote>
<pre wrap=""><!---->(pos + 1 < argc)) {
539d535
< #endif /* XMLSEC_NO_STRPTIME */
1007a1004,1041
</pre>
<blockquote type="cite">
<pre wrap="">/*
** ParseDateString()
*
* PARAMETERS: pszDateTime - pointer to date/time string
* ptmOut - pointer to struct returning
</pre>
</blockquote>
<pre wrap=""><!---->parsed time value
</pre>
<blockquote type="cite">
<pre wrap=""> *
* DESCRIPTION: Parse a date-time string into a struct tm
* Input: yyyy-mm-dd.hh:mm:ss (where '.'
</pre>
</blockquote>
<pre wrap=""><!---->is any character)
</pre>
<blockquote type="cite">
<pre wrap=""> *
* RETURNS: Zero (success) or -1 (format error)
*
*/
#ifdef XMLSEC_NO_STRPTIME
int ParseDateString(const char* pszDateTime, struct tm* ptmOut)
{ int iStatus = 0;
int iCount = 0;
memset(ptmOut, 0, sizeof(*ptmOut));
ptmOut->tm_isdst = -1;
iCount = sscanf(pszDateTime, "%4u-%2u-%2u%*c%2u:%2u:%2u",
&ptmOut->tm_year,
</pre>
</blockquote>
<pre wrap=""><!---->&ptmOut->tm_mon, &ptmOut->tm_mday,
</pre>
<blockquote type="cite">
<pre wrap=""> &ptmOut->tm_hour,
</pre>
</blockquote>
<pre wrap=""><!---->&ptmOut->tm_min, &ptmOut->tm_sec);
</pre>
<blockquote type="cite">
<pre wrap=""> if (iCount != 6 ||
ptmOut->tm_year < 1900 || ptmOut->tm_year > 2036 ||
ptmOut->tm_mon < 1 || ptmOut->tm_mon > 12 ||
ptmOut->tm_mday < 1 || ptmOut->tm_mday > 31 ||
ptmOut->tm_hour < 0 || ptmOut->tm_hour > 23 ||
ptmOut->tm_min < 0 || ptmOut->tm_min > 59 ||
ptmOut->tm_sec < 0 || ptmOut->tm_sec > 61) {
iStatus = -1;
} else {
ptmOut->tm_year -= 1900; /* tm relative format year */
ptmOut->tm_mon -= 1; /* tm relative format month */
}
return iStatus;
} /* of ParseDateString() */
#endif /* XMLSEC_NO_STRPTIME */
</pre>
</blockquote>
<pre wrap=""><!---->1022a1057,1062
</pre>
<blockquote type="cite">
<pre wrap="">#else /* XMLSEC_NO_STRPTIME */
if (ParseDateString(str, &tm) < 0) {
fprintf(stderr, "Error: the local system time in \"YYYY-MM-DD
</pre>
</blockquote>
<pre wrap=""><!---->HH:MM:SS\" is expected isntead of \"%s\"\n", str);
</pre>
<blockquote type="cite">
<pre wrap=""> return(-1);
}
#endif /* XMLSEC_NO_STRPTIME */
</pre>
</blockquote>
<pre wrap=""><!---->1025,1027d1064
< #endif /* XMLSEC_NO_STRPTIME */
< fprintf(stderr, "Error: strptime() function is not supported by
your system, feature is disabled\n");
< return(-1);
-----Original Message-----
From: Aleksey Sanin [<a class="moz-txt-link-freetext" href="mailto:aleksey@aleksey.com">mailto:aleksey@aleksey.com</a>]
Sent: Thursday, October 10, 2002 3:53 AM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: <a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->as
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->soon
</pre>
<blockquote type="cite">
<pre wrap="">(I just turned the X509 stuff over to them) but if we'd missed it, it
would have been very painful.
Ferrell
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
xmlsec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a>
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------020600080204020505050602--