Zusammenfassung

  • Am von SC-104 benannten Basis-Commit ist die nicht kritische Authority-Information-Access-Erweiterung in TLS-Subscriber-Zertifikaten ein MUST. Innerhalb der Erweiterung ist id-ad-caIssuers jedoch SHOULD und id-ad-ocsp MAY.
  • Der unveränderliche Redline-Vergleich nimmt zwei Änderungen vor: Die äußere Präsenz wird SHOULD, und die Forderung nach mindestens einer AccessDescription gilt nur, wenn die Erweiterung vorhanden ist.
  • Die beiden Methoden bleiben unverändert. caIssuers verweist auf Ausstellerzertifikate für die Pfadbildung; OCSP verweist auf einen Online-Statusdienst. Ein gemeinsamer ASN.1-Container macht sie nicht austauschbar.
  • Laut öffentlicher Mitteilung endet die Abstimmung am 3. September 2026 um 00:00 UTC. Zum Recherche-Stichtag am 2. September sind weder ein Ergebnis noch ein abgeschlossenes IPR-Verfahren oder eine veröffentlichte Guideline zu unterstellen.
  • Ein belastbarer Nachweis hat fünf getrennte Ebenen: Verfahrensstand, Profilregel, Methodenregel, ausgestellte Bytes und Verhalten der prüfenden Anwendung. Versionen und Zertifikats-Fingerprints verbinden sie, ersetzen sie aber nicht.

Der scheinbar einfache Audit-Fall

Ein Auditor bekommt ein Subscriber-Zertifikat und eine Checkliste. In der Zeile authorityInformationAccess steht am Basistext von SC-104: Präsenz MUST, kritisch „N“. Der Fall scheint binär. Erweiterung da: bestanden. Erweiterung nicht da: nicht bestanden.

Schon die nächste Tabelle zerstört diese Einfachheit. Die AuthorityInfoAccessSyntax muss zwar mindestens eine AccessDescription enthalten, doch die erlaubten Methoden haben eigene Stufen. id-ad-caIssuers ist SHOULD; id-ad-ocsp ist MAY; alle anderen Methoden sind MUST NOT. Der Pflichtcontainer garantiert also nicht genau einen bestimmten Dienst.

Das macht den aktuellen Text nicht bedeutungslos. Ein vorhandener Container darf nicht leer sein. Kodierung, zulässiger URI-Typ, Eindeutigkeit und Reihenfolge bleiben geregelt. Auch ein SHOULD ist eine starke Empfehlung. Aber die äußere Gewissheit ist größer als die Gewissheit über jede einzelne innere Route.

SC-104 greift exakt dort ein. Im Extensions-Table wird MUST zu SHOULD. Vor die Mindestzahl der AccessDescriptions tritt „If present“. Die Methode-Tabelle bleibt unverändert. Der Vorschlag führt keine neue Methode ein, ändert keine OID und macht aus dem caIssuers-SHOULD kein MAY.

Wer den Redline als „AIA wird optional“ zusammenfasst, entfernt damit den wichtigsten Unterschied des Textes.

SHOULD verlangt eine begründbare Ausnahme

RFC 2119 definiert SHOULD nicht als freie Beliebigkeit. Es kann gültige Gründe geben, der Empfehlung nicht zu folgen; die Folgen müssen jedoch verstanden und sorgfältig abgewogen werden. RFC 8174 bestimmt, wann die großgeschriebenen Schlüsselwörter diese normative Bedeutung tragen.

Sollte SC-104 wirksam werden, wäre ein Subscriber-Zertifikat ohne AIA kein Verstoß gegen ein äußeres MUST mehr. Daraus folgt nicht, dass die Abwesenheit keine Erklärung mehr braucht. Eine CA kann dokumentieren, welche Guideline-Version gilt, welches Ausgabeprofil die Ausnahme erlaubt, warum sie vertretbar ist, welche Zertifikatsprodukte betroffen sind und welche Client-Matrix geprüft wurde.

Ein Boolean-Feld aia=false kann eine bewusst geprüfte Ausnahme, ein veraltetes Template und einen Konfigurationsfehler nicht unterscheiden. Es verwirft die Governance-Leistung des SHOULD. Ein Feld allowed=true wäre ebenso schwach, weil es die Empfehlung in eine bloße Erlaubnis umdeutet.

Die sinnvolle lokale Klassifikation lautet daher: Standardinklusion, begründete Ausnahme oder ungeklärte Abweichung. Die gemeinsame Regel darf flexibler werden, ohne dass die lokale Entscheidung unsichtbarer werden muss.

Zwei Methoden, zwei Abhängigkeiten

RFC 5280 beschreibt AIA als Folge von Zugangsbeschreibungen zu Informationen oder Diensten des Ausstellers. id-ad-caIssuers bezeichnet einen Ort, an dem Ausstellerzertifikate erhältlich sind. Das kann einer relying party bei Auswahl und Aufbau eines Zertifizierungspfads helfen. id-ad-ocsp bezeichnet einen Online-Dienst für Zertifikatsstatus.

