Individual Submission J. Bruhns Internet-Draft 10 September 2026 Intended status: Informational Expires: 14 March 2027 Product Security Fields for security.txt draft-bruhns-securitytxt-product-security-00 Abstract This document registers two new fields for the security.txt file format defined in RFC 9116: "Product-Security" and "Product-Security- Policy". They allow an organisation to publish a dedicated contact and disclosure policy for vulnerabilities in the products it manufactures, distinct from the contact for vulnerabilities in its own web presence and infrastructure. The fields are optional and fully backward compatible with existing security.txt parsers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Bruhns Expires 14 March 2027 [Page 1] Internet-Draft security.txt Product Security September 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Product-Security . . . . . . . . . . . . . . . . . . . . 3 3.2. Product-Security-Policy . . . . . . . . . . . . . . . . . 4 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction RFC 9116 [RFC9116] defines security.txt as a machine-readable file that tells security researchers where to report security issues. Its "Contact" field is deliberately generic: it does not distinguish between a vulnerability in the organisation's website and a vulnerability in a product the organisation sells. For many organisations these are handled by different teams. Website and infrastructure issues are typically owned by IT operations; product vulnerabilities are handled by a Product Security Incident Response Team (PSIRT) and follow a separate coordinated vulnerability disclosure (CVD) process with its own timelines and, increasingly, regulatory reporting obligations. Bruhns Expires 14 March 2027 [Page 2] Internet-Draft security.txt Product Security September 2026 Recent regulation has made this distinction more relevant. The EU Cyber Resilience Act [CRA] requires manufacturers to publish a contact address and a CVD policy for their products, and national guidance such as [BSI-TR-03183-3] recommends fulfilling that requirement by means of the security.txt file. As a result, a single security.txt file is now expected to serve two audiences with different needs, and reporters have no reliable way to tell which "Contact" entry is intended for which purpose. This document defines two optional fields that make the product- security contact and policy explicit while leaving the semantics of existing fields unchanged. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms "field", "field name", and "field value" are used as defined in Section 2 of [RFC9116]. "Product" is used in the sense of a hardware or software product supplied by the organisation to third parties, as opposed to the organisation's own web presence, infrastructure, or internal systems. 3. Field Definitions Both fields follow the general syntax of Section 2 of [RFC9116]: a field name, a colon, optional whitespace, and a field value, terminated by a line ending. Field names are case-insensitive. 3.1. Product-Security The "Product-Security" field indicates a means of contacting the organisation about security vulnerabilities in products it manufactures or maintains. The value MUST be a URI as defined in [RFC3986]. The same schemes and constraints apply as for the "Contact" field in Section 2.5.3 of [RFC9116]; in particular, "https" and "mailto" URIs are expected, and web URIs MUST use "https". The field MAY appear more than once. When it does, the order of the entries indicates the organisation's order of preference, with the first entry being the preferred one. Bruhns Expires 14 March 2027 [Page 3] Internet-Draft security.txt Product Security September 2026 If the organisation operates a PSIRT or equivalent function, the first "Product-Security" entry SHOULD be the functional mailbox or reporting endpoint of that function. The presence of a "Product-Security" field does not change the meaning of the "Contact" field. Reporters who cannot determine whether an issue relates to a product or to infrastructure SHOULD use "Contact". 3.2. Product-Security-Policy The "Product-Security-Policy" field indicates a link to the organisation's coordinated vulnerability disclosure policy for its products. The value MUST be an "https" URI. The linked policy SHOULD describe at least: the scope of products covered, how reports are acknowledged and triaged, expected response times, the organisation's approach to public disclosure and embargo periods, whether anonymous reports are accepted, and any assurances given to good-faith reporters. [ISO29147] provides guidance on the content of such policies. The field MUST NOT appear more than once. 4. Formal Syntax The following ABNF [RFC5234] extends the grammar in Section 4 of [RFC9116]. The rules "uri", "unstructured-field", "eol", and "WSP" are imported from that document. product-security-field = "Product-Security" ":" *WSP uri eol product-security-policy-field = "Product-Security-Policy" ":" *WSP uri eol Implementations parsing security.txt files MUST treat these fields as extension fields in the sense of Section 2.5 of [RFC9116] when they do not recognise them. 5. Examples A manufacturer whose IT department handles website issues and whose PSIRT handles product issues: Bruhns Expires 14 March 2027 [Page 4] Internet-Draft security.txt Product Security September 2026 Contact: mailto:security@example.com Product-Security: mailto:psirt@example.com Product-Security: https://example.com/psirt/report Product-Security-Policy: https://example.com/psirt/cvd-policy Expires: 2027-09-10T22:00:00.000Z Preferred-Languages: en, de Canonical: https://www.example.com/.well-known/security.txt An organisation whose single security team handles both, and that wishes to make the product policy discoverable without duplicating contacts: Contact: mailto:security@example.com Product-Security-Policy: https://example.com/security/product-cvd Expires: 2027-09-10T22:00:00.000Z 6. Backward Compatibility Section 2.5 of [RFC9116] requires implementations to ignore fields they do not recognise. Files that use the fields defined here therefore remain valid security.txt files for all conforming parsers, and existing "Contact" entries continue to work unchanged. Organisations SHOULD continue to provide at least one "Contact" entry that accepts product-related reports, so that reporters using tools unaware of this specification are still able to reach the organisation. 7. Security Considerations The security considerations of [RFC9116] apply in full. In particular, the fields defined here are only as trustworthy as the server delivering the file, and an attacker who can modify the file can redirect product vulnerability reports. Organisations SHOULD sign the file as described in Section 2.3 of [RFC9116] and SHOULD ensure that the "Canonical" field is present so that reporters can detect copies served from unexpected locations. Separating product-security contacts from infrastructure contacts may make it easier for an attacker to identify the PSIRT mailbox for phishing or denial-of-service purposes. This information is normally public in any case and the benefit of reliable routing of reports is judged to outweigh this risk. Bruhns Expires 14 March 2027 [Page 5] Internet-Draft security.txt Product Security September 2026 8. IANA Considerations IANA is requested to add the following entries to the "security.txt Fields" registry established by Section 6.2 of [RFC9116], following the Expert Review procedure of [RFC8126]. Field Name: Product-Security Description: Contact for reporting vulnerabilities in the organisation's products Multiple Appearances: Yes Published in: This document Status: current Change controller: IETF Field Name: Product-Security-Policy Description: Link to the organisation's coordinated vulnerability disclosure policy for its products Multiple Appearances: No Published in: This document Status: current Change controller: IETF 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Bruhns Expires 14 March 2027 [Page 6] Internet-Draft security.txt Product Security September 2026 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in Security Vulnerability Disclosure", RFC 9116, DOI 10.17487/RFC9116, April 2022, . 9.2. Informative References [BSI-TR-03183-3] Bundesamt für Sicherheit in der Informationstechnik, "Technical Guideline BSI TR-03183-3: Vulnerability Reports and Notifications", August 2025, . [CRA] European Parliament and Council, "Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)", October 2024, . [ISO29147] ISO/IEC, "ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure", 2018. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Author's Address Jannick Bruhns Email: security@nyze.one Bruhns Expires 14 March 2027 [Page 7]