Zusammenfassung

  • In RFC 5217 gehört PKI2 zu zwei Domänen. Dadurch lässt sich von PKI1 über PKI2 ein Pfad zu PKI3 bauen. Unter der Policy von Domäne 1 darf die Validierung dennoch nicht gelingen, weil PKI1 und PKI3 diese Domäne nicht gemeinsam haben.
  • Cross-Zertifikate und eine Bridge CA schaffen signierte Verbindungen. Für die Annahme braucht es weiterhin einen Trust Anchor, Policy- und Namensbeschränkungen, aktuellen Mitgliedschafts- und Widerrufsstatus sowie eine zurechenbare Entscheidung der vertrauenden Anwendung.

Ein erfolgreicher Aufbau mit richtigem Abbruch

Der Validator hatte jedes benötigte Zertifikat gefunden. Die Signaturen passten, der Kandidat begann am konfigurierten Trust Anchor und endete beim Teilnehmerzertifikat. Trotzdem lautete das Ergebnis: abgewiesen.

Wer nur die Erfolgsquote beobachtet, sieht darin einen Interoperabilitätsfehler. RFC 5217 liefert eine andere Diagnose. Die Ablehnung kann belegen, dass eine vereinbarte Grenze tatsächlich durchgesetzt wurde.

PKI2 ist im Beispiel Mitglied der Domänen 1 und 2. Ein Pfad führt von PKI1 zu PKI2, ein weiterer von PKI2 zu PKI3. Der Builder kann beide Abschnitte verbinden. PKI1 und PKI3 teilen jedoch nicht die Mitgliedschaft in Domäne 1. Bei einer Validierung nach deren Policy muss der vollständige Pfad scheitern.

Die Topologie sagt, dass ein Weg vorhanden ist. Sie sagt nicht, wer ihn für welchen Zweck freigegeben hat.

Finden ist nicht entscheiden

Path Building sucht eine geordnete Zertifikatsfolge vom Trust Anchor zum End-Entity-Zertifikat. Die Validierung prüft diesen Kandidaten gegen Policies, Namensräume, Verwendungszweck, Zeit und Widerruf. Dass Software beides nacheinander erledigt, macht die Ergebnisse nicht identisch.

Eine Bridge oder ein Mesh erweitert den Suchraum und reduziert bilaterale Beziehungen. Damit wird ein entfernter Aussteller erreichbar. Für die Annahme in jeder Anwendung entsteht daraus keine Generalvollmacht.

RFC 5217 lässt jeder PKI ihre eigenen Certificate Policy OIDs und ihre Principal CA. Vor einer externen Beziehung werden Policy- und Governance-Dokumente geprüft und Assurance-Niveaus abgebildet. Das Cross-Zertifikat formalisiert das begrenzte Ergebnis. Es vereinheitlicht weder Institutionen noch Zwecke.

Doppelmitgliedschaft lässt Pfade durchsickern

PKI2 verbindet als Mitglied zweier Domänen getrennte Vertrauensräume. Fehlen präzise Grenzen, kann der Algorithmus eine Route entdecken, auf der lokales Vertrauen scheinbar transitiv wird. Jede einzelne Signatur kann stimmen, ohne dass die Gesamtnutzung genehmigt ist.

RFC 5217 verlagert die Grenze deshalb in signierte Cross-Zertifikate: Policy Mappings, Policy Constraints und Name Constraints sollen domänenfremde Validierungen verhindern. Eine Domäne sollte sich nicht darauf verlassen, dass jede Relying Party zufällig dieselbe lokale Regel setzt.

Auch Mitgliedschaft hat einen Lebenszyklus. Tritt eine PKI einer weiteren Domäne bei oder verlässt sie, ändert sich der erreichbare Graph. Die betroffenen Domänen müssen informiert und die Beschränkungen geprüft werden. Ändert sich die erlaubte Pfadmenge, ist das alte Cross-Zertifikat zu widerrufen und korrekt neu auszustellen.

Die Signatur schützt eine Aussage. Sie hält die von ihr beschriebene Welt nicht an.

