Skip to main content

PKI and Trust Anchor

Version 0.1.0 – Draft for Consultation

Normative description of the interim national mechanism for distributing trust anchors until the European trust list infrastructure (LoTE) becomes applicable.

Overview​

The following overview displays the PKI Infrastructure of the EUDI Wallet DE Ecosystem.

overview.

Usage​

One of the main principles is the usage of self signed Root Certification Authority (Root CA) stored using an offline HSM. These RootCAs are created with an quorum and then used to created the Subordinate Certification Authorities (SubCAs) with an quorum too. Storing these SubCAs in a separate HSM is the base for the issuance and when necessary revocation of the signer certificates. Regarding ETSI TS 119 472 it is necessary to reference the trust chain but the trust root shall not be part of the reference. Thats why the SubCA has not necessarily be named as root of trust and keep the root CA completly untouched in any case, an audited PKI can remain.

Trust Lists​

It is prepared to have LoTE on EU Level available for any certified component of an EUDI Wallet Infrastructure. This will not happen to the EUDI Wallet DE Infrastructure, it is planned to certifiy these components following EU Regulation CIR 2024/2997 in postponed development.

These Trust Lists then will register the SubCAs out of this infrastructure as root of trust. The infrastructure can remain the same then.

Trust Lists are signed with offically published certifiactes / public keys to validate the integrity of the list. The list contains the informations about trusted SubCAs.

Trust List format and content​

Format: ETSI TS 119 602 v1.1.1, JSON serialization following the TS 119602 annexes.

Content: The PID Provider SubCA as trust anchor.

Security Mechanisms​

Sealing​

The Trust Lists will be signed with a qualified electronic seal (QSeal) applied by the ecosystem operator using JAdES (ETSI TS 119 182-1) as the AdES format native to the JSON serialization of TS 119 602. The seal creation device and processes follow the QTSP's requirements for qualified seals.

Publication​

The sealed trust lists become published on the ecosystem website.

  • Stable, versioned URI over HTTPS.
  • The current list is always available at a fixed URI; previous versions remain retrievable at versioned URIs for audit purposes.
  • Standard HTTP caching headers aligned with the update cadence; the endpoint is dimensioned for polling by all registered Relying Parties.
  • Alongside the list itself: the seal certificate, its fingerprint (SHA-256), and a human-readable change log.

Official Anchoring​

The trust anchoring is an official publication by the responsible government organization in the Bundesgesetzblatt, containing:

  1. the URI of the trust list distribution point,
  2. the seal signer certificates and its SHA-256 fingerprints

This official anchoring ensures an out-of-band, government-authenticated reference. The officially published signer certificate is the root of validation, and any change to it requires a new official publication. Changes to the URI or the signer certificate of the trust list follow the same channel.

Lifecycle​

ActionDescription
Update cadenceThe list is re-issued and re-sealed (a) on every content change (Sub-CA added, withdrawn, status change), and (b) periodically at most every 90 days even without content changes, so that NextUpdate proves liveness.
Emergency withdrawalOn compromise of a Sub-CA or the Provider, the affected service entry is set to withdrawn and a new list is published within 48 hours.
Rollback protection.TSLSequenceNumber is strictly increasing, verifiers must never accept a list with a lower sequence number than one already seen.
Seal certificate rotation.Planned rotation is announced in advance, the new signer certificate is officially published while the old one is still valid, and both are accepted during a defined overlap window.
Availability.The distribution point is operated with high availability, verifiers additionally mitigate outages through caching within NextUpdate.
Auditability.All published list versions are archived. The seal, the sequence numbers, and the archived versions together provide a complete, non-repudiable history of the ecosystem's trust anchors.

Certificate Lifetimes​

Signer CertificateLifetimeRevocation Information
PID Token Signermax. 6 Monthswhen required issued within max. 48 hours
PID TSL Signermax. 6 Monthswhen required issued within max. 48 hours
WIA Signermax. 6 Monthswhen required issued within max. 48 hours
WIA TSL Signermax. 6 Monthswhen required issued within max. 48 hours
KA Signermax. 6 Monthswhen required issued within max. 48 hours
KA TSL Signermax. 6 Monthswhen required issued within max. 48 hours

PKI Audit​

PKIs or their operators have to be audited following BSI TR 03189-1, when these are PKIs used by PID Provider or Wallet Provider to sign their Tokens, the PKI operators have to fulfil annually surveillance audits as well.