Verify digital signature with ItextSharp

Question

I\'m trying to verify digital signatures in c# using iTextSharp.

I\'ve followed the example in the iText web (http://gitlab.itextsupport.com/itextsharp/tutorial/blob/mas

Answer 1

There are two aspects to this question:

• Why does iTextSharp appear not to be able to verify the given example signature provided by Adobe?
• At which date, using which CRL, should revocation checks be made?

Verifying the given signature using iTextSharp

Using the sample code from C5_03_CertificateValidation.cs the OP couldn't verify that the certificates in question, in particular the signer certificate, was not revoked, neither "at the time of signing" nor "today". I, on the other hand, immediately could verify that "at the time of signing".

The major difference between the OP's tests and my tests were that the former ones occurred using the OP's time zone UTC-3 while mine were using UTC+2.

Thus, I ran the code using different system time zones, and indeed: The verification only succeeded in time zones UTC-01 and up, i.e. UTC-01, UTC, UTC+01, ...

The time returned by DateTime cal = pkcs7.SignDate in the tests turned out to be given using the current local time zone.

Apparently, therefore, the CRL validation code does not use times according to the local time zone but instead in some fixed time zone, presumably in UTC itself.

Thus, one can make the example code work universally by

changing

crlVerifier.Verify(signCert, issuerCert, date)

to

crlVerifier.Verify(signCert, issuerCert, date.ToUniversalTime())

as the OP could confirm after tests.

Choosing the right date and CRL for revocation checks

The OP mentions that he would prefer to execute revocation checks using current time and current versions of the CRL of the PKI in question.

While this approach appears to make use of the most up-to-date information available, its usefulness is limited:

• If the certificate under scrutiny is beyond its original validity period now (i.e. its valid-not-after date is in the past) but was not at the time of signing, information about its possible revocation at the time of signing may not be on the CRL anymore. Indeed, according to RFC 5280

  An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period.

  By implication, therefore, it may be removed from the CRL in any version issued after the validity period.

  Thus, it makes no sense to use a CRL newer than the end of the validity period of the certificate.

• Even if the certificate under scrutiny is not yet beyond its original validity period, the PKI provider might have gone out of business. In that case all access points for revocation information now might only serve a final version of the CRL created when the PKI was still active or none at all.

  In that case one can use that final CRL or the newest CRL one still has available (e.g. in some CRL cache) as long as the CRL is recent enough.

Thus, validation policies often allow and even require the use of an older CRL as long as it is recent enough, at least the CRL's nextUpdate value must be after the signing time, and at the same time old enough, at least the CRL's thisUpdate value must be before the end of the validity period of the certificate.

One item to consider, though, is what one considers to be the signing time to compare with when checking whether an older CRL can be used.

The pkcs7.SignDate used in the iText example code above may merely be the content of a field in the PDF or the CMS container which might have been faked: Someone might have gotten hold of the private key; after the associated certificate has been revoked, that person might still misuse the key setting the signing time information to a date before revocation.

Thus, you might determine the signing date differently. E.g.

• if the signature container contains a signature time stamp or the PDF document contains a later document time stamp, and if that time stamp can be trusted, the time of that time stamp can be used;

• if the signed document has been locally stored for some time (e.g. in some archiving system) and the time of storage is known and can be trusted, that time can be used;

• ...