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

On 08/01/2026 16:22, Daniel Kahn Gillmor wrote:
> 
> Note that either of these mechanisms can be used along with subkey
> expiration for some kind of calendar-based ephemerality, but you do need
> to know which kind you're using, and the instrumentation of that
> ephemerality will depend heavily on other parts of the stack than just
> the certificate (In particular, automated secret key destruction, but
> sometimes other work too)

Sure, but IMO this makes it even more important that we clearly treat 
ephemerality as a distinct concept.

Imagine for example that you have multiple storage encryption subkeys, 
and one of them happens to expire in 6 months, but you intend to renew 
the expiry on it beforehand. You don't want a "strictly for 6 months 
only" encryption command to accidentally use that subkey. You also don't 
want to accidentally extend the expiry date on a subkey that you 
intended to be ephemeral.

It is not safe to treat ephemerality as an optional extension of 
existing encryption subkeys, because then it's too easy to accidentally 
downgrade it to non-ephemeral.

>> 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.
> 
> I don't think self-signatures are a necessary component of the plan
> here.  Given that a public encryption subkey is inherently unusable after
> expiration, there is little to be gained from retaining it.

The expiration date of a subkey is stored in a self-signature, so we 
have to take them into account somehow...

> I'd propose text something like this for a system with storage limits on
> a certificate:
> 
>     If the certificate grows beyond the storage limits of the system, it
>     is RECOMMENDED that the system discard all expired encryption subkeys
>     (and their corresponding subkey binding signatures) before it drops
>     or discards any other components of the certificate.

Right, but many existing systems won't do this. PGP was not designed 
with rapid subkey rotation in mind, and legacy code is unlikely to 
handle it gracefully. Enabling it unilaterally could therefore end up 
being a self-DoS vector.

>> 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.
> 
> If the existing wire format offers the knobs we need,

Part of the problem is that the existing wire format offers *too many* 
knobs. In order to tighten security, you have to remove the knobs that 
are no longer required; otherwise you're one knob-twiddle away from a 
downgrade attack.

> and they don't
> collide with existing use, why add to an already complex spec?
Retrofitting existing things also adds complexity. Trying not to break 
legacy code that doesn't follow updated guidance adds complexity. Adding 
a clean, new (and optional!) feature is often less complex overall than 
stretching existing features to cover use cases they were not designed for.

A

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