Zusammenfassung

  • IESG eröffnete am 2. September den Last Call zur Revision 29 des Entwurfs für Attestierungen in Zertifikatsanträgen. Stellungnahmen sind bis zum 16. September vorgesehen.
  • Unterstützen mehrere Verifier dieselbe Format-OID, muss die jeweilige Formatspezifikation die Auswahl klären. Ein gemeinsamer Decoder ersetzt diese Zuordnung nicht.

Bei einer Schnittstelle lässt sich vergleichsweise leicht prüfen, ob zwei Produkte dasselbe Datenformat lesen. Schwieriger kann die Frage sein, ob sie auch dieselbe Entscheidung darüber treffen, wohin diese Daten zur Prüfung gelangen sollen. Für Zertifikatsanträge mit Gerätenachweisen macht ein aktueller IETF-Entwurf diese zweite Aufgabe ausdrücklich sichtbar.

Der Last Call vom 2. September betrifft draft-ietf-lamps-csr-attestation-29. IESG erwägt den Status Proposed Standard und bittet bis zum 16. September um Stellungnahmen. Es handelt sich weiterhin um einen Arbeitsentwurf, nicht um einen bereits gebilligten RFC oder einen Nachweis produktiver Einführung.

Vorgesehen ist eine gemeinsame Struktur, um Remote-Attestierungen in PKCS#10- und CRMF-Anträgen zu transportieren. Standardisierte und proprietäre Formate sind möglich. Zertifizierungs- oder Registrierungsstellen, CA beziehungsweise RA, können selbst prüfen oder einen externen Verifier einschalten.

Die Auswahl gehört zum Formatvertrag

Abschnitt 4.3 der Revision 29 behandelt den Fall, dass mehrere Verifier dieselbe Objektkennung, OID, eines Attestierungsformats unterstützen. Der Entwurf empfiehlt unterschiedliche OIDs für Verifier- oder Prüfarten, selbst bei identischer Struktur, oder einen zusätzlichen Wrapper mit einem ausdrücklichen Hinweis. Die genaue Auswahl von Nonce und Verarbeitungsweg soll die Formatspezifikation festlegen.

Eine OID ist hier keine Serveradresse. Sie bezeichnet ein Format, das mehrere Dienste verstehen können. Welcher Verarbeitungskontext gemeint ist, braucht eine weitere Vereinbarung. Der gemeinsame Entwurf benennt die zuständige Spezifikation, statt für sämtliche Formate denselben Auswahlmechanismus festzuschreiben.

Damit entsteht eine konkrete Kontrollfrage: Wer pflegt im Betrieb die Zuordnung zwischen eingehendem Nachweis und prüfendem Dienst? Eine Änderung dieser Zuordnung kann den Bearbeiter wechseln, ohne das Datenformat zu verändern. Eine aussagekräftige Kompatibilitätserklärung sollte deshalb die verwendete Auswahlkonvention und das Verhalten bei fehlenden oder widersprüchlichen Hinweisen erklären.

Zwei Kennungsebenen, verschiedene Aufgaben

Die IANA-Tabelle der S/MIME-Attribute führt den Wert 59 zum Prüfzeitpunkt noch als id-aa-evidence. Revision 29 beantragt die Umbenennung in id-aa-attestation, ohne den Zahlenwert zu ändern. Das betrifft das äußere CSR-Attribut und kein Verzeichnis zugelassener Prüfdienste.

Die OIDs der darin transportierten Attestierungsformate liegen auf einer anderen Ebene. Nach Abschnitt 4.2 vergeben die Autoren der jeweiligen Formate diese aus Kennungszweigen, die sie kontrollieren. Der äußere Registereintrag erklärt daher nicht, welche Zuordnung ein konkreter Betreiber implementiert hat.

Warum das relevant ist, zeigt RFC 9334. Der Eigentümer des Verifiers legt dessen Bewertungsregeln für Evidence fest; der Eigentümer der Relying Party bestimmt die Verwendung des Ergebnisses. Ein Ziel kann somit auch einen Bewertungskontext auswählen und nicht nur eine Software, die die Bytes lesen kann. Eine Organisation darf beide Rollen übernehmen, ohne dass sie sachlich zusammenfallen.

Ein Betreiber könnte die dokumentierten Auswahlbedingungen bei gleichbleibendem Format durchspielen und den tatsächlich angesprochenen Verifier kontrollieren. Das ist ein hier vorgeschlagener Integrationstest, keine zusätzliche IETF-Vorschrift. Die nachfolgende Sicherheitsprüfung bleibt ebenfalls nötig: Revision 29 belässt die Verantwortung für die Bindung der Attestierungen an den beantragten öffentlichen Schlüssel bei CA oder RA.

Die ausgewerteten Quellen belegen weder einen Fehlleitungsfall noch gemessene Wechselkosten. Der Nachrichtenanlass ist die nun im Last Call überprüfbare Arbeitsteilung. Ein gemeinsamer Transport kann Schnittstellenarbeit sparen; austauschbare Verarbeitung setzt zusätzlich eine klare Auswahlvereinbarung voraus.

Quellen

  1. Last-Call-Mitteilung von IESG
  2. CSR-Attestierungsentwurf, Revision 29
  3. RATS-Architektur, RFC 9334
  4. SMI-Registrierungen bei IANA