Summary

  • Ein individueller Internet-Draft schlägt /.well-known/company-certs zur HTTPS-Ermittlung anwendungsspezifischer privater Vertrauensanker vor, ohne sie in den globalen Betriebssystemspeicher aufzunehmen.
  • Authentisierte Herkunft, gültige X.509-Pfade und die Auswahl des jüngsten valid_from belegen nicht, dass die zuständige Organisationsrolle den Austausch genehmigte. In einer Überlappungsphase kann sich wirksames Vertrauen ändern, bevor dieses Mandat nachweisbar ist.
  • Daniel Kade schlägt einen Vertrauensanker-Änderungsbeleg vor: exakte Metadatenepoche, alte und neue Fingerabdrücke, Geltungsbereich, Überlappung, Genehmigungsinstanz, lokale Richtlinie, unabhängige Bestätigung und Rückkehrpfad. Das ist redaktionelle Governance, keine IETF-Vorgabe.

Eine reguläre Rotation zeigt bereits die Lücke

Ein Angriff ist für das Gedankenexperiment nicht nötig. Das Unternehmen bereitet einen normalen Wechsel vor und veröffentlicht alte und neue Kette einige Tage parallel. So müssen nicht alle Clients im selben Augenblick umgestellt werden. Beide Ketten sind zeitlich anwendbar, besitzen denselben Nutzungskontext und bleiben innerhalb der erlaubten Domänen.

Die Architektur bietet echte Vorteile. Eine authentisierte Herkunft ist besser als eine CA-Datei per E-Mail. Ein anwendungsspezifischer Speicher ist sicherer als ein globaler Import. Eine eindeutige Auswahlregel schützt vor zufälligem Verhalten. Dennoch beweist der Abruf nur, was die Herkunft ausgeliefert und der Client ausgewählt hat. Er nennt weder den PKI-Verantwortlichen noch den Anwendungsbesitzer, der die neue Autorität akzeptierte.

Ein Vertrauensanker ist kein gewöhnlicher Konfigurationswert. Er ist eine lokale Eingabe der Pfadvalidierung. Wird er angenommen, können zuvor abgelehnte Zertifikatspfade für den begrenzten Zweck gültig werden. Die technische Fähigkeit, den Endpunkt zu ändern, ist damit eine Fähigkeit, den anerkannten Autoritätsraum der Anwendung zu verändern.

Was der Entwurf festlegt

draft-doehle-company-certs-discovery-00 ist ein individueller Internet-Draft vom 22. Juli 2026 mit beabsichtigtem Standards-Track. Zum Stichtag existiert nur Revision -00. Der Text ist weder RFC noch IETF-Konsens und kein Nachweis einer Implementierung.

Der Entwurf legt ein versioniertes JSON-Objekt unter /.well-known/company-certs ab. Es umfasst authority_information und trust_anchors. Jeder Anker ist einem usage_context und einer oder mehreren certificate_chains zugeordnet. Ketten können valid_from, valid_until, eine gleichursprüngliche HTTPS-URL, PEM-X.509-Material, CRL-, OCSP- und SHA-256-Angaben enthalten.

permitted_domains werden an DNS-Identitäten im validierten TLS-Zertifikat des Endpunkts gebunden: erlaubt sind die identische Domäne oder untergeordnete Namen. isolated_store_required drückt aus, dass der Anker in einem getrennten Speicher bleiben soll. Kann der Client das nicht gewährleisten, soll er ablehnen.

Das Verfahren verändert nicht den globalen Betriebssystem-Truststore, ersetzt nicht die Web-PKI und registriert keine Endzertifikate. Es erklärt eine private CA auch nicht für beliebige Zwecke vertrauenswürdig. Gerade die Eingrenzung auf eine Anwendung ist seine Stärke.

HTTPS-Validierung ist Pflicht. Kontrolle über die Herkunft verleiht Publikationsbefugnis für diese Herkunft. Der Entwurf stellt zugleich klar, dass sie Qualität, Sicherheit und betriebliche Vertrauenswürdigkeit der privaten CA nicht selbst attestiert. DNS, Hosting, CDN, TLS-Schlüssel, Deployment und CA-Verwaltung können organisatorisch getrennt sein.

Eine Herkunft ist kein Organigramm

RFC 8615 ordnet den Well-known-Namensraum. Seine Sicherheitsbetrachtung warnt, dass Schreibzugriff auf eine solche Ressource Autorität über den gesamten Ursprung darstellen kann. Bei gemeinsamem Hosting oder komplexen Berechtigungen kann ein scheinbar kleiner Zugang überraschend weit reichen.

Das spricht nicht gegen Herkunftsauthentisierung. Sie beantwortet zuverlässig, aus welchem Namensraum die Aussage stammt. Sie beantwortet nicht, wer intern zuständig war. Das Webteam kann deployen, das Netzteam DNS verwalten, ein CDN ausliefern, die PKI-Gruppe die Kette betreiben und der Anwendungseigner den Einsatzzweck verantworten. „Das Unternehmen hat veröffentlicht“ verschluckt diese Übergaben.

