Zusammenfassung

  • Neue Clients des Lightweight-Profils müssen nach RFC 9919 SHA-256 für CertID.issuerNameHash und issuerKeyHash verwenden. Alte, zu RFC 5019 kompatible Clients sollen SHA-1 so bald wie praktisch möglich verlassen.
  • Für die Übergangszeit darf ein Responder einen SHA-1- und einen SHA-256-SingleResponse gemeinsam ausliefern. Der beobachtete Request-Algorithmus kann die Entscheidung über das Ende dieser Kompatibilität unterstützen.
  • Das Log sieht nur eintreffende Requests. Client- und Proxy-Caches, vorproduzierte Antworten, Stapling, andere Responder-Pfade und Out-of-band-Absprachen können fortbestehende Abhängigkeit ausblenden.
  • Der Hash in CertID identifiziert den Ausstellerkontext des geprüften Zertifikats; er ist nicht der Signaturalgorithmus der OCSP-Antwort.
  • Ein belastbarer Stilllegungsbeleg nennt Beobachtungspunkte, Grundgesamtheit, Dual-Response-Regel, Abbruchkriterium, Entscheider, Canary, Rückfallpfad, Ausnahmeablauf und Ergebnis nach der Umstellung.

Wenn die Herkunftsmessung verstummt

Null SHA-1-Requests an einem Endpoint sind eine genaue Aussage über diesen Endpoint und den Messzeitraum. Daraus wird erst durch zwei unbewiesene Annahmen eine Aussage über alle Clients: Jede Nutzung müsse diesen Eingang passieren, und jede Nutzung müsse einen neuen Origin-Request erzeugen.

Das High-Volume-Profil will gerade die zweite Annahme vermeiden. Antworten dürfen vorproduziert werden. Clients müssen autoritative Antworten lokal cachen; HTTP-Proxys dürfen sie wiederverwenden; der Dienst kann vorbereitete Objekte verteilen. Beim Stapling oder Piggybacking reist die OCSP-Antwort in einem anderen Protokollaustausch mit. Der Client braucht dann keine eigene HTTP-Verbindung zum Responder.

Auch die erste Annahme ist unsicher. Regionen, Ersatzinstanzen, private Netze und Failover teilen den Verkehr. Weil OCSP Responder-Fähigkeiten nicht im Protokoll signalisiert, können Betreiber außerhalb des Protokolls vereinbaren, welches Profil gilt. Ein einzelnes Log inventarisiert weder diese Vereinbarungen noch selten aktive Gerätebestände.

Der Zähler kann also nach einem Upgrade fallen. Er kann ebenso wegen längerer Antwortlaufzeiten, besserem Caching, mehr Stapling oder einer Routingänderung fallen. Ohne ausgewiesene Grundgesamtheit sind diese Erklärungen nicht zu trennen.

Was die SHA-Umstellung tatsächlich betrifft

RFC 5019 schrieb SHA-1 für den Hash des Ausstellernamens und des Ausstellerschlüssels vor. RFC 9919 ersetzt das alte Profil und verlangt SHA-256 von neuen profilkonformen Clients. Alte Clients dürfen den bisherigen Pfad für Kompatibilität nutzen, müssen aber so bald wie praktisch möglich migrieren.

Auf der Antwortseite ist eine kontrollierte Überlappung möglich. Normalerweise soll ein SingleResponse genügen; zusätzliche Elemente sind jedoch für Vorproduktion, Cache-Effizienz oder Rückwärtskompatibilität erlaubt. RFC 9919 beschreibt ausdrücklich eine SHA-1- und eine SHA-256-Variante in derselben BasicOCSPResponse. Wenn kein Client SHA-1 benötigt, soll der Responder die alte Form nicht mehr verteilen. Request-Logs dürfen diese Einschätzung informieren.

Informieren ist nicht automatisch entscheiden. Der RFC bestimmt weder eine allgemeine Zahl stiller Tage noch einen zulässigen Restanteil oder einen globalen Nenner. Der jeweilige Betreiber muss die lokale Evidenz und das verbleibende Risiko verantworten.

Technisch ist die Schicht klar: CertID.hashAlgorithm steuert nach RFC 6960 die Hashes über Ausstellername und öffentlichen Schlüssel; die Seriennummer bezeichnet das Zielzertifikat. BasicOCSPResponse.signatureAlgorithm ist ein anderes Feld. RFC 9919 bewertet SHA-1 für diesen CertID-Zweck nicht als unmittelbares kryptografisches Problem. Die Last liegt im fortgesetzten Software-Support, seiner Komplexität und möglichen Angriffsfläche.

Ein Bericht darf den Abbau dieser Kompatibilität deshalb nicht als Ende von SHA-1-Antwortsignaturen ausgeben.

Beobachtbarkeit als Matrix

Die Grundgesamtheit umfasst Responder-Instanzen, Hostnamen, Regionen, Netzpfade, Zertifikatsfamilien und Client-Gruppen. Für jede Kombination ist festzuhalten, ob direkte Requests, Cache-Revalidierung, Proxy-Auslieferung, Stapling, Offline-Nutzung und Failover beobachtbar sind. Nicht instrumentiert ist ein eigener Zustand, kein Synonym für SHA-256.

Der Zeitraum folgt den Lebenszyklen. Ist die Messung kürzer als die langlebigste gespeicherte Antwort, muss ein alter Client noch gar nicht wieder anfragen. Selten aktualisierte Geräte und geschlossene PKIs benötigen eigene Evidenz. Ein Canary soll mehrere materielle Lieferwege abdecken, nicht nur das sichtbarste Zertifikat.

Bekannte Ausschlüsse erhalten Eigentümer und Ablaufdatum. Erst dann kann der Leser unterscheiden, ob Null tatsächlich Reichweite hat oder bloß die Lücken nicht zählt.

Vom Change-Ticket zum Abschlussbeleg

Der Beleg hält Scope und Entscheider, Beobachtungspunkte und Grundgesamtheit, SHA-1-Ausnahmen, Single- oder Dual-Response-Policy, Cache- und Stapling-Abdeckung, Messintervall und Stoppkriterium fest. Hinzu kommen Canary-Population und -Dauer, Rollback-Bedingung, funktionsfähiger Fallback und das Datum, an dem eine Ausnahme ohne neue Genehmigung endet.

Nach dem Cutover werden wiederkehrende SHA-1-Requests, Responder-Fehler, Validierungsfehler, Fallback-Nutzung, betroffene Zertifikate und Servicefolgen ergänzt. Ohne diese Rückmeldung dokumentiert das Ticket nur eine Absicht.

Die IETF definiert Interoperabilität. Den konkreten Betrieb und seine Folgen besitzt der Betreiber. Kompatibilität darf weder mangels Zuständigkeit ewig bleiben noch wegen eines stillen Dashboards verschwinden.

Quellen