Die beiden Einträge können HTTP-URIs benutzen und im selben Container stehen. Ihre Funktion bleibt verschieden. Ein erfolgreicher OCSP-Abruf liefert nicht automatisch das fehlende Zwischenzertifikat. Ein erfolgreicher caIssuers-Abruf sagt nichts darüber, ob und wie der Status geprüft wurde.

Die Baseline Requirements lesen diese Differenz auch an anderen Stellen. Bedingungen für CRL-Aktualisierung oder CRL Distribution Points können speziell davon abhängen, ob das Subscriber-Zertifikat einen AIA-OCSP-Pointer enthält. „AIA vorhanden“ reicht deshalb selbst zur Normprüfung nicht immer als Beobachtung. Die Methode muss benannt werden.

Ebenso wenig beweist fehlendes caIssuers einen unvermeidbaren Pfadfehler. Ein TLS-Server kann das passende Zwischenzertifikat liefern. Der Client kann es bereits im Store oder Cache haben. Ein Anbieter kann es über einen eigenen Verteilweg bereitstellen. Umgekehrt beweist eine kodierte URL weder einen Abruf noch Erreichbarkeit oder einen gültigen resultierenden Pfad.

Die Bytes sagen, welcher Hinweis existiert. Sie sagen nicht, welchen Weg eine Ausführung genommen hat.

Microsoft und Mozilla begrenzen die Verallgemeinerung

Microsoft dokumentiert, dass Windows fehlende Ausstellerzertifikate über AIA abrufen kann. Dieselbe Dokumentation beschreibt, dass Administratoren diese Funktion abschalten können. Ein Testbericht mit der Angabe „Windows“ lässt daher wesentliche Variablen offen: Version, Richtlinie, Zertifikatsspeicher, Cache, Netzwerk, URL und Serverkette.

Mozilla beschrieb 2020 die Vorabverteilung offengelegter Zwischen-CA-Zertifikate über Firefox Remote Settings. Sie sollte unter anderem Unknown-Issuer-Fehler verringern, wenn Websites das richtige Zwischenzertifikat nicht mitsenden. Ein Preload ist damit ein anderer möglicher Ursprung des Pfadmaterials.

Er ist aber keine universelle Zusage für jede Firefox-Version, jedes Zwischenzertifikat und jede Konfiguration. Er entbindet Serverbetreiber nicht davon, eine passende Kette auszuliefern. Die Windows-Funktion wiederum beweist keine flächendeckende AIA-Abhängigkeit.

Diese Beispiele zeigen, welche Felder ein Versuch braucht. Woher kam das Zwischenzertifikat: Server, lokaler Store, Cache, Preload oder caIssuers-Abruf? War der Abruf erlaubt? Welche Netzbedingungen galten? Ohne diese Angaben kann ein Erfolg der falschen Schicht zugeschrieben werden. Wird später der Cache geleert, erscheint die alte Abhängigkeit als neue Störung.

Die Verfahrensuhr läuft noch

Die öffentliche SC-104-Mitteilung nennt Ethan Davis von Google Trust Services als proposer sowie Roman Fischer von SwissSign und Stephen Davidson von DigiCert als endorsers. Sie bezieht sich auf Baseline Requirements 2.2.9 und verlinkt den festen Vergleich vom Basis-Commit ad77bf… zum vorgeschlagenen Commit a0f9a7….

Die Diskussionsphase war für den 20. bis 27. August 2026 UTC angesetzt, die Abstimmung vom 27. August bis zum 3. September um 00:00 UTC. Am 2. September ist die korrekte Zustandsbeschreibung somit „in Abstimmung“.

Ein offener Pull Request ist kein angenommenes Regelwerk. Auch ein positiver Abstimmungsausgang wäre noch nicht dasselbe wie ein abgeschlossenes IPR-Review und eine veröffentlichte Final Maintenance Guideline. Erst die veröffentlichte Version und ihr Wirksamkeitsdatum beantworten, welcher gemeinsame Text auf eine Ausgabe zu einem bestimmten Zeitpunkt anwendbar war.

Der Verfahrensbeleg sollte Ballot-ID, proposer, endorsers, Basis und Vorschlag, Zeitfenster, Stimmberechtigten-Nenner, Stimmen, Ergebnis, IPR-Stand, Exclusion Notices, finale Version und Geltungsbeginn führen. Ein späterer Erfolg darf den Status vom 2. September nicht rückwirkend überschreiben.

Auch bei Scheitern bleibt der Redline Beleg dafür, was zur Entscheidung stand. Verfahren ist nicht nur Vorlauf zur technischen Wahrheit; es ist die Herkunft ihrer Autorität.

