Signature validation

Taking a very (or over) simplified model, validating a digital signature can be seen as:

• On one hand, verifying the cryptographic validity of the digital signature value (part of it consisting in decrypting the digital signature value and comparing the decrypted value with the hash of the signed data).

• On the other hand, verifying the validity of the signing certificate (see certification path validation).

We’ll see that even such a simplified model is useful for the purpose of introducing common concepts in digital signature validation.

Let’s imagine that we want to validate a digital signature and the time when this validation occur is denoted as Tval.

If the signing certificate successfully passes the certification path validation at Tval, and the digital signature value is cryptographically valid, one can then say that the digital signature is valid at Tval.

Now, if computing the hash of the signed data does not yield the same value as the decryption of the signature value, one can then say that the digital signature is invalid.

Beyond valid and invalid digital signature however, there are a lot of cases when one cannot determine the validity of a digital signature. Below are some examples where one cannot conclude that a digital signature is valid or invalid, in which case the validity status of the signature is indeterminate.

Let’s imagine that at Tval, when we are trying to access the certification status information, that information is unavailable (e.g. the CRL cannot be downloaded, the OCSP responder is unavailable). Then it is not possible, at Tval, to determine whether the signing certificate is valid or not because at that time we are lacking information to conclude on that validity status. Because the validity of the signing certificate cannot be determined, the validity of the overall signature cannot be determined either and the validity of the signature is indeterminate. However, this status is only indeterminate because we do not have the information that would allow us to conclude, retrying to validate the signature with more information (e.g. at a time when the CRLs can be downloaded) could result in a definite valid or invalid status.

A more complex example is when, at Tval, revocation information indicates that the signing certificate is revoked since a time indicated as Trev (which is thus < Tval).

Then at Tval, we can only conclude that the signing certificate is revoked and thus the signature cannot be determined as valid at Tval. However, this does not mean necessarily that the signature was created when the signing certificate was revoked, it may very well be that the signature was created at a time prior to Trev and that, should we have validated the signature at that time, the validation would have been successful. Therefore, we cannot conclude that the signature is invalid because we do not know in a definite manner if the signature was created before the revocation of the signing certificate.

For instance, if we had a proof that the signature existed before Trev, such as a signature timestamp indicating a time Tpoe < Trev, then using that proof of existence (POE) we can conclude that the signature was created before the signing certificate was revoked and this could allow us to produce a definite conclusion.

On the other hand, if we had a proof that the signature could not have existed before Trev, such as a content timestamp indicating a time Tcnt > Trev (a content timestamp is necessarily created before the digital signature value), then we could definitely conclude that the signing certificate was revoked when the digital signature was created and thus that the digital signature is invalid.

Another issue that can be illustrated here is when one creates a digital signature using cryptographic algorithms that are not considered secure: In such a case, it may be possible for an malicious actor to create counterfeited signed documents.

When validating a signature, it is therefore necessary to verify that the signature was created using cryptographic algorithms and parameters that are considered as secure. This is usually done by comparing a POE of the digital signature value with a sunset date for the cryptographic algorithms and parameters involved. A sunset date for a cryptographic algorithm and/or parameter is called a cryptographic constraint, and the application validating the signature usually keeps a set of such dates and cryptographic algorithms and parameters; this set is what is called the set of cryptographic constraints.

In general, the validation of a signature is made against a set of constraints, which the cryptographic constraints are a part of, that is also sometimes referred to as a signature validation policy.

The standard ETSI EN 319 102-1 specifies a complete validation model and procedures for the validation of “AdES digital signatures”, which are implemented in DSS. The result of a validation process performed according to those procedures is a validation report and an indication which can be:

• TOTAL-PASSED indicating that the signature has passed verification and it complies with the signature validation policy.

• INDETERMINATE indicating that the format and digital signature verifications have not failed but there is insufficient information to determine if the electronic signature is valid.

• TOTAL_FAILED indicating that either the signature format is incorrect or that the digital signature value fails the verification.

For each of the validation checks/constraint (e.g. signature format, signing certificate validity), the validation process must provide information justifying the reasons for the resulting status indication as a result of the check against the applicable constraints. In addition, the ETSI standard defines a consistent and accurate way for justifying statuses under a set of sub-indications. This allows the user to determine whether the signature validation has succeeded and the reason in case of a failure.

The following table presents the indications and sub-indications that can be encountered at completion of a signature validation process. For a detailed description of their meaning, refer to ETSI EN 319 102-1 ([R09]).