Verifying policy authenticty about security-txt HOT 5 CLOSED

Hi @jskiba99,

This is a valid concern and thank you for raising this issue. Currently my thought is to work together with different companies in the industry to make this work. Essentially we could solve many problems (#14) with an external service/index that monitors security.txt files. Several companies have volunteered to be in charge of this and I hope that we can open source a tool that monitors security.txt files at some point to allow others to follow suit.

I would love to hear your thoughts on this and do you have any other suggestions/possible solutions?

from security-txt.

Would allowing a PGP or S/MIME signature for the security.txt file help here? Combined with some sort of DNS-based (like DANE) or web based PKI, it may be possible to verify the signature then.

from security-txt.

We also should clarify what the thread model is and what can happen if the file is compromised or forged. I assume if that happens, the attacker can now start collecting security reports about a domain and can hone their attacks further.

Good example of this modeling discussion can be found in the ACME protocol that is used by LetsEncrypt:
https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-10

It also seems from ACME that HTTP challenges are good enough of a proof to issue SSL certificates. If the level of threat is the same as here, then maybe authentication may not be as important.

One more idea to throw out - we can also require or recommend that "security.txt" files be always loaded over a valid TLS connection. Not sure if that will actually work in real life.

from security-txt.

I like the idea of requiring security.txt be loaded over HTTPS, but a lot of small companies rely on cheap Web hosting that only supports HTTP. To ensure the widest adoption, I think the next draft of the RFC should read "security.txt SHOULD be loaded over HTTPS" rather than "MUST be loaded."

With that in mind, having some kind of second factor to authenticate the security.txt file would be a great enhancement. There could be a line such as PGP-Signature: <url> for detached signatures, or the RFC could be amended to allow for inline signatures, with something along the lines of, To allow security.txt to be cryptographically signed with PGP, user agents MUST ignore any lines not in the 'Thing: Value' format.

from security-txt.

This issue has been resolved in 53931bd. The section still needs a lot of work, but the general idea is already there.

from security-txt.