Zusammenfassung

  • Entwurf 14 des STIR-OCSP-Profils prüft mit TNQuery, ob ein Zertifikat weiterhin für genau die vorgelegte Rufnummer gilt.
  • Eine signierte positive Antwort belegt Zertifikatsumfang und Zeitpunkt, nicht die Person am Telefon, ihre Absicht oder den Ausgang des Gesprächs.
  • Fehlende Erweiterung, unknown, veraltete Staple und Nichterreichbarkeit brauchen eigene Ursachencodes, bevor lokale Richtlinien handeln.

Warum „good“ nicht genau genug war

Klassisches OCSP beschreibt ein Zertifikat als good, revoked oder unknown. Bei delegierten STIR-Zertifikaten kann sich die Menge zulässiger Telefonnummern ändern, obwohl das Zertifikat selbst weder abgelaufen noch widerrufen ist.

draft-ietf-stir-certificates-ocsp-14 nimmt deshalb gewöhnlich die Nummer aus dem PASSporT-Feld orig und sendet sie als TNQuery. Gibt der Responder dieselbe Nummer in der signierten Antwort zurück, bestätigt er: Dieses Zertifikat ist innerhalb der Zeitgrenze der Antwort noch für diese Nummer gültig.

Mehr sagt die Antwort nicht. Sie weist keinen Menschen aus, bestätigt keine Einwilligung, bewertet keinen Gesprächsinhalt und genehmigt keine Überweisung. RFC 8224 macht das Verifikationsergebnis ausdrücklich zum Eingang einer nachgelagerten Autorisierung, die außerhalb seiner Vorgaben liegt.

Fehlt TNQuery in der Antwort auf eine Anfrage mit dieser Erweiterung, konnte der Responder den Nummernumfang nicht bestätigen. unknown muss ebenfalls als not good behandelt werden. Beides beweist keinen Betrug. Eine legitime Umschaltung, verzögerte Daten, ein Ausfall, eine ungültige Zertifikatskette und tatsächliche Täuschung bleiben unterschiedliche Ursachen.

Ein Staple verlegt den Abrufzeitpunkt

Eine Live-Abfrage verlängert den zeitkritischen Rufaufbau. Deshalb definiert der Entwurf den PASSporT-Claim stpl, der eine vorab oder anlassbezogen beschaffte OCSP-Antwort transportiert.

Der Staple erspart dem Verifikationsdienst einen Netzweg. Er vergrößert nicht die Aussage. Signatur, Zeit, Nummer, Zertifikatspfad, Delegationsumfang und PASSporT bleiben zu prüfen. Erst danach entscheidet die Zielseite über Zulassen, Kennzeichnen, Nachfragen oder Sperren.

Bei großen Rufnummernbereichen kann für jede mögliche Ursprungsnummer ein eigener vorgefertigter Staple nötig sein. Ein Bestand aus ausschließlich korrekt signierten Antworten kann daher unvollständig sein. Abdeckung, Verteilung, Frische und Signaturgültigkeit sind getrennte Betriebsnachweise.

Frische Statusdaten haben einen Datenschutzpreis

Die Live-Anfrage zeigt dem OCSP-Dienst die rufende Nummer und den prüfenden Dienst. TLS schützt vor passiven Dritten, nicht vor der Sicht des Responders. Stapling reduziert diese Einzelabfragen, verlangt dafür kontrollierte Erneuerung und Bestandsführung.

Die Wahl zwischen Aktualität und Datensparsamkeit ist eine lokale Risikofrage. Aus der Signatur einer Zertifizierungsstelle entsteht kein Mandat, diese Abwägung für das Zielnetz zu treffen.

Der Prüfpfad braucht mehr als eine Ampel

Getrennt aufzubewahren sind beobachtetes orig, Zertifikat und Pfad, TN-Berechtigungsumfang, Anfrage, signierte Antwort und Zeiten, Live- oder Staple-Weg, Prüfresultat, Richtlinienversion und Grund, ausgeführte Behandlung und beobachtete Wirkung.

Die IESG hat Revision 14 gebilligt; sie liegt beim RFC Editor. Bis zur Veröffentlichung bleibt sie ein Internet-Draft. Dieser Stand belegt weder Einführung bei einem Anbieter noch Produktkonformität oder weniger unerwünschte Anrufe.

Quellen