This is a good idea, but won’t help the most severe issue: many companies don’t want to know about security flaws and will prosecute people who report them as “hackers.” You rely on their good intentions when you responsibly disclose things to them.
I like the idea, although the field “Disclouse:Full/Partial/None” is too open to interpretation to be useful I think.
Another issue is that whilst the RFC request the PGP key be served over HTTPS, it doesn’t specify that security.txt also be served over HTTPS. This makes the PGP key HTTPS irelevant, as an attacker could MiTM and specify a different location for the file.
This is a good idea, but won’t help the most severe issue: many companies don’t want to know about security flaws and will prosecute people who report them as “hackers.” You rely on their good intentions when you responsibly disclose things to them.
Some problems cannot be fixed by technology.
I like the idea, although the field “Disclouse:Full/Partial/None” is too open to interpretation to be useful I think.
Another issue is that whilst the RFC request the PGP key be served over HTTPS, it doesn’t specify that security.txt also be served over HTTPS. This makes the PGP key HTTPS irelevant, as an attacker could MiTM and specify a different location for the file.
HTTPS is useless if the attacker can MITM the server, since the attacker can just obtain a LetsEncrypt certificate.
If you are worried about the attacker MITM you, then you should try from multiple locations.