Summary

  • draft-bruhns-securitytxt-product-security-00, posted on 10 September 2026, proposes optional Product-Security and Product-Security-Policy fields for the RFC 9116 format.
  • The first field points to product-vulnerability contacts; the second points to an HTTPS policy expected to describe scope, triage and disclosure practice.
  • The document is an individual Internet-Draft, not an adopted IETF work item, approved standard or registered extension. IANA does not currently list either field.
  • Separating receiving queues does not establish responsibility for a particular model, version, redistributed build or unsupported release. A useful handoff therefore needs an artifact-to-owner receipt.

The report reached a product team — but which product?

Consider a researcher holding a firmware image from a network appliance sold under one brand, manufactured by another company and maintained through a regional distributor. The brand’s security.txt file contains a product-specific address. The message is delivered and acknowledged. None of those observations establishes whether the receiving team owns that model, the affected version or the component in question.

This is not the familiar problem of an abandoned disclosure mailbox. The route can be live. The gap appears one decision later, when the receiver must accept the artifact into its scope, redirect it with evidence, or explain that another maintainer owns the branch. A contact URI answers “where should a report start?” It does not answer “who has taken responsibility for this exact thing?”

The distinction matters because products move while domains remain still. A product line can be acquired, white-labelled, forked, placed into maintenance-only status or abandoned. The same vulnerability may affect a library shipped by several vendors. A file published from a corporate web origin cannot encode those transitions merely by naming a more specialised inbox.

What revision 00 actually proposes

The Datatracker record identifies Product Security Fields for security.txt as an individual Internet-Draft. Its history contains revision 00, posted on 10 September 2026. Anyone may submit an Internet-Draft; this status does not confer IETF endorsement or formal standards standing.

The draft text adds two optional fields to the format defined by RFC 9116. Product-Security carries a URI through which product vulnerabilities can be reported. It may appear more than once, and the order expresses the publisher’s preference, following the same URI constraints used for Contact.

Product-Security-Policy carries one HTTPS URI. The linked policy should address product scope, acknowledgement and triage, expected response times, disclosure and embargo practices, anonymous reporting and assurances for good-faith research. That list makes scope visible as a governance concern. It does not turn the policy page into proof that the reporter’s model and version are covered.

The proposal also preserves a deliberate fallback. Existing parsers must ignore unknown extension fields under RFC 9116. Publishers are therefore advised to keep the ordinary Contact route able to receive product reports. A new label can improve routing without making old software fail closed.

The registry has not moved

The draft asks IANA to add both field names under Expert Review. The current IANA security.txt fields registry does not contain them. It lists established fields such as Contact, Expires, Canonical, Encryption, Policy and Preferred-Languages, alongside later registered extensions including CSAF, Bug-Bounty and Hiring.

That absence is an important part of the news. An IANA considerations section is a request about a possible future registry state. It is not the state itself. RFC 8126 describes Expert Review as a registration policy in which designated experts evaluate requests against the registry’s rules. The review cannot be replaced by a publisher pre-emptively treating an unregistered name as universally recognised.

Experimentation can still occur because RFC 9116 tells parsers to ignore unrecognised extensions. But an experiment should be labelled as such. Operators need to distinguish a locally understood field from an allocated, interoperable field and from a field implemented across a measurable population of parsers.

A web origin is not a product catalogue

RFC 9116’s ordinary scope follows the place from which the file is retrieved. A file found for a domain or IP address applies to that resource; it does not automatically govern parent domains or subdomains. The RFC permits an organisation to publish information concerning its products and services, yet it does not define a registry of product models, versions or maintainers.

That leaves a join for the policy document to perform. The reporter has an artifact: perhaps a package coordinate, hardware model, serial family, firmware release or commit. The publisher has an origin and a policy. The receiver has a queue. Unless one side records how those identifiers match, later reviewers see only a successful delivery to a branded domain.

Brand is especially weak evidence after acquisitions and licensing arrangements. A distributor may accept the first report while a manufacturer controls the patch. A cloud service may embed an open-source component whose upstream project needs a coordinated disclosure. An end-of-life product may still be deployed even though no current team accepts remediation duty. The correct route can change with the artifact’s version.

The proposed policy field is useful precisely because it can describe these cases. Its governance value depends on the specificity and versioning of the linked policy, not on the presence of the field alone.

Trust remains attached to publication

RFC 9116 requires an Expires value so stale contact data can be recognised. It provides Canonical to identify the intended location and recommends signing the file. Its security considerations are blunt: if an attacker can alter the publication surface, the attacker can redirect a researcher to a contact under their control.

Those protections are necessary but not sufficient for product scope. A valid signature shows continuity with a signing key, not that the signer owns a component. A canonical URI identifies the chosen copy of a file, not the applicable product inventory. A future Product-Security field can name the intended first hop without attesting to the downstream handoff.

The RFC also keeps authorisation separate. Finding or failing to find a security.txt file neither grants nor denies permission to test a system. A product-security policy may state safe-harbour terms, but an index entry cannot be assumed to confer legal coverage across jurisdictions, products and methods.

Keep the artifact-to-owner handoff

A product-routing receipt should begin with the identifiers the reporter supplied: product family, model, package or component coordinate, version, build, firmware branch and distribution channel, where those facts are known. It should retain the origin and canonical URL of the security.txt file, its retrieval time, Expires value, signature result and the exact Product-Security entry selected, including its preference position.

The receipt should then preserve the Product-Security-Policy URL and a content hash or policy version. The receiver should record which scope clause caused acceptance, rejection or redirection, which team took custody, and the case or handoff identifier returned. Sensitive vulnerability detail need not enter a public registry; the point is to preserve the decision boundary.

This receipt is Daniel Kade’s editorial proposal, not a requirement in revision 00, RFC 9116 or the IANA registry. It complements, rather than repeats, the need to test whether a contact route is live. A live inbox proves reception. An artifact-to-owner receipt proves which responsibility decision followed.

Sources