verified_user Funktionsbaustein: Siegeln und Signierenfeedback

Eigenschaft	Wert
Kennung	SDO
Hauptfähigkeit	Infrastruktur und IT-Betrieb
Geschäftsfähigkeit	Sicherheitsinfrastruktur
Bausteintyp	Infrastrukturfunktion
Version	0.2 (11.05.2026)
GovStack-Bezug	E-Signature Building Block
Referenzstandards	eIDAS 2.0, X.509, W3C DID Core, W3C VC, OpenID4VCI/VP, DCP

summarize 1 Management Summaryfeedback

Dieser Funktionsbaustein stellt Funktionalitäten zum rechtssicheren Umgang mit elektronischen Signaturen, elektronischen Siegeln, (Browser-)Zertifikaten und elektronischen Zeitstempeln unter Beachtung der eIDAS-Verordnung zur Verfügung. Er baut auf der Verwaltungs-PKI (V-PKI) des BSI auf und beschreibt, wie sich die klassische X.509-Zertifikatsinfrastruktur mit dezentralen Identitätskonzepten (W3C DIDs, Self-Sovereign Identity) und der Digitalen Brieftasche (EUDI Wallet) zu einem durchgängigen Signatur- und Identitätsmanagement für Behörden und Kommunen verbinden lässt.

Kernfrage für Kommunen: Wie können alle kommunalen Kommunikationsendpunkte (Kommunen, Städte, Kreise) eine V-PKI-Anbindung für Signaturen und Siegel erhalten und gleichzeitig zukunftsfähig für eIDAS 2.0 und Dataspace-Szenarien aufgestellt sein?

description 2 Beschreibungfeedback

Der Baustein deckt den gesamten Lebenszyklus elektronischer Signaturen und Siegel ab – von der Erstellung über die Validierung bis zum Widerruf. Die V-PKI bildet dabei die kryptografische Vertrauensbasis mit einer hierarchischen CA-Struktur: Wurzel-CA → Policy-CA → Sub-CAs. Teilnehmer an der V-PKI für Sub-CAs sind u. a. Telekom, BDR D-Trust, BWI und Landesdienstleister.

In Kombination mit W3C Decentralized Identifiers (DIDs) dient das V-PKI-Zertifikat als Vertrauensanker für signaturbasierte SSI-Anwendungen. Das DID-Dokument macht die kryptografischen Schlüssel (Public Keys), die nicht direkt in einem klassischen X.509-Zertifikat stecken, für Verifiable-Credential-Signaturen verfügbar:

• id – Die eindeutige DID, die einer Behörde oder einem Funktionsträger zugeordnet ist.
• verificationMethod – Enthält den öffentlichen Schlüssel. Im V-PKI-Szenario wird dieser genutzt, um eine Signatur zu prüfen, die von einem Zertifikat der V-PKI-Root-CA beglaubigt wurde.
• service – Verweist auf Dienste der Behörde, z. B. APIs, die das Once-Only-Prinzip unterstützen.

menu_book 3 Terminologiefeedback

Die folgenden Begriffe werden in diesem Baustein verwendet.