RFC 9525 unterstützt die Prüfung einer TLS-Identität gegen den beabsichtigten Referenznamen. Ein erfolgreicher Test zeigt, dass der Client einen für den Namen autorisierten Server erreichte. Er ist kein Protokoll der internen Freigabe. Der richtige Endpunkt kann eine Änderung ausliefern, deren Mandat nicht nachweisbar ist.

Auch Automatisierung braucht ein Mandat. Sie kann legitim genehmigen, wenn Zweck, erlaubte Fingerabdrücke, zweite Evidenz, maximale Überlappung sowie Stopp- und Rückkehrrechte begrenzt sind. Ein erfolgreicher Pipeline-Lauf belegt Ausführung, nicht aus sich selbst heraus Befugnis.

Der spätere Zeitpunkt genehmigt nichts

Sind mehrere Ketten für denselben Kontext anwendbar, verwirft der Entwurf solche außerhalb ihrer Zeitspanne und bevorzugt ansonsten das jüngste valid_from, sofern lokale Richtlinien nicht widersprechen. Das ist eine deterministische Auswahl, kein Genehmigungsverfahren.

RFC 3339 sorgt für interoperable Zeitangaben. Ein korrektes Datum sagt nicht, wer es setzte, warum die Überlappung galt oder ob zwei zuständige Gruppen übereinstimmten. Rechtmäßige, irrtümliche und kompromittierte Publikationen können gleichermaßen einen syntaktisch richtigen späteren Wert tragen.

RFC 5280 schließt diese Lücke nicht. Die Pfadvalidierung erhält Vertrauensanker und Richtlinien als lokale Eingaben. Sie kann die neue Kette unter diesen Voraussetzungen bestätigen, aber nicht den Prozess prüfen, der den Anker zur Eingabe machte.

Die Jüngster-Regel erfüllt also eine sinnvolle Aufgabe. Der Fehler liegt im Bericht, wenn „gemäß Clientrichtlinie ausgewählt“ zu „vom Unternehmen genehmigt“ wird.

Isolation muss beobachtbar sein

isolated_store_required ist eine Absichtserklärung des Herausgebers, keine technische Schranke. Der Client muss wissen, ob seine Architektur die Trennung durchsetzt. Ein vorhandenes Wahrheitsfeld beendet die Prüfung nicht.

Zu untersuchen ist, in welchen Speicher der Anker gelangt, welche Validierungsaufrufe ihn erreichen und ob gemeinsame Bibliotheken seinen Geltungsbereich erweitern. Eine Umstrukturierung kann eine private Sammlung in einen geteilten Cache verschieben, ohne das JSON zu verändern.

Auch permitted_domains wirken nur durch lokale Durchsetzung. Ein Parser kann das Feld lesen, während der Pfadbauer es ignoriert. Caches können Nutzungskontexte vermischen. Der Governance-Beleg muss veröffentlichte Grenze und beobachtetes Verhalten verbinden.

Die Isolation ist das wichtigste Sicherheitsversprechen des Entwurfs. Gelangt der Anker in den globalen Speicher, wird aus begrenzter Ermittlung eine weit größere Vertrauensentscheidung. Das ist eine Autoritätsänderung, kein Implementierungsdetail.

Frisches HTTPS kann ein altes Mandat tragen

RFC 9110 und RFC 9111 unterscheiden HTTP-Semantik, Cachefrische und Revalidierung. Der Entwurf verlangt vorsichtige Zwischenspeicherung, periodische Prüfung und Schutz vor Replay oder veralteten Metadaten; Clients dürfen eine eigene Höchstdauer festlegen.

Diese Regeln beantworten, ob die Darstellung der Herkunft hinreichend aktuell ist. Sie verlängern keine interne Freigabe. Eine zweistündige Notfallausnahme kann vor dem Cache enden. Eine Sicherheitsrolle kann ihre Zustimmung zurückziehen, während ein Edge noch die alte Epoche ausliefert. Ein frisch geholtes JSON kann dennoch vom Anwendungseigner nie gebilligt worden sein.

Der erste erfolgreiche Abruf ist ein sensibles Bootstrap-Ereignis. Vorher besitzt der Client keinen Anker aus diesem Kanal; danach kann er neue Pfade akzeptieren. Erstaufnahme, Routineaktualisierung, Überlappung, Umschaltung, Entfernung und Rückkehr sollten deshalb verschiedene Betriebszustände sein.

Abrufe können außerdem Interesse an einer Organisation oder einem Nutzungskontext verraten. Cache schützt Privatsphäre und Verfügbarkeit, macht aber seine Dauer zu einem Teil der Vertrauensentscheidung. Entscheidend ist die zulässige Korrekturzeit, nicht nur Netzlast.

Zertifikatsstatus ist kein Freigabestatus

Die Metadaten können CRL- und OCSP-Orte enthalten. RFC 6960 liefert Statusauskünfte über Zertifikate. Das ist wertvoll, erklärt aber nicht die Freigabe eines Ankerwechsels.