Die Bridge CA ist keine gemeinsame Wurzel

Das Bridge-Modell senkt die Zahl direkter Cross-Zertifizierungen. Die Bridge CA ordnet Policies zu und soll gegenüber den Domänen neutral bleiben. RFC 5217 verbietet zugleich, sie als Trust Anchor einer teilnehmenden Domäne zu verwenden; gewöhnliche End-Entity-Zertifikate darf sie ebenfalls nicht ausstellen.

So wird ein zentraler Koordinator nicht stillschweigend zum Souverän. Die Relying Party beginnt weiterhin mit dem eigenen Anchor. Beim Übergang über die Bridge müssen die signierten Bedingungen beider Seiten verarbeitet werden. Topologische Zentralität und Entscheidungsbefugnis bleiben getrennt.

Die Trust List hat einen Verantwortlichen

Eine Local Trust List wird von einer einzelnen Relying Party für den eigenen Gebrauch gepflegt. Sie kann auf komplexe Cross-Zertifizierung verzichten, verteilt aber die Pflege. Eine Trust Authority verwaltet eine Liste für mehrere Beteiligte und vereinheitlicht die Arbeit.

Das Urteil bleibt nötig. Vor Aufnahme einer PKI sind Policy, Assurance, Pflichten der Relying Party, Gewährleistungen sowie Widerrufs- und Kompromittierungsmeldungen zu prüfen. Diese Prüfung wird wiederholt. Wer Vertrauen in weitere Domänenmitglieder nicht erben will, muss Policy Mapping hemmen.

Ein Listeneintrag ist eine Berechtigung. Das Hinzufügen einer CA kann neue Zertifikate zulassen; das Entfernen kann Dienste sperren. Änderungen brauchen daher Eigentümer, Begründung, Zeit und Geltungsbereich.

Ein Beleg für die Annahmebefugnis

Der Beleg bindet Anwendung und Relying Party, Entscheidungszeit, Validator-Version, Fingerabdruck und Installationsquelle des Anchors, beabsichtigte Domäne, Zweck und anfängliche Policy-Menge.

Er bewahrt den exakten Kandidatenpfad, alle verarbeiteten Mappings und Constraints, den Mitgliedschaftsstand, Cross-Zertifikats- und Widerrufsdaten, die Version der Trust List, die Frische von CRL oder OCSP, Ergebnis und Ablehnungsgrund sowie die tatsächlich erlaubte oder verhinderte Aktion.

Auch der gebaute und abgelehnte Pfad bleibt erhalten. Er beweist, dass der Validator Reichweite erkannt, aber nicht zu Befugnis aufgeblasen hat.

Aussagegrenze

RFC 5217 ist Informational und erkennt andere Interoperabilitätsmodelle an. Derselbe Pfad kann mit anderem Anchor, Zweck oder anderer Gemeinschaft zulässig sein. Hier wird keinem konkreten Anbieter oder Betreiber ein Fehler unterstellt.

Die operative Aussage ist enger: Signatur, Pfad, Domänenmitgliedschaft und Anwendungsannahme sind vier Nachweise. Ein einziges grünes Signal würde aus ihrer Vermischung eine Autorität erfinden.

Quellen

Ergänzendes Normenverzeichnis

  1. RFC 5217 als Klartext
  2. Informationsdatensatz zu RFC 5217
  3. IETF-Datatracker-Datensatz
  4. IETF-Datatracker-Verlauf
  5. RFC 4949: Internet Security Glossary
  6. RFC 5914: Trust Anchor Format
  7. RFC 5934: Anforderungen an die Trust-Anchor-Verwaltung
  8. RFC 6024: Protokollanforderungen für Trust Anchors
  9. RFC 5055: serverbasierte Zertifikatsvalidierung
  10. RFC 6818: Aktualisierungen zu RFC 5280
  11. RFC 6960: Online Certificate Status Protocol
  12. RFC 5019: leichtgewichtiges OCSP-Profil
  13. RFC 6962: Certificate Transparency
  14. RFC 7030: Enrollment over Secure Transport