New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow already created files to be served by us #62
Comments
Can you fill me in on what's the context of the private key that need to be provided to our lib? I think I'm missing a feature of a signed security.txt file. |
Currently, our library generates the security.txt file based on an object representing it. Previously, there used to be a "Signature" directive which was a URI to an external signature file: I'm not sure exactly what the format of it was, but it allowed the signing process to be external to our library since the user was responsible for creating a signature file. The purpose of signing the security.txt file is that if an attacker somehow manages to take control of the security.txt file, security researchers will not trust the file at all and pretend it doesn't exist, so as to make sure vulnerabilities aren't reported to attackers, etc. In more recent versions, signatures have to be inline. Yet if we are generating the security.txt file like we are now, then if someone wants to sign the security.txt file and we are generating the files on the spot, then we need the private key to do the signing. To get around this, I propose that if someone does want to sign their security.txt file, they can do that themselves (keeping the private key needed for signing far away from the security.txt host) and then feed the signed file to us. Our library already validates the security.txt objects fed to it and we can do that for these static signed files too. Our library will also be responsible for hosting the file in two locations: /security.txt and /.well-known/security.txt. The only part that our library won't be doing is generating the signed file, because I think that would have security-related problems. |
Thanks for the elaborate explanation @joker314 👌 Completely agree. So we would actually receive the input for the file to display rather than generate on the fly. |
We could add a validator which will take an existing security.txt file (which may or may not be signed), validate it, and host it at both the well-known path and the root.
Thoughts?
It solves the issue of not giving our library the private key.
The text was updated successfully, but these errors were encountered: