Zusammenfassung

  • draft-bruhns-securitytxt-product-security-00 vom 10. September 2026 schlägt die optionalen Felder Product-Security und Product-Security-Policy für das Format aus RFC 9116 vor.
  • Das erste nennt Kontakt-URIs für Produktschwachstellen; das zweite verweist auf eine HTTPS-Richtlinie zu Geltungsbereich, Triage, Reaktionszeit und Offenlegung.
  • Das Dokument ist ein individueller Internet-Draft, kein angenommenes Arbeitspapier einer IETF-Arbeitsgruppe und kein verabschiedeter Standard. Bei IANA sind beide Felder derzeit nicht eingetragen.
  • Getrennte Eingänge verbessern die erste Zuordnung, binden aber Modell, Version, weitervertriebenen Build oder Fremdkomponente nicht an den tatsächlich verantwortlichen Akteur.

Eine grüne Zustellung kann vor einer roten Zuständigkeit enden

Ein Forscher meldet einen Fehler in der Firmware eines Geräts. Die Marke veröffentlicht einen Produktsicherheitskontakt, das Ticket-System bestätigt den Eingang und die Transportprotokolle zeigen keine Störung. Erst in der Triage stellt sich heraus, dass die betroffene Baureihe vor Jahren verkauft wurde und die alte Firmware von einem Vertragspartner betreut werden sollte.

Der Meldeweg hat funktioniert. Trotzdem ist noch offen, wer den Code ändern, ein Update signieren und den Offenlegungszeitpunkt abstimmen kann. Eine URI bestimmt den ersten Empfänger. Sie weist ihm nicht automatisch die Verantwortung für jedes Produkt zu, das denselben Markennamen trägt.

Produktgrenzen bewegen sich schneller als Webadressen. Übernahmen, White-Label-Vertrieb, ausgelaufener Support und eingebettete Open-Source-Komponenten zerlegen die vermeintlich einfache Beziehung zwischen Marke und Hersteller. Ein spezialisiertes Postfach macht diese Geschichte nicht von selbst sichtbar.

Der Entwurf schlägt zwei optionale Bausteine vor

Im Datatracker ist Product Security Fields for security.txt als individueller Internet-Draft geführt. Die Historie enthält zum Stichtag nur Version 00 vom 10. September. Das ist eine öffentlich prüfbare Vorlage, aber weder IETF-Unterstützung noch Arbeitsgruppenannahme noch RFC-Status.

Der Text der Version 00 erlaubt mehrere Product-Security-Zeilen. Jede enthält eine URI für Meldungen über Produktschwachstellen und übernimmt die URI-Bedingungen von Contact. Die Reihenfolge zeigt die Präferenz des Herausgebers.

Product-Security-Policy darf einmal vorkommen und muss auf eine HTTPS-Ressource verweisen. Die Richtlinie soll den Produktumfang, Bestätigung und Triage, erwartete Reaktionszeiten, Offenlegung und Embargo, anonyme Meldungen und Zusicherungen für Forschung in gutem Glauben beschreiben.

Damit bekommt die Umfangsfrage einen vorgesehenen Ort. Der Verweis sagt aber nicht, ob die Seite ein konkretes Modell nennt, alte Versionen trennt oder einen aktuellen Betreuer ausweist. Ein Link ist noch keine Zuordnungsentscheidung.

Der IANA-Registerstand ist unverändert

Der Entwurf beantragt zwei Einträge nach dem Verfahren Expert Review. Im aktuellen IANA-Register für security.txt-Felder stehen weder Product-Security noch Product-Security-Policy. Eingetragen sind unter anderem Contact, Expires, Canonical, Encryption, Policy und Preferred-Languages sowie spätere Erweiterungen wie CSAF, Bug-Bounty und Hiring.

Ein Antrag darf nicht als Zuteilung berichtet werden. RFC 8126 beschreibt Expert Review als Prüfung eines Registrierungswunsches durch benannte Fachleute anhand der geltenden Regeln. Der Abschnitt eines individuellen Entwurfs nimmt dieses Ergebnis nicht vorweg.

Lokale Versuche bleiben möglich. RFC 9116 verlangt, unbekannte Erweiterungsfelder zu ignorieren. Deshalb empfiehlt der neue Text, den allgemeinen Contact-Weg weiterhin für Produktmeldungen offenzuhalten. Alte Parser behalten einen Ausgang; allgemeine Interoperabilität ist damit noch nicht belegt.

Der Fundort ist keine Produktstückliste

RFC 9116 bindet den gewöhnlichen Geltungsbereich an die Ressource, für die die Datei abgerufen wurde. Eine Datei für eine Domain oder IP-Adresse gilt nicht automatisch für Eltern- oder Subdomains. Organisationen dürfen darin Informationen über Produkte und Dienste veröffentlichen, doch das Format verwaltet keine Modelle, Versionen und Betreuerwechsel.

Auf der einen Seite stehen Artefaktdaten: Paketkoordinate, Baureihe, Serienbereich, Version, Build, Firmware-Zweig oder Commit. Auf der anderen stehen Webursprung, Richtlinie und Warteschlange. Für eine belastbare Übergabe muss festgehalten werden, warum beides zusammengehört.

Ohne diesen Beleg sieht eine spätere Prüfung nur, dass die Meldung an eine Markendomain ging. Sie zeigt nicht, ob der Empfänger den betroffenen Release annahm, an einen Zulieferer weiterleitete oder eine inzwischen geänderte Richtlinie anwendete. Eine aktuelle Webseite kann die damalige Grenze nicht ersetzen.

Signatur und Canonical belegen Veröffentlichung, nicht Fachzuständigkeit

RFC 9116 verlangt Expires, stellt Canonical bereit und empfiehlt eine Signatur. So lassen sich veraltete Koordinaten, unbeabsichtigte Kopien und Manipulationen besser erkennen. Wer den Publikationsserver kompromittiert, könnte Forschende sonst auf einen eigenen Kontakt umleiten.

Diese Kontrollen beantworten jeweils eine begrenzte Frage. Eine gültige Signatur bindet Inhalt an einen Schlüssel, nicht eine Komponente an einen Wartungsvertrag. Eine Canonical-URI bestimmt die beabsichtigte Datei, nicht die gedeckte Produktversion. Ein zukünftiges Ablaufdatum belegt keine Fallübernahme.

Auch die Erlaubnis zum Testen bleibt getrennt. Das Vorhandensein oder Fehlen von security.txt erteilt und entzieht keine Autorisierung. Eine Produktrichtlinie kann Zusicherungen nennen; ihr sachlicher und rechtlicher Umfang muss aus der konkreten Fassung hervorgehen.

Die Übergabe vom Artefakt zum Verantwortlichen festhalten

Ein Produkthandlungsbeleg beginnt mit den Angaben aus der Meldung: Familie, Modell, Komponente oder Paket, Version, Build, Firmware-Zweig und Vertriebsweg, soweit bekannt. Hinzu kommen Ursprung und Canonical-URL der security.txt, Abrufzeit, Expires, Signaturergebnis und der gewählte Product-Security-Eintrag samt Präferenzrang.

Außerdem braucht es die Product-Security-Policy-URL und einen Inhalts-Hash oder Versionsstand. Der Empfänger dokumentiert, welche Umfangsklausel Annahme, Ablehnung oder Weiterleitung begründete, welches Team die Verwahrung übernahm und welche Fall- oder Übergabenummer entstand. Vertrauliche Schwachstellendetails müssen dafür nicht öffentlich werden.

Dieser Beleg ist ein redaktioneller Vorschlag von Daniel Kade, keine Pflicht aus Version 00, RFC 9116 oder dem IANA-Register. Er setzt hinter der Erreichbarkeitsprüfung an. Das lebende Postfach belegt Empfang; der Artefaktbeleg hält die anschließende Verantwortungsentscheidung fest.

Quellen