Das Veil-Protokoll

Was ein Veil-Zertifikat ist

Für jede Inferenzanfrage, die durch das Gateway läuft, erzeugt das Protokoll einen signierten Umschlag, der Folgendes enthält: einen fail-closed Gateway-Claim, Best-Effort-Claims der vier nachgelagerten Pipeline-Dienste (dsa-bridge, dsa-sanitizer, dsa-ai, dsa-audit), das Witness-Urteil über fünf Konsistenzprüfungen, ein RFC-3161-Zeitstempel-Token und — auf einem asynchronen Best-Effort-Retry-Pfad — einen Verweis auf einen Sigstore-Rekor-Eintrag.

Das Zertifikat ist über drei Gateway-Endpunkte abrufbar, einen je Ansicht: /api/v1/veil/certificate/{request_id} (vollständiger Umschlag, technischer Nachweis), /api/v1/veil/certificate/{request_id}/summary (DPO-Zusammenfassung) und /api/v1/veil/certificate/{request_id}/regulatory (regulatorische Zuordnung). Es ist keine Zugangsberechtigung und keine Lizenz. Es ist eine Attestierung über eine konkrete Anfrage, unabhängig gegen externe Vertrauensanker verifizierbar.

Umfang der Attestierung

Bezeugt:

• +Das Gateway hat einen Ed25519-signierten Veil-Claim auf Request-Ebene protokolliert.
• +Der Witness hat seine fünf Konsistenzprüfungen gegen das Claim-Set ausgeführt.
• +Der Umschlag wurde seit der Witness-Signierung nicht verändert.
• +Wenn anchor_status == ANCHORED: Der Umschlag existierte nicht später als der RFC-3161-Zeitstempel, und der Umschlag-Hash erscheint im Sigstore-Rekor-Transparenzprotokoll.

Bezeugt nicht:

• −Was die KI ausgegeben hat — das ist Aufgabe der Evidenzschicht.
• −Die rechtliche Korrektheit Ihres Anwendungsfalls.
• −Die Fehlerfreiheit Ihres eigenen Anwendungscodes nach dem Gateway.

Die fünf Konsistenzprüfungen

Ein Veil-Zertifikat trägt zwei Label-Achsen, die der Witness unabhängig voneinander berechnet:

• completenessFULL, wenn alle vier erwarteten nachgelagerten Dienste (dsa-bridge, dsa-sanitizer, dsa-ai, dsa-audit) einen Claim emittiert haben; PARTIAL, wenn einer fehlt. Der Gateway-Claim selbst wird durch eine separate fail-closed-Invariante am Edge garantiert — kann das Gateway ihn nicht protokollieren, wird die Anfrage abgewiesen, bevor überhaupt ein Zertifikat entsteht.
• overall_verdictDas kombinierte Urteil des Witness über alle Prüfungen: VERIFIED, wenn alles auf einem FULL-Claim-Set passt; PARTIAL, wenn Signaturen, Datensichtbarkeit und Isolationsprüfung alle passen, aber entweder die Vollständigkeit PARTIAL ist oder eine zeitliche Prüfung fehlschlägt; FAILED, wenn Signaturen ungültig sind, die Datensichtbarkeit verletzt ist oder die Isolationsprüfung nicht VERIFIED ist. FAILED-Zertifikate werden persistiert und mit diesem Urteil ausgeliefert — sie werden nicht unterschlagen.

Die fünf Prüfungen, die der Witness ausführt, in der Reihenfolge des Codes:

1. 1

   Signaturgültigkeit

   Jede Ed25519-Signatur eines Claims muss gegen den veröffentlichten öffentlichen Schlüssel des Dienstes verifizieren. Zusätzlich werden die typisierten Proto-Felder des Dienstes (IsolationProbe, QiScore, ModelUsedusw.) mit dem signierten kanonischen Payload abgeglichen — eine Abweichung bedeutet, dass die äußeren Felder nach der Signierung manipuliert wurden. Jede Abweichung ist fatal → FAILED.

2. 2

   Claim-Vollständigkeit

   Alle vier erwarteten nachgelagerten Dienste müssen vorhanden sein, um completeness = FULL zu erhalten; sonst PARTIAL, mit Auflistung der fehlenden Dienste. Unvollständigkeit allein degradiert overall_verdict nur auf PARTIAL — außer der fehlende Dienst ist dsa-ai, dann hat die Isolationsprüfung keinen Claim zum Konsumieren und overall_verdict fällt auf FAILED.

3. 3

   Zeitliche Konsistenz

   Die Zeitstempel der Claims müssen innerhalb eines 120-Sekunden-Fensters liegen und in der erwarteten Pipeline-Reihenfolge eintreffen (dsa-bridge → dsa-sanitizer → dsa-ai → dsa-audit). Fällt eine dieser Teilprüfungen, degradiert overall_verdict auf PARTIAL.

4. 4

   Datensichtbarkeit

   Sandbox B (dsa-ai) darf nicht behaupten, PII-Feldnamen aus der fest eingebauten Musterliste gesehen zu haben (customer_id, email, name, first_name, last_name, phone, address, ssn, dob, date_of_birth, identity_id). Eine Verletzung ist fatal → FAILED.

5. 5

   Isolationsprüfung

   Der Claim von Sandbox B trägt einen IsolationProbe-Status. Nur VERIFIED besteht die Prüfung; BREACHED, LOCKED und UNKNOWN schlagen fehl → FAILED.

Der Signierprozess

Jedes Zertifikat wird durch eine vierstufige Pipeline erzeugt. Die ersten beiden Stufen laufen synchron auf dem Inferenzpfad; die externe Verankerungsstufe läuft asynchron nach der Witness-Signierung. Jede Stufe ist unabhängig verifizierbar.

1. 1

   Pro-Dienst-Ed25519-Claim

   Jeder Pipeline-Dienst besitzt ein eigenes Ed25519-Schlüsselpaar. Beim Verarbeiten einer Anfrage emittiert er einen Claim: seine Dienst-ID, die Request-ID, eine strukturierte Zusammenfassung der gesehenen Daten und seinen Zeitstempel. Er signiert den Claim mit seinem privaten Schlüssel und erzeugt einen kanonischen Payload, der an die typisierten Proto-Felder gebunden ist. Schlüssel werden über den Secret Manager des Deployments verwaltet (HashiCorp Vault, AWS KMS oder Azure Key Vault).

2. 2

   Witness-Verifizierung und Umschlagsignatur

   Der Witness sammelt die während der Anfrage emittierten Claims, führt die fünf Konsistenzprüfungen aus und setzt den Zertifikats-Umschlag zusammen: alle Claims, die Verdiktachsen (completeness, overall_verdict), die Liste fehlender Dienste (falls vorhanden) und die signierende Schlüssel-ID. Der Umschlag wird mit dem Ed25519-Schlüssel des Witness signiert; diese Signatur ist der primäre Vertrauensanker des Zertifikats.

3. 3

   Externe Verankerung (RFC-3161-TSA + Sigstore Rekor, asynchron, Best-Effort)

   Nachdem der Witness den Umschlag signiert hat, übermittelt ein Attestor einen Hash des Zertifikats an zwei externe Dienste. Das Eingabe-Artefakt ist für beide Anker dieselbe Protobuf-Binary-Serialisierung des VeilCertificate-Protos zum Zeitpunkt der Witness-Signierung — bevor der Attestor drei bestimmte Felder befüllt: attestation.timestamp, attestation.transparency_log und das oberste Feld anchor_status. Zu beachten: attestation.notaryverhält sich anders — der Assembler befüllt es zum Signierzeitpunkt mit der kanonisch-JSON-Signatur des Witness als wiederholte Metadaten, es gehört also zu den gehashten Bytes. Ein Verifier, der den Hash rekonstruiert, muss daher genau diese drei Felder (attestation.timestamp, attestation.transparency_log, anchor_status) am abgerufenen Zertifikat vor proto.Marshal zurücksetzen und attestation.notary beibehalten. Der Attestor schickt diesen Hash an eine externe Zeitstempelstelle gemäß RFC 3161 (die ein signiertes Zeitstempel-Token liefert und damit belegt, dass der Umschlag nicht später als das genTime des Tokens existierte) als auch an Sigstore Rekor als hashedrekord-Eintrag. Beide Einreichungen laufen auf demselben asynchronen Retry-Pfad; das Ergebnis wird als anchor_status ausgewiesen: PENDING_ANCHOR, solange Retries laufen, ANCHORED, wenn auf dem persistierten Zertifikat sowohl das TSA-Token als auch ein Rekor-Inklusionsbeweis gesetzt sind, und ANCHOR_FAILED, wenn das Retry-Fenster ohne vollständige Bestätigung abläuft. Ein Zertifikat mit ANCHOR_FAILED bleibt gegen seine Witness-Ed25519-Signatur gültig; nur die externen öffentlichen Anker haben nicht bestätigt.

4. 4

   Schlüssel-Lebenszyklus

   Pro-Dienst-Ed25519-Schlüssel rotieren nach einem vom Betreiber konfigurierbaren Zeitplan. Claims halten keine key_id fest; das VeilClaim-Proto trägt nur die service_id des signierenden Dienstes und seine signature. Ein Verifier schlägt den aktuellen öffentlichen Schlüssel des Dienstes über die service_id im unten beschriebenen Schlüsselmanifest nach. Der Zertifikats-Umschlag protokolliert separat die witness_key_id — diese Kennung gilt ausschließlich für die Witness-Umschlagsignatur. Die Rotation erfolgt je Dienst unabhängig, sodass ein Schlüsselkompromiss eingegrenzt bleibt. Da Claims keine konkrete Schlüsselversion festhalten, verlässt sich ein:e Prüfer:in bei einem historischen Zertifikat darauf, dass das Manifest den zum Claim-Zeitstempel gültigen öffentlichen Schlüssel weiterhin veröffentlicht (oder dass der Betreiber historische Schlüssel nach einer Rotation beibehält). Betreiber, die Schlüssel rotieren, müssen ein Manifest ausliefern, das den historischen öffentlichen Schlüssel neben dem aktuellen veröffentlicht; andernfalls werden Zertifikate, die unter dem stillgelegten Schlüssel signiert wurden, unverifizierbar. Betreiber, die historische Schlüssel nicht vorhalten können, sollten Zertifikate unter dem alten Schlüssel vor der Rotation aus den Verifikationspfaden herausnehmen.
   
   Der Gateway veröffentlicht das Schlüsselmanifest unter GET /.well-known/veil-keys.json— öffentlich, ohne Authentifizierung. Das Manifest liefert { issuer, version, supported_protocol_versions, keys[], signed_at }, wobei jeder Eintrag in keys[] die Form { service_id, key_id, public_key, purpose, algorithm: "Ed25519" } hat. Ist der Gateway mit einem Manifest-Signaturschlüssel konfiguriert (VEIL_MANIFEST_SIGNING_KEY-Env-Var), wird das Manifest Ed25519-signiert über seine kanonische JSON-Form und trägt zusätzlich signature, signing_key_id und signing_algorithm. Fehlt diese Env-Var, wird das Manifest unsigniert ausgeliefert — Konsumenten, die Manifest-Integrität benötigen, sollten einen signierten Spiegel (typischerweise im DPA-Anhang) pinnen und vor Vertrauen abgleichen.

Die drei Ansichten

Jedes Zertifikat ist in drei Ansichten abrufbar. Der zugrundeliegende signierte Umschlag ist identisch; die Ansichten unterscheiden sich nur in dem, was sie rendern. Jede Ansicht ist ein deterministisches Rendering desselben kanonischen JSON — das Rendering selbst ist gegen den signierten Umschlag verifizierbar.

So verifizieren Sie ein Veil-Zertifikat unabhängig

Ein Veil-Zertifikat ist so entworfen, dass die Verifizierung eines bereits erhaltenen Zertifikats kein Vertrauen in unseren Code verlangt. Der Abruf des Zertifikats erfordert hingegen einen authentifizierten Aufruf gegen den tier-gated Endpunkt /api/v1/veil/certificate/{request_id} (x-api-key, Pro- oder Enterprise-Tarif) — das ist unser Transport. Ist das Zertifikat einmal abgerufen, lässt es sich Ende-zu-Ende gegen öffentliche Standards (Ed25519, RFC 3161, Sigstore Rekor) und gegen die Schlüssel, die wir unter /.well-known/veil-keys.json (ohne Authentifizierung) veröffentlichen, verifizieren. Zwei Wege existieren: ein bequemer Pfad über das TypeScript-SDK und ein protokollagnostischer Pfad mit Standardwerkzeugen. Ehrliche Lage: Zertifikats-Abruf und Witness-Signatur-Verifizierung funktionieren heute Ende-zu-Ende; die vollständige Mehr-Claim-Verifizierung über eine unabhängige Go-Oracle ist auf der Roadmap. Wo die aktuelle Toolchain noch nicht vollständig ist, sagen wir es.

Bequemer Pfad (TypeScript-SDK)

Das @dsaveil/theveil-SDK liefert einen Zertifikats-Abruf und einen Helfer zur Witness-Signatur-Verifizierung. Der Verifier vertraut dem Zertifikat nicht, sich selbst als Unterzeichner auszuweisen — die Aufruferin liefert den erwarteten Witness-Schlüssel out-of-band.

import { TheVeil, TheVeilCertificateError, TheVeilHttpError } from "@dsaveil/theveil";

const client = new TheVeil({ apiKey: process.env.VEIL_API_KEY });

// 1) Abruf. Ein noch nicht assembliertes Zertifikat erscheint als
//    202-HTTP-Fehler, damit der Happy-Path eng typisiert bleibt.
let cert;
try {
  cert = await client.getCertificate("req_4f3a1b2c8d9e");
} catch (err) {
  if (err instanceof TheVeilHttpError && err.status === 202) {
    // Retry nach err.body.retry_after_seconds
  }
  throw err;
}

// 2) Witness-Ed25519-Signatur über die kanonischen 7 Felder prüfen.
//    Wirft bei Fehlschlag TheVeilCertificateError — kein Boolean-Return.
try {
  const result = await client.verifyCertificate(cert, {
    witnessKeyId:     "witness_v1",                     // erwartetes Label
    witnessPublicKey: process.env.VEIL_WITNESS_PUBKEY!, // base64 oder Uint8Array (32 Byte)
  });
  // result.overallVerdict — VERDICT_UNSPECIFIED | VERDICT_VERIFIED | VERDICT_PARTIAL | VERDICT_FAILED
  // result.anchorStatus   — ANCHOR_STATUS_UNSPECIFIED | ANCHOR_STATUS_PENDING | ANCHOR_STATUS_ANCHORED | ANCHOR_STATUS_FAILED
  // result.witnessAssertedIssuedAt — Date (Millisekunden-Präzision)
  if (result.overallVerdict === "VERDICT_VERIFIED") {
    // Alle fünf Witness-Prüfungen erfolgreich, vollständiges Claim-Set
  }
} catch (err) {
  if (err instanceof TheVeilCertificateError) {
    // err.reason ist einer von:
    //   malformed | unsupported_protocol_version | witness_mismatch
    //   witness_signature_missing | invalid_signature
  }
  throw err;
}

verifyCertificate führt heute vier Prüfungen durch: Protokollversion (protocol_version === 2), Witness-Identität (cert.witness_key_id stimmt mit dem vom Aufrufer erwarteten Label überein), Signatur-Vorhandensein und Ed25519-Verifikation über den kanonischen 7-Feld-Ausschnitt. Die externe RFC-3161-Zeitstempel-Verifikation und die Rekor-Inklusionsbeweis-Verifikation werden heute nicht im SDK durchgeführt — anchorStatus und overallVerdict sind im Ergebnis Durchreich-Metadaten. Die vollständige Mehr-Claim-Verifizierung (jede Pro-Dienst-Signatur, die TSA-Token-Kette, der Rekor-Inklusionsbeweis) ist der Roadmap-Schritt; sobald ausgeliefert, läuft sie ohne zusätzliche Konfiguration im SDK.

Hinweis zu den Enum-Formen. Ihr Code vergleicht gegen die oben gezeigten protojson-Full-Name-Literale: VERDICT_VERIFIED, VERDICT_PARTIAL, VERDICT_FAILED, ANCHOR_STATUS_ANCHORED usw. Genau diese Werte liefert das SDK, weil der Gateway das Zertifikat als protojson mit UseProtoNames: trueausliefert. An anderen Stellen dieser Seite schreiben wir die kürzeren Formen — VERIFIED, PARTIAL, ANCHORED—, wenn wir das Protokollverhalten erläutern, weil genau diese Strings der Go-Witness intern verwendet und kanonisch signiert. Gleiche Werte, zwei Kodierungen. In Ihrem Code vergleichen Sie immer gegen die Full-Name-Form.

Protokollagnostischer Pfad (Standardwerkzeuge)

Fünf explizite Schritte. Keine DSA-spezifischen Abhängigkeiten.

1. 1

   Umschlag abrufen

   curl die Zertifikats-URL aus dem Feld veil.certificate_url der Inferenz-Antwort oder direkt den Endpunkt /api/v1/veil/certificate/{request_id} (authentifiziert: x-api-key-Header, Pro- oder Enterprise-Tarif). Der Antwort-Body ist protojson-Ausgabe des VeilCertificate-Proto — JSON mit der protojson-Konvention, dass Enum-Felder Full-Name-String-Werte tragen (z. B. anchor_status.status = ANCHOR_STATUS_ANCHORED, verification.overall_verdict = VERDICT_VERIFIED) und ungesetzte Felder mit Zero-Values serialisiert werden. Für die Anzeige als JSON parsen, für Signatur- und Hash-Rekonstruktion anschließend nach dem Proto-Schema unter proto/veil/v1/veil.proto (im öffentlichen DSA-Repo) in Protobuf-Binary re-enkodieren.

2. 2

   Witness-Umschlagsignatur prüfen

   Extrahieren Sie den Umschlagrumpf und dessen Ed25519-Signatur. Beziehen Sie den öffentlichen Witness-Schlüssel aus dem Schlüsselmanifest des Gateways: GET /.well-known/veil-keys.json (öffentlich, ohne Authentifizierung). Suchen Sie den Eintrag mit service_id == "dsa-witness", dessen key_id der witness_key_id des Zertifikats entspricht (das Manifest liefert heute witness_v1 für diese Rolle). Ist der Gateway mit einem Manifest-Signaturschlüssel konfiguriert, prüfen Sie zuerst die eigene Ed25519-Signatur des Manifests; andernfalls pinnen und vergleichen Sie einen signierten Spiegel aus dem DPA-Anhang des Betreibers, bevor Sie dem Manifest vertrauen. Der signierte Payload ist der kanonische 7-Feld-Ausschnitt des Zertifikats (certificate_id, request_id, protocol_version, claim_ids in Reihenfolge, issued_at, overall_verdict in der Witness-Short-Form (VERIFIED / PARTIAL / FAILED) und witness_key_id) — die exakte Kanonisierung liefert der Witness-Assembler. Verifizieren mit einer beliebigen Ed25519-Bibliothek (RFC 8032) — openssl pkeyutl -verify, ein PyNaCl-Aufruf oder Äquivalent.

3. 3

   Pro-Dienst-Claim-Signaturen prüfen

   Der Umschlag enthält einen Claim je Pipeline-Dienst, der einen emittiert hat. Wiederholen Sie für jeden Claim Schritt 2 gegen den veröffentlichten Schlüssel des Dienstes — nachgeschlagen über die service_id des Claims im selben Manifest unter /.well-known/veil-keys.json (heute ein aktueller key_id je service_id). Das VeilClaim-Proto trägt kein key_id-Feld: Claims exponieren nur service_id und signature, die Rotations-Logik lebt daher im Manifest (siehe den Schlüssel-Lebenszyklus-Unterabschnitt in Abschnitt 3). Fehlende Best-Effort-Claims unter dsa-bridge/dsa-sanitizer/dsa-ai/dsa-audit sind bei PARTIAL-Zertifikaten normal; ein fehlender Gateway-Claim ist nicht möglich (die Anfrage wäre abgewiesen worden).

4. 4

   RFC-3161-Zeitstempel-Token prüfen (nur bei anchor_status == ANCHORED)

   Bei anchor_status == ANCHORED trägt das Feld attestation.timestamp das TSA-Token (Rohbytes unter attestation.timestamp.timestamp_token). Verifizieren Sie die Signatur des Tokens gegen die veröffentlichte CA-Kette der TSA und prüfen Sie, dass messageImprint.hashedMessage des Tokens gleich SHA-256(proto.Marshal(cert)) ist, wobei cert das abgerufene VeilCertificate ist, bei dem drei Felder auf ihren ungesetzten Zustand zurückgesetzt wurden: attestation.timestamp, attestation.transparency_log und das oberste Feld anchor_status. attestation.notarybleibt erhalten — es wurde zum Signierzeitpunkt befüllt und gehört zu den gehashten Bytes (ein Leeren erzeugt eine Hash-Abweichung bei einem legitimen Zertifikat). Der Wert von messageImprint.hashAlgorithm muss id-sha256 sein (OID 2.16.840.1.101.3.4.2.1). Werkzeuge: openssl ts -verify, dessen -data-Argument auf die rekonstruierten Bytes zeigt, oder eine beliebige TSP-Bibliothek. Bei PENDING_ANCHOR oder ANCHOR_FAILEDentfällt dieser Schritt — das Feld attestation.timestamp kann fehlen oder unvollständig sein; das Zertifikat bleibt gegen die Witness-Ed25519-Signatur gültig, aber die externe Zeitstempel-Verankerung hat nicht bestätigt.

5. 5

   Rekor-Eintrag prüfen (nur bei anchor_status == ANCHORED)

   Bei anchor_status == ANCHORED enthält das Feld attestation.transparency_log den Rekor-Eintrag: log_index (int64), inclusion_proof (Bytes), signed_entry_timestamp (Bytes) und log_url (der Rekor-Endpunkt, der den Beweis ausgestellt hat). Holen Sie den Eintrag über die Rekor-REST-API oder rekor-cli. Der Eintrag ist ein hashedrekord mit data.hash.algorithm == "sha512" — bestätigen Sie, dass data.hash.value gleich hex(SHA-512(proto.Marshal(cert))) ist, wobei cert das abgerufene VeilCertificate ist, bei dem drei Felder auf ihren ungesetzten Zustand zurückgesetzt wurden: attestation.timestamp, attestation.transparency_log und das oberste Feld anchor_status. attestation.notarybleibt erhalten — es wurde zum Signierzeitpunkt befüllt und gehört zu den gehashten Bytes (ein Leeren erzeugt eine Hash-Abweichung bei einem legitimen Zertifikat). Beachten Sie: Die Signatur des Eintrags ist Ed25519ph(Pre-Hash; RFC 8032 §5.1), also nichtdieselbe Konstruktion wie die Witness-Umschlagsignatur — Rekor verifiziert sie intern gegen den öffentlichen Schlüssel, der im Eintragsfeld spec.signature.publicKey.content eingebettet ist (PEM-umhüllter X.509-SPKI des öffentlichen Witness-Schlüssels). Bei PENDING_ANCHOR oder ANCHOR_FAILEDentfällt dieser Schritt — das Transparenz-Log-Feld kann fehlen oder unvollständig sein.

   # log_index ist ein Feld von attestation.transparency_log im abgerufenen Cert.
   rekor-cli get --log-index <attestation.transparency_log.log_index>

Die fünf Schritte oben sind eine vollständige manuelle Verifizierung gegen das Protokoll. Sie erfordern weder Vertrauen in unsere Infrastruktur noch in unseren Code — jedes Artefakt wird gegen öffentliche Standards (Ed25519, RFC 3161, Sigstore Rekor) oder gegen Schlüssel geprüft, die wir unter /.well-known/veil-keys.json (oder gepinnten signierten Spiegeln davon) veröffentlichen.

Regulatorische Zuordnung

Das Veil-Protokoll ist ein Mechanismus, mit dem ein Verantwortlicher bestimmte Artikel der DSGVO und der KI-VO erfüllen kann. Es handelt sich um Nachweis- und Architekturzuordnungen — keine gehaltene Zertifizierung unter einer der beiden Verordnungen.

Was das Protokoll nicht leistet

Das Veil-Protokoll beweist, dass die Isolation für eine bestimmte Anfrage stattgefunden hat. Es beweist nicht — für sich allein —, dass die Ausgabe der KI korrekt war, dass Ihre Anwendung die Ausgabe sicher interpretiert hat oder dass Ihre eigenen Systeme hinter dem Gateway gleichermaßen isoliert sind. Infrastruktur-Durchsetzung (Kubernetes NetworkPolicies, Docker-Netzwerksegmentierung) ist das, was die Isolation erzwingt; das Protokoll ist das, was sie beweist. Keines ersetzt das andere.

FAQ

Was passiert, wenn anchor_status dauerhaft auf PENDING_ANCHOR bleibt?

PENDING_ANCHOR bedeutet, dass die asynchrone Retry-Schleife noch nicht beide externen Attestierungen (den RFC-3161-TSA-Zeitstempel und den Sigstore-Rekor-Inklusionsbeweis) auf dem persistierten Zertifikat gesetzt hat. Die Witness-Ed25519-Signatur über den Umschlag wird synchron erzeugt und ist bereits gültig; beide externen Anker sind der asynchrone Teil und genau das, worauf PENDING_ANCHOR wartet. Wechselt der Status nicht innerhalb des Retry-Fensters auf ANCHORED, wird er auf ANCHOR_FAILED gesetzt; Prüfer:innen, die für ein bestimmtes Zertifikat einen Transparenz-Log-Anker benötigen, können den Abruf wiederholen oder einen erneuten Lauf anfordern. Ein länger andauerndes PENDING_ANCHORjenseits des konfigurierten Fensters ist ein operationelles Signal, dass der Attestor-Dienst die externen TSA- oder Rekor-Endpunkte nicht erreicht — prüfen Sie die Attestor-Logs und Retry-Metriken des Deployments.

Wie verifiziere ich ein Zertifikat, nachdem mein API-Schlüssel rotiert oder widerrufen wurde?

Ihr API-Schlüssel hat nichts mit der Zertifikatsverifizierung zu tun. Zertifikate werden mit dem Ed25519-Schlüssel des Witness-Dienstes signiert und durch die RFC-3161-TSA sowie Sigstore Rekor extern verankert. Der Umschlag protokolliert die witness_key_id und wird mit dem Ed25519-Schlüssel des Witness signiert. Pro-Dienst-Claims tragen nur service_id und signature — es gibt kein key_id-Feld auf Claim-Ebene. Der öffentliche Schlüssel, der einen Claim verifiziert, wird über die service_id im Manifest unter /.well-known/veil-keys.jsonnachgeschlagen. Betreiber, die Dienstschlüssel rotieren, müssen die stillgelegten öffentlichen Schlüssel neben den aktuellen im Manifest veröffentlichen — sonst werden vor der Rotation signierte Claims unverifizierbar. Der Widerruf des API-Schlüssels verhindert neue Inferenzanfragen unter diesem API-Schlüssel, hat aber keinen Einfluss auf bereits erzeugte Zertifikate.

Kann ich ein altes Zertifikat heute erneut vorlegen, um etwas zu beweisen?

Ein Veil-Zertifikat ist an eine konkrete request_id, Claim-Kette und TSA-Zeitstempelung gebunden. Seine Ed25519-Signaturen decken genau diesen Umschlag ab — dasselbe Zertifikat als Nachweis einer anderen Anfrage oder einer aktuellen Entscheidung vorzulegen, scheitert bereits an der Bindung an die request_id. Was das Zertifikat dauerhaft belegt, ist, dass die ursprüngliche Anfrage zur im TSA-Token festgehaltenen Zeit durch die isolierte Pipeline gelaufen ist. Replay auf die ursprüngliche Anfrage ist ein Feature; Replay auf irgendetwas anderes ist keine Bedrohung, die das Protokoll abzuwehren versucht, weil die Bindung sie mechanisch unmöglich macht.

Referenzen

• RFC 3161 — Time-Stamp Protocol (TSP)
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA / Ed25519)
• Sigstore Rekor — Überblick zum Transparenzprotokoll
• Sigstore Rekor — hashedrekord-Eintrag verifizieren