Abkürzung	Begriff	Erklärung
V-PKI	Verwaltungs-PKI	Nationale PKI-Infrastruktur des BSI für die öffentliche Verwaltung
CA	Certificate Authority	Zertifizierungsstelle in einer PKI-Hierarchie
Sub-CA	Subordinate CA	Untergeordnete Zertifizierungsstelle (z. B. Telekom, D-Trust, BWI)
CRL	Certificate Revocation List	Sperrliste widerrufener Zertifikate
OCSP	Online Certificate Status Protocol	Echtzeit-Statusprüfung von Zertifikaten
DID	Decentralized Identifier	W3C-Standard für dezentrale, selbstverwaltete Identitäten
SSI	Self-Sovereign Identity	Konzept der selbstbestimmten Identitätsverwaltung
VC	Verifiable Credential	Kryptografisch prüfbarer digitaler Nachweis
VP	Verifiable Presentation	Prüfbare Vorlage eines oder mehrerer VCs
DCP	Decentralized Claims Protocol	Protokoll für M2M-Datenaustausch in Dataspaces (Eclipse)
ARF	Architecture Reference Framework	eIDAS-2.0-Referenzarchitektur für EUDI Wallets
SD-JWT	Selective Disclosure JWT	JWT-Format mit selektiver Attributfreigabe
WSCA	Wallet Secure Cryptographic App	Kryptografischer Sicherheitskern der EUDI Wallet
TIR	Trusted Issuer Registry	Verzeichnis vertrauenswürdiger Aussteller
TRAIN	Trust Management Infrastructure	Framework für DID-basiertes Vertrauensmanagement
QES	Qualifizierte Elektronische Signatur	Höchstes eIDAS-Signaturniveau, gleichgestellt mit handschriftlicher Unterschrift
QEAA	Qualified Electronic Attestation of Attributes	Qualifizierter elektronischer Attributnachweis
HSM	Hardware Security Module	Hardware-Sicherheitsmodul für kryptografische Operationen

settings 4 Kernfunktionalitätenfeedback

4.1 Signaturen und Siegel verwaltenfeedback

(Qualifizierte) Elektronische Signaturen, Siegel, Zertifikate und Zeitstempel können erstellt, überprüft und validiert werden (im Zusammenspiel mit dem Funktionsbaustein PKI). Zudem gibt es Mechanismen zur Aufbewahrung signierter Dokumente und Siegel.

4.2 Signaturen mit Identitäten verknüpfenfeedback

Signaturen werden mit einer Identität (natürliche/juristische Person oder Maschine) verknüpft. Über das Identity-Access-Management (SID) und V-PKI-Zertifikate wird die Zuordnung sichergestellt.

4.3 Zertifikatsgültigkeit prüfenfeedback

Bestehende Zertifikate werden auf Gültigkeit geprüft – Signaturprüfung, Ablaufdatum, Herausgeber und Zertifikatsstatus (OCSP/CRL).

4.4 Siegel an Dokumente anbringenfeedback

Elektronische Siegel können an digitale Dokumente angebracht werden, wodurch der Urheber bzw. Absender und der Dokumenteninhalt verifizierbar werden.

4.5 DID-Erstellung und V-PKI-Bindungfeedback

Behörden erstellen eine DID (z. B. did:web) auf der eigenen Domain und binden das V-PKI-Zertifikat im DID Document als Verification Method (x5c). So wird die V-PKI-Hierarchie zum Trust Anchor für die Signatur-Verifikation von Verifiable Credentials.

4.6 Verifiable-Credential-Signaturprüfungfeedback

Die kryptografische Signaturprüfung umfasst JSON-LD/JWT Verifiable Credentials mit EdDSA- oder ES256-Signaturen. Die Verifikation erfolgt über DID-Document-Auflösung → Public-Key-Prüfung → Statusprüfung (OCSP für X.509-basierte VCs, Bitstring Status List für SD-JWTs) → Schema- und Trust-Framework-Validierung (TRAIN/EBSI).

shield 5 Querschnittsanforderungenfeedback

5.1 Identitätsfindung: W3C DIDs für Behördenfeedback

Neben klassischen Ansätzen (zentrale Registries wie LDAP/AD, X.500-Verzeichnisdienste, föderale Behördendatenbanken) bieten W3C DIDs einen dezentralen Ansatz für die Signaturbindung:

Aspekt	Klassisch	W3C DID
Identitätsvergabe	Zentral (LDAP, AD)	Dezentral, selbstverwaltet
Vertrauensanker	Zentrale CA	DNS (did:web) oder Blockchain
Zentraler Betreiber	Erforderlich	Nicht nötig – Register-Governance schafft Vertrauen
eIDAS-2.0-Konformität	Bedingt	Nativ kompatibel
Skalierbarkeit für Kommunen	Begrenzt	Beliebig skalierbar

