Skip to content

Signature Validation

Introduction

This "guide" describes how to validate digital signatures created using BankID eSign qualified certificates. It is intended for systems and APIs that receive signed documents and need to verify their authenticity and integrity.

Digital signatures provide non-repudiation - cryptographic proof that a specific person signed a specific document at a specific time. Unlike session-based authentication tokens, signed documents may be validated years after signing.

eIDAS and EU Trusted List

What is eIDAS?

eIDAS (EU Regulation 910/2014) establishes a legal framework for electronic identification and trust services across the EU/EEA.

BankID eSign produces Qualified Electronic Signatures (QES) - the highest level with legal equivalence to handwritten signatures throughout the EU/EEA.

EU Trusted List

The EU Trusted List is the authoritative registry of Qualified Trust Service Providers (QTSPs) in each EU/EEA member state.

BankID BankAxept AS / STØ AS is a Norwegian QTSP listed on the EU Trusted List.

When validating signatures, the certificate chain must terminate at a CA certificate published on the EU Trusted List. This is the only reliable trust anchor for signatures produced under eIDAS.

For testing purposes, the BankID eSign pre-production root certificate are also available in the Root Certificates document. They must not be used in production.

Validation

No CRL or OCSP is needed when validating end-user certificates

BankID eSign end-user certificates are short-lived (15 minutes). They include the valassured-ST-certs extension which indicates that no revocation checking (CRL or OCSP) is necessary when validating the certificate. The certificate lifetime is shorter than revocation propagation time, making revocation checks unnecessary. The certificate includes a link to the CRL, but it is not needed for validation. The CRL is primarily provided for compatibility with older formats that require some form of revocation data. Therefore, relying parties can skip revocation checks when validating end-user certificates issued by BankID eSign.

Minimum and recommended steps to validate a signature:

Validation Flow Diagram (click to collapse) 
flowchart TD
    A[Receive Signed Document] --> B[Extract Signature & Certificate Chain]
    B --> C{Signature Integrity Valid?}
    C -->|No| FAIL[Reject: Invalid Signature]
    C -->|Yes| D{Chain Builds to Trusted CA?}
    D -->|No| FAIL2[Reject: Untrusted Certificate]
    D -->|Yes| E{CA on EU Trusted List?}
    E -->|No| FAIL3[Reject: CA Not Trusted]
    E -->|Yes| F{Certificate Valid at Signing Time?}
    F -->|No| FAIL4[Reject: Certificate Expired]
    F -->|Yes| G{valassured-ST-certs Extension Present?}
    G -->|Yes| H[Skip Revocation Check]
    G -->|No| I{Revocation Status OK?}
    I -->|No| FAIL5[Reject: Certificate Revoked]
    I -->|Yes| J
    H --> J{Expected Signer Identity Valid?}
    J -->|No| FAIL6[Reject: Unknown Signer]
    J -->|Yes| PASS[Accept: Signature & Signer Valid]

Many (if not most) of these steps are handled automatically by signature libraries such as DSS : Digital Signature Service and its demo application. However; ensuring that the signer identity is as expected/required is a business logic that must be implemented by the relying party.

1. Signature Integrity

Verify the cryptographic signature over the signed data using the public key from the end-entity certificate.

Check Expected
Hash algorithm SHA-256
Signature algorithm ECDSA (P-256 curve)
Signature matches signed data Yes

2. Certificate Chain

Validate the complete certificate chain.

Note: The intermediate CAs are signed by BankID Root CA G2, but for eIDAS validation, trust is anchored at the intermediate CA level via the EU Trusted List.

Check Expected
Chain is complete No missing intermediates
Each certificate signature valid Yes
Intermediate CA on EU Trusted List Yes

3. Validity Period

Verify the certificate was valid at the time of signing.

Check Expected
Signing time ≥ Not Before Yes
Signing time ≤ Not After Yes

Note: BankID eSign certificates are short-lived (~15 minutes). Use the signature timestamp, not the current time, for this check.

4. Revocation Status

Short-Lived Certificate Exception

Check for the valassured-ST-certs extension:

OID Name
0.4.0.194121.2.1 valassured-ST-certs

If present: Skip OCSP/CRL checks. The certificate lifetime is shorter than revocation propagation time, making revocation checks unnecessary.

If absent: Perform OCSP or CRL check.

Method Description
OCSP Real-time query to CA's OCSP responder
CRL Check against Certificate Revocation List

Method depends on the certificate; and will the method(s) available via the Authority Info Access and/or CRL Distribution Points extensions. BankID only uses CRL where applicable.

5. Key Usage (optional)

Verify the certificate is authorized for signing:

Check Required Value
Key Usage digitalSignature, nonRepudiation

6. Qualified Certificate Statements (optional)

Verify the certificate is a qualified certificate for electronic signatures:

OID Name Required
0.4.0.1862.1.1 QcCompliance Present
0.4.0.1862.1.4 QcSSCD Present
0.4.0.1862.1.6.1 QcType (esign) Present
0.4.0.194112.1.2 QCP-n-qscd Present in policies

7. Validate signer identity

Extract signer identity from the end-entity certificate and verify it matches expected identity. See Certificate Profiles for details on the fields and extensions available.

Long-Term Validation (LTV)

The Problem

Signed documents may need validation years after signing, but:

  • End-entity certificates expire quickly (~15 minutes)
  • Intermediate/root certificates eventually expire
  • OCSP responders may become unavailable
  • CRLs may no longer be published

The Solution: PAdES-LTA

PAdES-LTA (Long-Term Archival) embeds all validation evidence at signing time:

Component Purpose
Certificate chain Proves trust path
OCSP responses / CRLs (when applicable) Proves non-revocation at signing time
Qualified timestamp Proves signing time with legal certainty

BankID eSign LTA Support

BankID Signing WYSIWYS provides two ways to create PAdES-LTA documents:

Option 1: At Signing Time

Set extendToLTA: true in padesSignProperties when creating the sign order:

{
  "padesSignProperties": {
    "extendToLTA": true
  }
}

The returned padesSignedPdf will include:

  • The qualified signature
  • Embedded certificate chain
  • Embedded revocation data
  • Qualified timestamp from BankID QTSA

This should be used when the final signer is about to sign the document.

Option 2: Post-Signing

Use the PAdES-LTA API to add LTA data to an already-signed PDF:

POST /v1/timestamp/pades/lta

This is useful when:

  • You have existing signed documents without LTA
  • You need to re-timestamp documents approaching timestamp expiry

Option 3: Self-Managed Timestamps

By calling a trusted timestamp authority (TSA) yourself, you can add timestamps to the signed document. However, you will need to manage embedding the certificate chain and revocation data yourself to achieve full LTA compliance.

Qualified Timestamps

The LTA extension includes an RFC 3161 qualified timestamp from BankID's Qualified Time Stamp Authority (QTSA). This provides legally binding proof of when the signature existed.

See Timestamp API for standalone timestamp services.

References

External: