Validate new CSAF field

[WKobes]

The 'CSAF'-field is now part of the security.txt fields registry (https://www.iana.org/assignments/security-txt-fields/security-txt-fields.xhtml). This field should be accepted without raising the unknown_field notification.

It was added on 2023-02-15.

Validating it as a URI-field should be sufficient, as it probably goes beyond the scope of this parser to check if the field complies with the OASIS specification.

[baknu]

For some further details see CSAF specification under:

• https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#718-requirement-8-securitytxt
• https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#731-finding-provider-metadatajson

See also: https://www.rfc-editor.org/rfc/rfc9116.html#section-2.4 ("Any fields registered via that process MUST be considered optional.")

Possible additional checks:

• URI to begin with "https://"
• URI to end with "provider-metadata.json"
• In case of multiple CSAF fields maybe give a notification

Example of a security.txt with CSAF field: https://www.bsi.bund.de/.well-known/security.txt

[DigitalTrustCenter]

#47 Validate new CSAF field
new key for CSAF field, it is considered optional as per the section 2.4 mentioned by @baknu. If not present a recommendation is added:

new recommendation.

• "no_csaf": 'CSAF' field should appear at least once.
• If no CSAF field is found this recommendation is given.
  new error:
• no_csaf_file: All CSAF field in the securtiy.txt must point to a provider-metadata.json file
  new notification:
• multiple_csaf_fields: It is allowed to have more than one CSAF field, however this should be removed if possible.
  added multiple tests for the new key and added recommdation, error and notification.

[baknu]

Thanks.

Some remarks:

1. As the CSAF field is OPTIONAL (thus MAY, and not SHOULD or MUST), it should be treated the same way as other optional fields (like "Acknowledgments" and "Hiring"). So there should not be a given a recommendation message when the CSAF field is missing.
   However when it is present then indeed the "no_csaf_file" message and the "multiple_csaf_fields" message could be given in case deviations are detected.

2. The "multiple_csaf_fields" message should be a recommendation, as the used language (also in the specification) is SHOULD (NOT).

3. Some textual nits:

• "All CSAF field in the security.txt must point to a provider-metadata.json file" --> "All CSAF fields must point to a provider-metadata.json file."

[DigitalTrustCenter]

These changes have been applied in the new release.

• The CSAF field is now optional (like "Acknowledgments" and "Hiring") so the recommendation is removed. The errors remain, if the field is listed with an issue it will throw an error.
• The "multiple_csaf_fields" has been moved from a notification to a recommendation.
• The "no_csaf_file" text has been updated to be more clear.