]>

security@nyze.one

Security Individual Submission security.txt vulnerability disclosure PSIRT CRA 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.

Introduction RFC 9116 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. Recent regulation has made this distinction more relevant. The EU Cyber Resilience Act requires manufacturers to publish a contact address and a CVD policy for their products, and national guidance such as 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.

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 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 . "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.

Field Definitions Both fields follow the general syntax of Section 2 of : a field name, a colon, optional whitespace, and a field value, terminated by a line ending. Field names are case-insensitive.

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 . The same schemes and constraints apply as for the "Contact" field in Section 2.5.3 of ; 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. 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".

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. provides guidance on the content of such policies. The field MUST NOT appear more than once.

Formal Syntax The following ABNF extends the grammar in Section 4 of . The rules "uri", "unstructured-field", "eol", and "WSP" are imported from that document.

Implementations parsing security.txt files MUST treat these fields as extension fields in the sense of Section 2.5 of when they do not recognise them.

Examples A manufacturer whose IT department handles website issues and whose PSIRT handles product issues:

An organisation whose single security team handles both, and that wishes to make the product policy discoverable without duplicating contacts:

Backward Compatibility Section 2.5 of 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.

Security Considerations The security considerations of 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 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.

IANA Considerations IANA is requested to add the following entries to the "security.txt Fields" registry established by Section 6.2 of , following the Expert Review procedure of .

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

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. European Parliament and Council Bundesamt für Sicherheit in der Informationstechnik ISO/IEC