search

internetstandards / Internet.nl

Internet standards compliance test suite
https://internet.nl
164 stars 36 forks source link

RFC 9116 may specify that a security.txt expiration date is not valid if it is more than 400 days in the future. #1380

Closed janwillemstegink closed 2 months ago

janwillemstegink commented 3 months ago

RFC 9116 may specify that a security.txt expiration date is not valid if it is more than 400 days in the future. As a result, the intended single annual cycle check is no longer impossible.

Second proposal for RFC 9116: In an office agenda, security.txt can be checked for around New Year's Eve. Rewriting through scripts is not the desired cycle control.

My question to internet.nl is: propose an amendment to RFC 9116. Currently, no tool can truly test. The following is the current RFC text.

2.5.5. Expires

The "Expires" field indicates the date and time after which the data contained in the "security.txt" file is considered stale and should not be used (as per Section 5.3). The value of this field is formatted according to the Internet profiles of [ISO.8601-1] and [ISO.8601-2] as defined in [RFC3339]. It is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness.

This field MUST always be present and MUST NOT appear more than once.

Expires: 2021-12-31T18:37:07z

bwbroersma commented 3 months ago

@janwillemstegink:

It's probably best to suggest the 'it might not be the best idea to use 20xx-12-31' to:

Changing the year to 400 days, or maybe 398 (366+31+1) that is currently the maximum TLS Certificate Lifespan: It would have been best to address this during the draft phase of RFC 9116, when it was draft-foudil-securitytxt (between September 2017 and May 2021).

janwillemstegink commented 3 months ago

Current text in my https://hostingtool.nl/server_headers/ tool:

RFC 9116: The "Expires" field indicates the date and time after which the data contained in the "security.txt" file is considered stale and should not be used (as per Section 5.3).

RFC 9116: It is RECOMMENDED that the value of this field be less than a year into the future to avoid staleness.

Suggestion 1: The file MUST nevertheless expire due to the desirability of an annual audit cycle.

Suggestion 2: For the one-time annual cycle check to work, there is a maximum expiration date of 398 (366+31+1) days into the future, equal to the TLS Certificate Lifespan.

Suggestion 3: Annual audit requires a scheduled date on an office calendar; and customer requests cannot be dealt with if concentrated in one part of the year.

baknu commented 2 months ago

Changing the year to 400 days, or maybe 398 (366+31+1) that is currently the maximum TLS Certificate Lifespan: It would have been best to address this during the draft phase of RFC 9116, when it was draft-foudil-securitytxt (between September 2017 and May 2021).

@janwillemstegink: You could still bring it up at https://github.com/securitytxt/security-txt. But I'm not sure if the authors will pick it up for a new version.

baknu commented 2 months ago

Closing the issue for now, as this is not the right place to further discuss possible changes for RFC 9116.

bwbroersma commented 2 months ago

Issue made upstream: