Open Bug 905543 Opened 11 years ago Updated 2 years ago

Bugzilla should autodiscover OpenPGP/GPG key for secure email from DNS

Categories

(bugzilla.mozilla.org :: Extensions, enhancement)

Production
enhancement
Not set
normal

Tracking

()

People

(Reporter: hsivonen, Unassigned)

References

Details

Steps to reproduce:
1) Publish your OpenPGP public key on a Web server.
2) Publish the fingerprint and the URL for your public key in DNS.
3) Enable DNSSEC for your domain.
4) Receive notification e-mail for an update to a security bug.

Actual results:
The e-mail about the update to the security bug is just a pointer to Bugzilla. It does not include the content of the update in a OpenPGP-encrypted form. If you want to Bugzilla to send encrypted e-mail to you, you need to manually paste your public key block into Bugzilla preferences.

Expected results:
If
 * There exists a TXT record for userid._pka.domain.
AND
 * The record has an RRSIG that validates all the way up to the DNSSEC root.
AND
 * The value of TXT record is of the form v=pka1;fpr=FINGERPRINT;uri=URL
AND
 * Dereferencing URL yields an OpenPGP public key block.
AND
 * FINGERPRINT is the fingerprint for the primary key in the public key block.
AND
 * Bug 905538 has been fixed.
…expected to Bugzilla to automatically use OpenPGP when sending security bug e-mail to that bug mail account.
Depends on: 790487
This sounds like a significant amount of work for a developer to save a not-very-significant amount of work for a not-all-that-large number of users...

This would require SecureMail to grow a DNS library which supports DNSSEC, right?

Gerv
(In reply to Gervase Markham [:gerv] from comment #1)
> This sounds like a significant amount of work for a developer

I guess that depends on how readily DNSSEC-validated retrieval of TXT records and fingerprinting OpenPGP public key blocks are available off the shelf.

> to save a
> not-very-significant amount of work for a not-all-that-large number of
> users...

There's a chicken and egg problem here. PGP famously has a bootstrapping problem. PKA with DNSSEC solves the bootstrapping problem, but few people are incented to publish their keys via PKA+DNSSEC unless there are plenty of apps making use of that data and apps are not incented to add the relevant code unless there are many people whose keys are published via PKA+DNSSEC. Of course, the more software there is that finds the needed keys via PKA+DNSSEC, the more time is saved for the user compared to manually setting up keys. (Sadly, while GPG supports PKA, it doesn't appear to do DNSSEC validation and treats keys retrieved via PKA as untrusted as keys retrieved from public key servers even if a DNSSEC trust chain would be available.)

> This would require SecureMail to grow a DNS library which supports DNSSEC,
> right?

Or, alternatively, it would require Bugzilla being able to reach a DNSSEC-aware recursive DNS server (that claims the TXT record doesn't exist if it exists but the RRSIG doesn't validate) via a secure link (localhost or within the trusted data center network).
Or perhaps implement support for the OPENPGPKEY record:

https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00
(In reply to Paul Wouters from comment #3)
> Or perhaps implement support for the OPENPGPKEY record:
> 
> https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00

As an addition, OK. Instead of TXT, not OK. Plenty of people have DNS configurators that can handle TXT. Practically no one has tooling for OPENPGPKEY. (The IETF shunning TXT records with in-band type identification is really hostile to deployability.)
the biggest problem of older TXT methods is the discovery. The openpgpkey draft allows one to query for pgp keys for _any_ email address. The TXT methods depend on the poster giving you some kind of secure pointer to the TXT record which then point to yet another URI for the key blob, which might involve TLS and so then you might even have to validate _that_ key first.

Using TXT for anything is really a pre RFC-3597 solution. Any DNS software written in the last 5 years supports the generic record, so there is no reason to pick TXT records for anything and wade through a puddle of TXT records to find the sub-type you are interested in.
Component: Extensions: SecureMail → Extensions

A better solution would be to use Web Key Directory since it's a single GET request of the hashed email address and the underlying library for GET will do the X509 validation.

You need to log in before you can comment on or make changes to this bug.