iText Signature Validation Policy Details

With the release of iText Core 9.0 we finalized the dedicated module PDF digital signature validation. You can see Signature Module Refactoring & Built-in Signature Validation API for a basic usage overview, however, this article goes into detail on the validation policy itself,

In general, the validation policy iText uses for digital signatures follows the standard RFC and ETSI profiles.

For reference, here is a list of resources we used during our development:

• https://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf

• https://datatracker.ietf.org/doc/html/rfc5280

• https://datatracker.ietf.org/doc/rfc3161/

• https://datatracker.ietf.org/doc/rfc5816/

However, in this article we want to highlight some particular procedures of this policy, and deviations from the standards.

Required Certificate Extensions

Refer to the Java and .NET API docs for additional details.

• A Key Usage extension is never required, but, if present, shall contain the following values in these cases:

  • key_cert_sign value shall be present if the certificate in question is used to sign other certificates (thus CA).

  • crl_sign value shall be present if the certificate in question is used to sign a CRL response.

  • For a signing certificate no key usage extension is required. This behavior technically contradicts the ETSI requirements, but is widely supported by other validation tools (including Adobe Acrobat).

• An Extended Key Usage extension is required in the following cases:

  • ocsp_signing value shall be present if the certificate in question is used to sign an OCSP response.

  • time_stamping value shall be present if the certificate in question is used to sign a timestamp signature.

• A Basic Constraints extension is required when the certificate in question is used to sign other certificates (thus CA). The value of the CA field shall be “true”. The pathLength field is optional, but, if present, will be validated accordingly.

Freshness

ETSI EN 319 102-1 defines “freshness” as “the required freshness of the revocation status information is the maximum accepted difference between the validation time and the issuance time of the revocation status information”. By default the values are as follows:

• For “Historical” revocation data (the one which is stored in the document and covered by the timestamp signature) the default freshness value is 1 minute.

• For “Present” revocation data (the one which is not covered by any timestamp, thus, validated in the current date time) the default freshness value is 30 days.

If the revocation data is older, compared to the validation time, than this predefined value, a CRL or OCSP response won’t be considered trustworthy, and therefore will not be used during the validation.

Certificate validation time

When it comes to signature validation, the signature itself is usually validated either at the current time and date, or at some point in the past, if Proof of Existence is provided (timestamp signatures usually).

For the certificate chain, however, two possible validation models are usually applied.

• “shell” model: the full chain must be valid at the time of signing (effectively, the validity period of an intermediate CA must encompass that of all the certificates below it in the chain).

• “chain” model: all certificates in the chain must be valid at usage time. (the time they were used to generate another certificate in the chain).

iText currently uses only the “shell” model for certificate chain validation.