Verfügbare DID-Methoden: did:web, did:ebsi, did:ion, did:key.

Empfehlung

did:web + TRAIN-Framework als pragmatischer Einstieg für kommunale Signaturen und Siegel – DNS dient als Vertrauensanker und ist sofort nutzbar ohne Blockchain-Abhängigkeit.

5.2 SSI-Kernprinzipienfeedback

Self-Sovereign Identity (SSI) adressiert zentrale Probleme klassischer Signatur- und Identitätssysteme (Single Point of Failure, Tracking-Risiken, Vendor Lock-In):

• Existenz und Kontrolle durch den Inhaber
• Transparenz und Persistenz der Identität
• Portabilität und globale Interoperabilität
• Zustimmungspflicht und Datensparsamkeit (DSGVO-konform by design)
• Schutz der Rechte der Identitätsinhaber

5.3 eIDAS-2.0-Regulierungfeedback

Die eIDAS-2.0-Verordnung schafft den europäischen Rechtsrahmen für elektronische Signaturen, Siegel und digitale Identitäten und ist seit 2024 in Kraft:

Meilenstein	Jahr
Kommissionsvorschlag	2021
Wallet-Piloten	2022
Inkrafttreten	2024
Nationale Umsetzung	2026
Vollbetrieb	2027+

Kernanforderungen:

• Jede EU-Bürgerin / jeder EU-Bürger erhält Anspruch auf eine EUDI Wallet – in Deutschland gefördert durch SPRIND (Prototypen: Ubique, wwWallet, Animo)
• Akzeptanzpflicht durch öffentliche und private Stellen
• Qualified Electronic Attestations (QEAAs) – qualifizierte elektronische Attributnachweise
• Interoperabilität zwischen allen Mitgliedstaaten
• Datenschutz by design: Selective Disclosure

Das Architecture Reference Framework (ARF) definiert die Protokolle: OpenID4VCI (Credential Issuance), OpenID4VP (Presentation), SD-JWT VC Format, ISO 18013-5 (mdoc/mDL), W3C DID Core und Bitstring Status List.

checklist 6 Funktionale Anforderungenfeedback

6.1 Business Wallets vs. Personal Walletsfeedback

Signaturen und Siegel werden je nach Wallet-Typ unterschiedlich gehandhabt. Die Details zur Wallet-Architektur sind im Baustein Digitale Brieftasche beschrieben.

Kriterium	Personal Wallet	Business Wallet
Inhaber	Natürliche Person	Juristische Person (Behörde, Unternehmen)
Credentials	Ausweis, Führerschein, Qualifikationen	Handelsregister, Bundesanzeiger, Zertifikate, Behördenstatus
Signaturfunktion	Qualifizierte elektronische Signatur (QES)	Elektronisches Siegel (organisational)
Kontrolle	Individuell (SSI)	Organisational, rollenbasiert
Use Cases	Bürgerservices, Behördengänge, Login	B2B-Datenaustausch, Dataspace-Teilnahme
Wallet-Typ	Mobile App (EUDI Wallet App)	Server-Side / Cloud Wallet (API-gesteuert)
Standards	ISO 18013-5, W3C VC, SD-JWT	W3C DID, EBSI VC, DCP (Eclipse Dataspace)
Sicherheit	WSCA (Wallet Secure Cryptographic App)	V-PKI-Zertifikate im DID Document (x5c)

Digitale Brieftasche

Der Funktionsbaustein Digitale Brieftasche (DBT) beschreibt die EUDI Wallet als eigenständigen Identitätsträger mit Credential-Verwaltung, Presentation-Flows und Offline-Fähigkeit im Detail. Die V-PKI liefert über Siegeln und Signieren die kryptografische Vertrauensbasis, auf der die Wallet-Credentials aufbauen – insbesondere für Business Wallets, deren Organisationsidentität über V-PKI-Zertifikate im DID Document (x5c) verankert wird.

