Checksum, hashing and notification

[Hyperpolymath]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Just background
There is a risk that someone might tamper with email addresses/contact details such that it is routed to some cracker, or whatever might be in the security.txt file. Then someone comes along, thinking that is the correct one, send information on vulnerabilities to that]
There are increasingly extensions that make it much easier to know if there is a security.txt file, and if hacking for good reasons is welcome, and if someone is not wrapping up that info and just sending it in genuine belief but mistakenly to a competitor or to a hacker or even routed to something like Pastebin or Wordpress (site, forumm, mailing list, etc etc.) for direct posting online.

Describe the solution you'd like
A clear and concise description of what you want to happen.

The OpenPGP signature for the security.txt file is a good idea, so that the person could verify the integrity of the security.txt file. This could then be regularly checked, and in particular on file opening, or modification or replacement and flagged to the original address. That way of doing things would

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Really just the different SHA algorithms, and different places/options for where to put that for checking.

Perhaps this signing could be extended to cross-reference against the blockchain at intervals, or maybe ensuring it has some reference to the DS record value for the domain, or something about regular checking of signature automatically.

Or maybe there is a way to get the extensions that might do the verification automatically. I have used "Yes we hack!" to spot these sites automatically, but they do not do the checking just tell you if they exist and read the contents if do and say you can or cannot do it based on what is written in it.

Additional context
Add any other context or screenshots about the feature request here.

Perhaps this is done some other way, just seems quite useful dealing with increasing numbers of new people who know about it but inexperienced, admins of many sites who might not be paying attention, or users of sites who might want to be informed to make a decision about whether to get help over it.

Also, I did not see in the security.txt tool on your site that says YES or NO or TEMPORARILY NO or WITH EXPLICIT PERMISSION or ... whatever might be the intent of the site, and whilst likely it will be security policy it links to, might usefully appear as a flag of some sort in the security.txt thing (just one line with "permission to hack: [whatever value]", or a link to the vulnerability disclosure programme (VDP) maybe?

To some extent I think that VDP might better be part of the security.txt file, but I am not that radical, and sure that that's a bit extreme at this point.

Well, maybe something a bit better than that, but...

[Hyperpolymath]

would you prefer if I split that into the two parts (they both relate to newbie hackers engaging with the document, but there are two issues:

OpenSignature verification for safe hacking
Knowing if someone wants you to hack for bug bounties, or it will be seen as hostile

And this is the thing I was referring to re extensions, but it is just one of them (again, if it is an extension, it will be more of an issue as some might some might not, whereas pushing towards a standard might be better.

https://chrome.google.com/webstore/detail/yeswehack-vdp-finder/jnknjejacdkpnaacfgolbmdohkhpphjb - the extension, free

https://www.yeswehack.com/ - the wider service/the company, if you are interested
(I do not use anything but the extension, and not affiliated with the company)

[yakovsh]

The existing RFC uses PGP signatures to protect against tampering, is there a reason why that doesn't work? See:
https://www.rfc-editor.org/rfc/rfc9116.html#name-digital-signature

Not clear about the other question - can you provide an example of what the field would look like and some of the possible values?

[yocchan440]

How can we verify the PGP signature in security.txt?
There is an ``Encryption'' field in security.txt that shows the location of the PGP key.
However, it is written as follows.

Researchers must not assume that this key is used to generate the digital signature referenced in Section 2.3.

That is, we may not be possible to verify the signature with this PGP key.
So how can we get the verification key for PGP signature?
We believe that this information should be provided by security.txt.
For example, we could define a new ``Signature'' field and indicate the location of the verification key as its value.

[nightwatchcyber]

Take a look at section 2.3, this is not the same thing as the "Encryption" field:
https://www.rfc-editor.org/rfc/rfc9116.html#name-digital-signature

The signature would be in the enveloped encryption as per RFC 4880. Adding a separate signature field won't increase security since the attacker can falsify it.

[yocchan440]

Thank you for reply. But, I did not catch the intent of your reply.

We simply want to verify the PGP signature on the security.txt.
However, security.txt is not clear on how to obtain the verification key.
I am not talking about whether the PGP key is reliable or not, but about how to obtain the key to verify the PGP signature.

[nightwatchcyber]

You would derive the key ID directly from the signature and then use a different mechanism to verify it is legit. The RFC doesn't provide a separate field on purpose.

[yocchan440]

Yes. We understand that we can get a PGP key from a Key ID.
However, I do not know how to get the Key ID from the information contained in the security.txt due to lack of knowledge.
Do you expect to derive the Key ID from the email address given in the Contact field?

[nightwatchcyber]

The key ID would be derived from the signature itself, something like:

gpg --list-signatures --verbose security.txt

The output will contain this:

gpg: Signature made xxxxx
gpg:                using RSA key yyyyy

xxxxx is the date while yyyyy is the key ID

[nightwatchcyber]

With that being said, I can see some value in having an extra field pointing to the actual key with the caveat that the users have to make sure to verify it

@EdOverflow let me know what you think