Das Fünf-Zustände-Protokoll

Verfahren: Welchen Stand hat SC-104? Basis, Vorschlag, Abstimmung, IPR und Veröffentlichung werden als zeitliche Kette geführt. Diese Ebene beweist Autorisierung.

Profil: Für welchen Zertifikatstyp und welche Guideline-Version gilt welche äußere AIA-Stufe? Kritikalität und Wirksamkeit gehören dazu. Diese Ebene beweist die anwendbare Norm.

Methode: caIssuers und OCSP erhalten getrennte Zeilen mit OID, Zweck, Stufe, Location-Typ, Anzahl und Reihenfolge. Diese Ebene beweist den zulässigen inneren Aufbau.

Ausgabe: Ausstellende CA, Produkt, Template- oder Konfigurationsversion, Fingerprint und tatsächlich kodierte AccessDescriptions werden festgehalten. Diese Ebene beweist Zertifikatsbytes.

Nutzung: Clientprodukt, Version, Plattform, Richtlinie, Store, Cache oder Preload, Serverkette, Netzwerk, Abrufversuch, Statuspfad und Ergebnis werden dokumentiert. Diese Ebene beweist eine reproduzierbare Beobachtung.

Die Guideline-Version verbindet Verfahren und Profil. Die Ausgabekonfiguration verbindet Profil und Zertifikat. Der Fingerprint verbindet Zertifikat und Clientversuch. Dennoch darf keine Ebene die nächste vertreten. Eine erfolgreiche Validierung beweist keinen AIA-Abruf. Ein lokaler Fehler beweist keinen Normfehler. Ein veröffentlichter Text beweist keine Template-Änderung.

Lu Hengs Trennung zwischen minimaler gemeinsamer Spezifikation, lokal überprüfbaren Folgeentscheidungen und tatsächlicher Übernahme bietet hier eine redaktionelle Leitlinie. Sie bedeutet nicht, dass Lu Heng SC-104 beurteilt hat. Sie verhindert, dass Veröffentlichung als Einsatz oder ein einzelner Einsatz als allgemeine Übernahme ausgegeben wird.

Was der öffentliche Datensatz offenlässt

Die geprüften Quellen messen nicht, wie viele aktuelle Subscriber-Zertifikate AIA, caIssuers, OCSP oder beide Methoden enthalten. Sie nennen keine CAs, die nach einer Annahme ihr Profil ändern würden. Sie quantifizieren weder Größenersparnis noch Datenschutz, Latenz, Verfügbarkeit, Sicherheit oder Fehlerraten.

Die normative Begründung des Vorschlags kann trotzdem schlüssig sein: Wenn keine innere Methode MUST ist, liefert der äußere Pflichtcontainer keine Garantie für eine bestimmte Route. Normative Stimmigkeit ist jedoch kein gemessener Betriebsvorteil.

Befürworter dürfen Firefox-Preloads nicht als universelle Unabhängigkeit von AIA behandeln. Gegner dürfen die Windows-Abruffunktion nicht als universelle Abhängigkeit behandeln. Beide brauchen abgegrenzte Populationen und wiederholbare Tests.

Dem Diff angemessene Aussagen

SC-104 stellt eine enge Frage an das Working Group: Soll die äußere AIA-Präsenz von MUST auf SHOULD wechseln, während caIssuers SHOULD und OCSP MAY bleiben? Das etablierte Verfahren kann diese Frage entscheiden.

Danach kontrollieren CAs ihre Ausgabe, Clients ihre Pfadbildung und Server ihre Kette. Das Ballot kann diese Entscheidungen beeinflussen, aber nicht für alle treffen. Ein Fünf-Zustände-Protokoll wahrt diese Grenze.

So wird aus „AIA ist jetzt optional“ eine genaue Aussage über eine Normstufe. Aus „Clients brauchen AIA nicht“ wird ein benannter Test. Aus „die CA hat umgestellt“ wird ein Fingerprint mit Konfigurationsversion.

Der Redline ist zwei Zeilen lang. Die richtige Schlussfolgerung darf ebenso schmal sein; nur der Beleg muss tief genug reichen.

Quellen

  1. Lu Heng, „Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption“
  2. CA/Browser Forum, servercert Pull Request 665 — SC-104
  3. Unveränderlicher SC-104-Vergleich
  4. CA/Browser Forum, servercert Issue 673
  5. Öffentliches Archiv der SC-104-Abstimmungsmitteilung
  6. TLS Baseline Requirements am Ballot-Basis-Commit
  7. Bylaws des CA/Browser Forum
  8. RFC 5280, Abschnitt 4.2.2.1
  9. RFC 2119
  10. RFC 8174
  11. Microsoft, Authority Information Access Retrieval
  12. Mozilla Security Blog, Vorabladen von Zwischen-CA-Zertifikaten in Firefox