How to provide public key for security.txt?

Question

When generating a security.txt file, it is recommended to digitally sign it. However, security researchers must not assume that the information used in the Encryption field is actually the key used to sign the file. So my question is: how should I indicate the location of/ provide the public key such that researchers can verify the signature?

My research

• Read the documentation of the rfc standard
• Read the documentation of the security.txt guideline
• Searched the internet

Answer 1

The pitfall of circular reasoning when trusting the PGP keys

The definitions of the Encryption field (RFC 9116, 2.5.4) and the digital signatures (RFC 9116, 2.3) do not require matching PGP keys. However, using the same key for both is less confusing and easier to check.

Even in this case, the proof it provides is a circular reasoning at best; a compromised security.txt could refer a counterfeit PGP key that is also used for signing the file. Therefore, only out-of-band verification is sufficient.

The RFC 9116 recognizes the possible trust issues with the PGP keys and the requirements for verification:

2.3. Digital Signature:

When it comes to verifying the key used to generate the signature, it is always the security researcher's responsibility to make sure the key being used is indeed one they trust.

5.1. Compromised Files and Incident Response:

While it is not recommended, implementors may choose to use the information published within a "security.txt" file for an incident response. In such cases, extreme caution should be taken before trusting such information, since it may have been compromised by an attacker. Researchers should use additional methods to verify such data including out-of-band verification of the Pretty Good Privacy (PGP) signature, DNSSEC-based approaches, etc.

How to help with the verification?

1. Be consistent when publishing your PGP keys. Do not look suspicious.
2. Publish the keys in ways that can be verified using multiple anchors of trust:
   • TLS PKI
   • DNSSEC
   • (Web of Trust; weak because of social difficulties).

Luckily, one of the URI schemes within the examples provided in RFC 9116, 2.5.4 for the Encryption field is suitable for out-of-band verification.

Example of an OpenPGP key available from an OPENPGPKEY DNS record:

Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY

The OPENPGPKEY is defined in EXPERIMENTAL RFC 7929; DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. It is protected by DNSSEC, which provides a PKI useful for the verification:

RFC 7929, 5. Application Use of OPENPGPKEY

The OPENPGPKEY record allows an application or service to obtain an OpenPGP public key and use it for verifying a digital signature or encrypting a message to the public key. The DNS answer MUST pass DNSSEC validation; if DNSSEC validation reaches any state other than "Secure" (as specified in [RFC4035]), the DNSSEC validation MUST be treated as a failure.

On the other hand, Werner Koch & GnuPG is currently implementing a rival technology, OpenPGP Web Key Directory (WKD) in draft-koch-openpgp-webkey-service as GnuPG's standard system for key discovery. This may affect the adoption of OPENPGPKEY implementation. I find it sad, because the authenticity of the keys on WKD is solely proven by the HTTPS TLS PKI.

(BTW, the example in RFC 9116 is malformed, as the hash of the local-part is truncated too short; RFC 7929, 3 defines 28 octects instead of the 8 in 5d2d37ab76d47d36.)