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

Hi Andrew--

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

True :)

But i'm not sure that the sop spec is the place to offer the
definition.  I'll take a stab at my own explanation here:

- Encrypting an object "for communications" is a way to provide
  object-level confidentiality for a message while it is in transit.
  This is distinct from any sort of channel-based confidentiality (such
  as that offered by TLS or QUIC) because it the confidentiality is not
  a property of the channel itself, but of the object.

  The expectation here is that the recipient of the communication will
  decrypt upon receipt and then process/handle the decrypted message
  as they see fit.

  The classic OpenPGP example for this case is an encrypted e-mail
  message.

- Encrypting an object "for storage" is a way to provide object-level
  confidentiality for that object when it is placed in long-term
  storage.  This is different from, for example, underlying block device
  encryption or filesystem-level encryption because it applies
  distinctly to the object handled rather than the storage substrate.

  The expectation here is that the eventual decryptor will dip into the
  storage in the future, and need the cleartext at that point.

  The classic OpenPGP example for this case is an encrypted backup.

I'd be happy to hear any feedback, alternate explanations, or
suggestions for improvement.

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)

For example, "for communications" might be used to offer "reliable
deletion" of messages.  If messages are transmitted over a channel with
some maximum expected latency, if the recipient retains their secret key
for that max latency beyond public key expiration, then any message
protected with that key can be reliably deleted after that point.  Doing
this while retaining archival access to those messages the user does
*not* want to delete requires some additional care which i won't get
into here.

An example "for storage" might be used for time-limited backups: if i
know that i want to retain backups for recovery in untrusted cloud
storage going back 6 months but no more, it makes sense to encrypt to a
"for storage" key with an expiration marked for at least as long as i
want to be able to support recovery.

> I have strong doubts about whether a "forward secrecy" system (I'll use 
> the term for want of a better one)

Please let's reserve the term "forward secrecy" for channel-bound
confidentiality, and use "reliable deletion" for object-bound
confidentiality.

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

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.

> 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, and they don't
collide with existing use, why add to an already complex spec?

        --dkg

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