from TCADMIN-4265: Link to the request form prepared by the committee: [5]https://raw.githubusercontent.com/oasis-tcs/csaf/master/csaf_2.0/register/security-dot-txt/csaf.txt Field Name: CSAF Description: link to a provider-metadata.json resource of the Common Security Advisory Framework (CSAF) Multiple Appearances: yes Status: current Change controller: OASIS-OPEN Reference: Common Security Advisory Framework Version 2.0 section 7.1.8 "Requirement 8: security.txt" https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html#718-requirement-8-securitytxt [PK discussion or questions:] - is the "provider-metadata.json resource" fully described or exemplified in the specification? -- There is a schema (https://docs.oasis-open.org/csaf/csaf/v2.0/os/schemas/provider_json_schema.json) whose "description" field says: "Representation of metadata information of a CSAF provider as a JSON document." -- Is this schema the same as the "provider-metadata.json resource"?? (Answered in section 7.1.7) -- Why does it have a different name? Text from CSAF v2.0 OS, section 7.1.8: 7.1.8 Requirement 8: security.txt In the security.txt there MUST be at least one field CSAF which points to the provider-metadata.json (requirement 7) [PK note: see text from section 7.1.7 below]. If this field indicates a web URI, then it MUST begin with "https://" (as per section 2.7.2 of [RFC7230]). See [SECURITY-TXT] for more details. The security.txt was published as [RFC9116] in April 2022. At the time of this writing, the CSAF field is in the process of being officially added. Examples 125: CSAF: https://domain.tld/security/data/csaf/provider-metadata.json CSAF: https://psirt.domain.tld/advisories/csaf/provider-metadata.json CSAF: https://domain.tld/security/csaf/provider-metadata.json CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json It is possible to advertise more than one provider-metadata.json by adding multiple CSAF fields, e.g. in case of changes to the organizational structure through merges or acquisitions. However, this SHOULD NOT be done and removed as soon as possible. If one of the URLs fulfills requirement 9, this MUST be used as the first CSAF entry in the security.txt. Text from CSAF v2.0 OS, section 7.1.7: (initial lines - listed here since it is linked from section 7.1.8): 7.1.7 Requirement 7: provider-metadata.json The party MUST provide a valid provider-metadata.json according to the schema "CSAF provider metadata" [https://docs.oasis-open.org/csaf/csaf/v2.0/provider_json_schema.json] for its own metadata. [pk note - the URI is not visible in the specification (it is hyperlinked), and it is the "Latest stage" link.] Description of the security.txt registration process, from https://www.rfc-editor.org/rfc/rfc9116.html#name-registry-for-securitytxt-fi : 6.2. Registry for security.txt Fields IANA has created the "security.txt Fields" registry in accordance with [RFC8126]. This registry contains fields for use in "security.txt" files, defined by this specification. New registrations or updates MUST be published in accordance with the "Expert Review" guidelines as described in Sections 4.5 and 5 of [RFC8126]. [pk - see info from these sections below] Any new field thus registered is considered optional by this specification unless a new version of this specification is published. Designated experts should determine whether a proposed registration or update provides value to organizations and researchers using this format and makes sense in the context of industry-accepted vulnerability disclosure processes such as [ISO.29147.2018] and [CERT.CVD]. New registrations and updates MUST contain the following information: Name of the field being registered or updated Short description of the field Whether the field can appear more than once New or updated status, which MUST be one of the following: current: The field is in current use. deprecated: The field has been in use, but new usage is discouraged. historic: The field is no longer in current use. Change controller The document in which the specification of the field is published (if available) Existing registrations may be marked historic or deprecated, as appropriate, by a future update to this document. Sections 4.5 and 5 of [RFC8126] (https://www.rfc-editor.org/rfc/rfc8126.html) [PK - linked from section 6.2 above] (https://www.rfc-editor.org/rfc/rfc8126.html#section-4.5) - Expert Review (https://www.rfc-editor.org/rfc/rfc8126.html#section-5) - Designated Experts Also see section 4.6 - Specification Required For the Specification Required policy, review and approval by a designated expert (see Section 5) is required, and the values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. This policy is the same as Expert Review, with the additional requirement of a formal public specification. In addition to the normal review of such a request, the designated expert will review the public specification and evaluate whether it is sufficiently stable and permanent, and sufficiently clear and technically sound to allow interoperable implementations. [...] Useful info: - https://www.iana.org/help/protocol-registration