Open Bug 1595232 Opened 5 years ago Updated 2 years ago

[OpenPGP tracker] Distribution mechanisms for public key and revocations

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: KaiE, Unassigned)

References

Details

(Keywords: meta)

No description provided.

Let's track the various ways that can be used to distribute the user's own public key, and revocations of the keys the user has used previously.

If we decide to support a mechanism in Thunderbird, we should reuse code from Enigmail, if it is already implemented.

Sending of the user's own public key as an attachment is working.

Keywords: meta

Apols if this is not the place, but ought there to be an option to control by default whether or not the pubkey is sent as an attachment? It seems always to be sent by default, unless disabled per-message in Compose, unless I've missed a setting somewhere?

Perhaps also consider not sending it (by default) if we already have keys for all the recipients, suggesting that they might have ours?

Sorry if a tracker bug isn't the place for this…

(In reply to Calum Mackay from comment #3)

but ought there to be an option to control by default whether or not the pubkey is sent as an attachment? It seems always to be sent by default, unless disabled per-message in Compose, unless I've missed a setting somewhere?

Currently, we automatically attach your key whenever you are signing a key. And we automatically sign a key whenever we encrypt a message. Currently there isn't a switch yet to control this interdependency.

Your request to "don't automatically attach if I sign" is already tracked in bug 1645514.

Perhaps also consider not sending it (by default) if we already have keys for all the recipients, suggesting that they might have ours?

If we want to consider heuristics, they should be more advanced, like, assume a correspondent has your key, if they have already sent you encrypted email previously. But then, they might be on a new computer, which doesn't have a copy of your key yet. In any case the "don't always attach" is a potential optimizations that we'll have a postpone for a bit.

thanks Kai; I belatedly found that bug after adding the above, sorry.

Ironically, I /would/ like to attach my key by default, yet at the same time not continually spam my regular contacts with it, many times a day, when I know they have it. Difficult.

thanks again.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.