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.

[mxsasha]

There's a bug here: when testing for internet.nl the found_url is https://internet.nl:443/.well-known/security.txt. This then does not match Canonical. May be a side effect from changing HTTP clients.

[baknu]

@mxsasha It seems better to wait and do this when we upgrade to the upcoming sectxt version 0.9.1 (see #1046). Right?

[mxsasha]

@mxsasha It seems better to wait and do this when we upgrade to the upcoming sectxt version 0.9.1 (see #1046). Right?

The canonical check is already done. The code is merged, we are upgraded to 0.8.3 in #959 and the bug I mentioned on June 8th is fixed. Only content is pending, included in https://github.com/internetstandards/Internet.nl_content/pull/41

[baknu]

@mxsasha: Content is ready. Could you check? Thanks.

[baknu]

Processed feedback from @mxsasha