Eine neu veröffentlichte CA kann nicht widerrufene Zertifikate ausstellen, obwohl ihre Aufnahme unbefugt war. Der alte Anker kann kryptografisch nutzbar bleiben, obwohl seine Entfernung vorgesehen war. Untergeordneter Status rekonstruiert weder Genehmiger noch Überlappungszweck.

Das Löschen am Endpunkt wirkt nicht sofort auf Caches, Offline-Clients, bestehende Sitzungen oder Kopien außerhalb des isolierten Speichers. Korrektur braucht betroffene Populationen, maximale Laufzeit und Abschlussnachweis.

Ein Vertrauensanker-Änderungsbeleg

Daniel Kade schlägt für jede wesentliche Company-Certs-Transition einen Vertrauensanker-Änderungsbeleg vor. Er ist kein neues Pflichtfeld im öffentlichen JSON und keine IETF-Regel. Er verbindet Publikationsfakt, internes Mandat und lokale Entscheidung.

Zuerst friert er die Epoche ein: exakter Objektdigest, Herkunft, validierte Referenzidentität, Abrufzeit und Cachezustand. Nutzungskontext, erlaubte Domänen und Isolationspflicht grenzen die Zustimmung ein. Eine Freigabe für einen Digest deckt nicht künftige Inhalte derselben URL.

Dann beschreibt er die Bewegung: alte und neue Fingerabdrücke, Kettenkennungen, Gültigkeitszeiten, Überlappungsfenster und vorgesehener Umschaltzustand. Hinzufügen, Bevorzugen, Entfernen und Zurückrollen sind verschiedene Handlungen.

Der Autoritätsteil nennt Rolle, Richtlinie oder begrenzte Automatisierung sowie einen geschützten Verweis auf den freigegebenen Vorgang. Persönliche Namen oder Sitzungsprotokolle müssen nicht öffentlich werden. Das Mandat muss jedoch unabhängig vom ausführenden Publikationsweg prüfbar sein.

Der Clientteil hält Auswahlregel, zusätzliche Bestätigung, tatsächliche Isolation, Revalidierungsfrist und Verhalten bei Unerreichbarkeit fest. Zur Korrektur gehören CRL, OCSP, Notentfernung, Rückkehr, Clientklassen und maximale Ausbreitungszeit. Auch der Beleg selbst läuft ab.

Bestätigung nach möglicher Wirkung

Ein internes Testwerkzeug mit geringen Rechten kann Herkunftsauthentisierung plus signierte Repository-Freigabe akzeptieren. Bei Zahlung, Signatur oder Infrastruktursteuerung kann eine zweite Rolle oder ein getrennter Verwaltungskanal nötig sein. Der Aufwand soll zur Folge passen.

Eine zweite URL derselben Deployment-Kette oder eine Nachricht desselben Kontos ist kaum unabhängig. PKI-Steuersystem, signiertes Manifest, geschütztes Änderungsjournal oder hardwaregebundener Freigabeschlüssel trennen Fehler besser.

RFC 5011 ist nur ein begrenzter Vergleich. Für automatische DNSSEC-Ankeränderungen nutzt es Hinzufüge-, Halte- und Entfernungszustände. Es gilt nicht für Company-Certs. Die schmale Lehre lautet: Software, die ihre Vertrauensbasis ändern darf, braucht beständigen Übergangszustand statt nur eines „aktuellen“ Werts.

Getrennte Verben erhalten

Der frühe Entwurf muss nicht jede Unternehmensverfassung abbilden. Mit authentisierter Herkunft, Domänengrenze, Nutzung, Gültigkeit und Isolation bietet er bereits mehr Disziplin als ein kontextlos verschicktes CA-File oder globaler Import.

Die Quellen belegen keine benannte Implementierung, Störung oder missbräuchliche Rotation. Das Eingangsszenario ist ein Entwurfstest aus der Mehrkettenregel, keine Behauptung über ein Unternehmen.

Reife Governance trennt die Verben: HTTPS authentisiert den Abruf. JSON stellt Metadaten dar. X.509 validiert einen Pfad unter lokalen Eingaben. Clientrichtlinie wählt. Organisationsautorität genehmigt. Der Änderungsbeleg verknüpft diese Tatsachen, ohne einer zu erlauben, alle anderen zu ersetzen.

Quellen

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-doehle-company-certs-discovery-00
  5. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/
  6. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/history/
  7. https://www.rfc-editor.org/rfc/rfc8615.html
  8. https://www.rfc-editor.org/rfc/rfc9525.html
  9. https://www.rfc-editor.org/rfc/rfc5280.html
  10. https://www.rfc-editor.org/rfc/rfc6960.html
  11. https://www.rfc-editor.org/rfc/rfc9110.html
  12. https://www.rfc-editor.org/rfc/rfc9111.html
  13. https://www.rfc-editor.org/rfc/rfc8259.html
  14. https://www.rfc-editor.org/rfc/rfc3339.html
  15. https://www.rfc-editor.org/rfc/rfc5011.html