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

hey OpenPGP folks--

If you celebrate the gregorian calendar, happy T=1767225600 !

Fri 2026-01-02 11:27:50 -0800, [email protected] wrote:
> A new version of Internet-Draft draft-dkg-openpgp-stateless-cli-15.txt has
> been successfully submitted by Daniel Kahn Gillmor and posted to the
> IETF repository.
>
> Name:     draft-dkg-openpgp-stateless-cli
> Revision: 15
> Title:    Stateless OpenPGP Command Line Interface
> Date:     2026-01-02
> Group:    Individual Submission
> Pages:    107
> URL:      https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-15.txt
> Status:   https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stateless-cli
> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-dkg-openpgp-stateless-cli-15
>
> Abstract:
>
>    This document defines a generic stateless command-line interface for
>    dealing with OpenPGP messages, certificates, and secret key material,
>    known as sop.  It aims for a minimal, well-structured API covering
>    OpenPGP object security and maintenance of credentials and secrets.

From the changelog, this minor update to the draft touches two `sop`
subcommands:

- `update-key`: permit/encourage creation of replacement primary keys
- `update-key`: add `--revoke-deprecated-keys`
- `encrypt`: add `--for={storage|communications|any}`

The first two are designed to expose some mechanism for encouraging
production of certificates using draft-ietf-openpgp-replacementkey

The last change is an attempt to clarify what it means to "encrypt for
communications", as distinct from encrypting for storage.

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.

      --dkg

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