[openpgp] Re: New Version Notification for draft-dkg-openpgp -stateless-cli-15.txt

Hi, Daniel.

On 02/01/2026 21:18, Daniel Kahn Gillmor wrote:
> The last change is an attempt to clarify what it means to "encrypt for
> communications", as distinct from encrypting for storage.

It clarifies that "communications" and "storage" are separate concepts, 
but I don't see how it clarifies what distinguishes them (beyond the 
usual dictionary definition of the words)...

> There have been an increasing number of discussions about how to achieve
> reliable deletion of OpenPGP messages (called in some circles "forward
> secrecy"), and being able to distinguish between encrypting long-term
> storage and recall (which effectively can't have this property) versus
> encrypting a message as it is being prepared for delivery (which can)
> seems like a good baseline step.  For background, people have been
> discussing some sort of reliable deletion in OpenPGP since at least
> https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs in 2001, but i
> don't think anyone has tried to make a reliable system yet.  Perhaps
> normalizing "sop encrypt --for=communications" to the general repertoire
> will make it easier for application developers to aim for these
> properties in a messaging system.

I have strong doubts about whether a "forward secrecy" system (I'll use 
the term for want of a better one) can be cleanly implemented using 
existing certificate formats. In particular, short-lifetime encryption 
subkeys will tend to accumulate in a certificate unless we have very 
clear rules about how to clean them up, but it is unclear how those 
rules could be consistently implemented using self-signatures. We don't 
normally remove certificate components just because they have expired, 
and we can't reliably use revocation signatures to trigger deletion 
because the revocation signature will then be discarded, allowing the 
subkey to be re-added.

I would much prefer to define a separate "ephemeral key" mechanism for 
forward secrecy using intrinsic (non-extensible, non-revocable) (sub)key 
lifetimes. That way, there can be no ambiguity about whether the 
ephemeral key has been extended or revoked - so it can always be safely 
deleted after its expiry date.

A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]