Schlüssel als JWKS veröffentlichen: Anleitung für Aussteller

Das Wichtigste in Kürze

Prüfstellen brauchen den öffentlichen Schlüssel des Ausstellers, üblicherweise als JWKS.
Jeder Nachweis nennt seine Schlüssel-ID, damit der richtige Schlüssel gefunden wird.
Beim Wechsel bleibt der alte Schlüssel im JWKS, bis alle damit signierten Nachweise abgelaufen sind.

Schlüsselpaar erzeugen

Erzeugen Sie ein Schlüsselpaar für ES256 (ECDSA mit P-256). Das folgende Skript für Node.js schreibt den öffentlichen Schlüssel als JWKS und den privaten Schlüssel geschützt in eine Datei:

import { generateKeyPairSync } from "node:crypto";
import { writeFileSync } from "node:fs";

const { publicKey, privateKey } = generateKeyPairSync("ec", { namedCurve: "P-256" });
const kid = "issuer-2026-10";
const jwk = { ...publicKey.export({ format: "jwk" }), kid, alg: "ES256", use: "sig" };
writeFileSync("jwks.json", JSON.stringify({ keys: [jwk] }, null, 2));
writeFileSync("private.pem", privateKey.export({ type: "pkcs8", format: "pem" }), { mode: 0o600 });

In Produktion gehört der private Schlüssel in ein Hardware-Sicherheitsmodul oder einen verwalteten Schlüsseldienst, nicht in eine Datei.

JWKS prüfen

Das erzeugte JWKS enthält nur öffentliche Angaben: Schlüsseltyp, Kurve, Koordinaten, Schlüssel-ID, Algorithmus und Verwendungszweck.

{
  "keys": [
    { "kty": "EC", "crv": "P-256", "x": "…", "y": "…", "kid": "issuer-2026-10", "alg": "ES256", "use": "sig" }
  ]
}

Achten Sie darauf, dass nie das Feld d, der private Anteil, im JWKS steht.

JWKS veröffentlichen

Stellen Sie das JWKS unter einer festen HTTPS-Adresse bereit, etwa unter /.well-known/jwks.json Ihrer Domain, und nennen Sie die Adresse in Ihren Nachweisen oder Ihrer Dokumentation. Prüfstellen laden das JWKS einmal aus dieser vertrauenswürdigen Quelle und hinterlegen es; KYA lädt Schlüssel nicht selbst aus dem Netz.

Schlüssel-ID in Nachweisen setzen

Tragen Sie die Schlüssel-ID im Header jedes signierten Nachweises als kid ein. So findet die Prüfstelle den richtigen Schlüssel, auch wenn das JWKS mehrere enthält. Eine kid, die zu keinem hinterlegten Schlüssel passt, meldet der Prüfkern mit dem Code no_key.

Schlüssel wechseln

Für einen Wechsel erzeugen Sie einen neuen Schlüssel mit neuer kid und fügen ihn dem JWKS hinzu. Signieren Sie neue Nachweise mit dem neuen Schlüssel, lassen Sie den alten aber im JWKS, bis alle damit signierten Nachweise abgelaufen sind. Ist ein Schlüssel kompromittiert, entfernen Sie ihn sofort und widerrufen betroffene Nachweise über die Statusliste.

Fehler beheben

Meldet eine Prüfstelle no_key, passt die kid im Nachweis zu keinem Schlüssel in ihrem hinterlegten JWKS; meist fehlt nach einem Wechsel der neue Schlüssel. Meldet sie signature_invalid, wurde mit einem anderen privaten Schlüssel signiert als dem, der zur kid gehört, oder der Inhalt wurde verändert. Prüfen Sie ausserdem, dass Algorithmus im Header und Schlüsseltyp zusammenpassen.

Häufige Fragen

Welcher Algorithmus ist zu empfehlen?

ES256 ist weit verbreitet und kompakt. EdDSA mit Ed25519 ist ebenfalls gut geeignet, wird aber nicht von jeder Umgebung unterstützt.

Darf ich denselben Schlüssel für Mandate und Statuslisten verwenden?

Technisch ja. Getrennte Schlüssel mit eigener kid erleichtern aber den Wechsel und begrenzen den Schaden, falls ein Schlüssel kompromittiert wird.

Wie lange sollte ein Schlüssel gültig sein?

Ein bis zwei Jahre sind üblich. Kürzere Zeiträume begrenzen das Risiko, verlangen aber häufigere Wechsel und eine gute Automatisierung.

Wie erfahren Prüfstellen von einem neuen Schlüssel?

Über das aktualisierte JWKS an derselben Adresse. Kündigen Sie Wechsel zusätzlich an, damit Prüfstellen den neuen Schlüssel rechtzeitig hinterlegen.

Muss das JWKS öffentlich erreichbar sein?

Für Prüfstellen ausserhalb Ihres Unternehmens ja. Es enthält nur öffentliche Schlüssel und darf deshalb ohne Anmeldung abrufbar sein.

Quellen

RFC 7517: JSON Web Key (JWK): https://www.rfc-editor.org/rfc/rfc7517
RFC 7518: JSON Web Algorithms (JWA): https://www.rfc-editor.org/rfc/rfc7518