6.2 Verifikationsmechanismenfeedback

Die Verifikation erfolgt in vier Stufen:

1. Kryptografische Signaturprüfung – JSON-LD/JWT Verifiable Credentials, EdDSA/ES256-Signaturen, DID Document → Public-Key-Auflösung
2. Statusprüfung – Revocation via Bitstring Status List, OCSP für X.509-basierte VCs, W3C StatusList2021
3. Schema- und Trust-Framework-Validierung – Credential-Schema-Validierung, TRAIN/EBSI Trust Framework, Trusted Issuer Registry (TIR)
4. Presentation Exchange – Presentation Definition (DIF PE), Selective Disclosure (SD-JWT), Zero-Knowledge Proofs (optional)

database 7 Datenstrukturenfeedback

7.1 DID-Dokument mit V-PKI-Bindungfeedback

Ein DID-Dokument für eine Behörde mit V-PKI-Zertifikatsbindung für Signaturen und Siegel enthält die folgenden Kernelemente:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:behoerde.bund.de:amt:berlin",
  "verificationMethod": [{
    "id": "did:web:behoerde.bund.de:amt:berlin#key-1",
    "type": "JsonWebKey2020",
    "controller": "did:web:behoerde.bund.de:amt:berlin",
    "publicKeyJwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." },
    "x5c": ["MIIBxTCCAWugAwIBAgI..."]
  }],
  "service": [{
    "id": "did:web:behoerde.bund.de:amt:berlin#api",
    "type": "OnceOnlyService",
    "serviceEndpoint": "https://behoerde.bund.de/api/v1/noots"
  }]
}

7.2 Verifiable Credential (V-PKI-signiert)feedback

Feld	Beschreibung
issuer	DID des Ausstellers (z. B. Registrierungsbehörde)
credentialSubject	Identitätsdaten der Behörde / des Amts
proof	V-PKI-basierte Signatur (EdDSA/ES256 mit x5c-Verweis)
credentialStatus	Bitstring Status List URL für Widerrufsprüfung

api 8 Service-Schnittstellenfeedback

8.1 Vergleich: Zentrale Registries vs. dezentrale Identitätenfeedback

Der Baustein muss mit beiden Paradigmen interoperieren – dem zentralen Registerpfad (NOOTS/SIMPL) und dezentralen DID-basierten Ansätzen:

Kriterium	NOOTS / SIMPL (AS4)	eIDAS 2.0 (W3C DIDs / SSI)
Architektur	Zentral (Hub & Spoke)	Peer-to-Peer
Registry-Typ	AS4-konforme zentrale Registry (föderiert)	DID Registry: DNS, Web, Blockchain
Identitätskontrolle	Registry-Betreiber	Identitätsinhaber (Self-Sovereign)
Vertrauen	Zentrale CA / Registry-Betreiber	Trust Framework + DID Document
Interoperabilität	AS4/ebMS3, PEPPOL-kompatibel	W3C Standard – globale Interop.
Skalierung	Föderiert, begrenzte Flexibilität	Beliebig skalierbar, technologieoffen
eIDAS-2.0-Kompatibilität	Teilweise – AS4 bleibt Transportprotokoll	Sehr gut – EUDI Wallet kompatibel

NOOTS und DIDs sind komplementäre, nicht konkurrierende Ansätze: NOOTS stellt den Transportweg für den Registerdatenabruf bereit, während DIDs die Identitäts- und Signaturschicht für die beteiligten Akteure bilden.

8.2 DCP – Machine-to-Machine Authenticationfeedback

