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

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2026-01-08 18:01:49 +0000, Andrew Gallagher wrote:
> 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.

This is true of all "ephemeral" keys, whether marked as such or not,
right?

I mean, draft-green-tls-static-dh-in-tls13 offers a way to effectively
recreate supposedly ephemeral keys in the forward-secure TLS handshake.

We can discourage it, but we can't prevent it.  Guidance that says
"please don't extend encryption-capable subkey expiration" seems like
good guidance generally, no?

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

ah ok, i think i understand your point now.  Yes, the signalling is
happening in the subkey binding signature.  Given that this is a
required element to keeping a subkey in a certificate, i think it's a
pretty reasonable place to keep it.

I actually don't think it's unclear how these rules would be
consistently implemented given the data in the self-signatures.

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

Can you say more about how much bloat you think would cause a self-DoS?
or even what you think the self-DoS would be?  are you saying that the
keyholder would be unable to operate their own secret key to decrypt?
Or that their peer would somehow be unable to encrypt to it?

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

I think what you're calling a "downgrade attack" is the current status
quo: a message that can't be reliably deleted.  Is that right?

what is the knob-twiddle that would cause it?  who has to twiddle the
knob to get that wrong?

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

The way i'm currently thinking about it is these certificates will work
with modern OpenPGP implementations. As long as their implementations
can handle RFC9580, the peers that access the certificate at least don't
need to implement anything other than the already-known semantics about
expiration.  In particular: don't encrypt to expired encryption-capable
subkeys.

If we were to use a distinct new critical wireformat change (new packet
type, critical signature subpacket, etc) to mark a component key as "not
renewable" (for example) then we risk being unable to even distribute
the associated certificate to a brittle RFC9580 client that might
complain about or reject the entire certificate.  On the other hand, if
we use some non-critical extension or signature subpacket (or other
similar inoffensive wireformat change) to distribute it, then we face
the same risks that i think you're describing.

      --dkg