Evaluate Canonical value of security.txt ?

[baknu]

Currently we do not check the value of the Canonical fields, because we find that its meaning is unclear in the security.txt specification. The latter is only the case when redirects are involved.

This issue is to get more clearity on its meaning when redirects are invloved, and also to discuss if and how we can add a check for this.

Note 1: Clarification question was already asked on securitytxt/security-txt#217
Note 2: The sectxt parser now uses the following interpretation: ""Web URI where security.txt is located must match with a 'Canonical' field. In case of redirecting either the first or last web URI of the redirect chain must match.""

[WKobes]

For the Dutch government this could also identify incorrect redirects.

E.g. https://www.rijksoverheid.nl/.well-known/security.txt would fail because the Canonical URL is https://www.ncsc.nl/.well-known/security.txt

[mxsasha]

If we finally want to do this, we first need to make a final decision on what we see as the requirements for Canonical. We've been pingponging on this for months now :)

[mxsasha]

Final decision:

• If a (or multiple) Canonical field is present, regardless of signature, the last URL in the redirect chain must be listed in a Canonical field, including query string if present.
• If the file is signed, one or more Canonical fields must be present - already tested.

[mxsasha]

#959 adds this and also updates the dependency to 0.8.3.

@baknu we need new labels for errors no_canonical_match, no_csaf_file and multiple_csaf_fields and probably need to update the test description.

As before, DTC's wording does not have to match ours, we only use the same error code. Our interpretation of no_canonical_match is different from DTC, so we definitely should not reuse their error message text there. But I also think their proposed texts for CSAF are not very clear.