Das Decentralized Claims Protocol (DCP, Eclipse Dataspace) adressiert Machine-to-Machine-Datenaustausch zwischen Organisationen mit signaturbasierter Verifikation, während OpenID4VP User-Facing Flows abdeckt. Beide Dataspace-Connectoren können sich gegenseitig via SSI verifizieren.

Protokollstack: OpenID4VCI · OpenID4VP · DCP (M2M) · SIOP v2

V-PKI-Zertifikate sichern den Transportkanal (X.509 / TLS) über Internet und Verwaltungsnetz (IXP/MPLS Peering), während DID-basierte Verifiable Presentations die Identität der Teilnehmer auf Anwendungsebene signaturbasiert nachweisen.

account_tree 9 Interne Workflowsfeedback

Der Baustein Siegeln und Signieren interagiert mit mehreren Funktionsbausteinen des Deutschland-Stacks:

• PKI (SPK): Stellt die V-PKI-Zertifikate bereit, auf denen Signaturen und Siegel basieren.
• Identity-Access-Management (SID): Signaturen werden mit Identitäten verknüpft (X.509, SAML, OIDC).
• Digitale Brieftasche (DBT): V-PKI-signierte Verifiable Credentials werden in Business Wallets gespeichert; Organisationsidentität über x5c im DID Document verankert.
• Nachweisdatenabruf (NDA): Signierte Nachweise fließen über NOOTS und OOTS.
• Authentifizierung: eID-Integration und Wallet-basierte Authentifizierung über OpenID4VP.

library_books 10 Weiterführende Informationen und Quellenfeedback

10.1 Nächste Schrittefeedback

Nr.	Maßnahme
1	did:web als pragmatischen DID-Ansatz für kommunale Signaturen und Siegel evaluieren (DNS als Vertrauensanker)
2	V-PKI als Trust Anchor in DID Documents einbinden (x5c Verification Method)
3	NOOTS/SIMPL (AS4) und DIDs als komplementäre Ansätze betrachten
4	Business Wallets für kommunale Identitäten pilotieren (Bundesanzeiger, SCC 2026)
5	eIDAS-2.0-ARF als regulatorischen Rahmen für alle Wallet- und Signaturentscheidungen nutzen
6	DCP-Protokolle für M2M-Signaturverifikation im Dataspace-Kontext implementieren

10.2 Normative Quellenfeedback

• BSI – Verwaltungs-PKI (V-PKI)
• W3C Decentralized Identifiers (DIDs) v1.0
• W3C Verifiable Credentials Data Model v2.0
• eIDAS 2.0 – Verordnung (EU) 2024/1183
• eIDAS 2.0 Architecture Reference Framework (ARF)
• Eclipse Dataspace – Decentralized Claims Protocol (DCP)
• GIB Dienstelandkarte – Siegeln und Signieren
• GovStack E-Signature Building Block

format_list_numbered 11 Verzeichnissefeedback

Abkürzung	Bedeutung
ARF	Architecture Reference Framework
CA	Certificate Authority
CRL	Certificate Revocation List
DCP	Decentralized Claims Protocol
DID	Decentralized Identifier
EBSI	European Blockchain Services Infrastructure
EUDI	European Digital Identity
HSM	Hardware Security Module
IAM	Identity and Access Management
mDL	Mobile Driving Licence
NOOTS	National Once Only Technical System
OCSP	Online Certificate Status Protocol
OOTS	Once Only Technical System (EU)
PEPPOL	Pan-European Public Procurement OnLine
QEAA	Qualified Electronic Attestation of Attributes
QES	Qualifizierte Elektronische Signatur
SD-JWT	Selective Disclosure JSON Web Token
SIMPL	Smart Middleware Platform
SSI	Self-Sovereign Identity
TIR	Trusted Issuer Registry
TRAIN	Trust Management Infrastructure
V-PKI	Verwaltungs-PKI
VC	Verifiable Credential
VP	Verifiable Presentation
WSCA	Wallet Secure Cryptographic Application