2

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

3
  • In the same ways you'd share a public key for any other reason, I'd think. Either use the web of trust, or distribute it (or at least the fingerprint) on some other channel, such as social media or business cards.
    – forest
    Dec 27, 2022 at 9:37
  • 1
    The RFC gives three examples on how to do it. What's wrong with those? Dec 27, 2022 at 10:00
  • I was hoping that there's an agreed-upon default (like "the public key should be available at .well-known/security.pub.pgp" or "you can use the security.txt element xyz to describe how to obtain the public key")
    – kolumbus
    Dec 27, 2022 at 18:38

1 Answer 1

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.)

1
  • For the consistency, my securitytxt-signer.sh script advices using the same key for signing that is referred in the Encryption field(s). Dec 27, 2022 at 18:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .