Re: [openpgp] New Version Notification for draft-dkg-openpgp-stateless-cli-05.txt (key generation profiles)

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

Hi OpenPGP folks--

The draft announced in this message is not Working Group work, but it is
aimed at interop testing, so i wanted to give a heads-up for any
implementers following the current crypto-refresh draft.

On Wed 2023-02-22 15:49:32 -0800, [e-mail] wrote:
> A new version of I-D, draft-dkg-openpgp-stateless-cli-05.txt
> has been successfully submitted by Daniel Kahn Gillmor and posted to the
> IETF repository.
>
> Name:		draft-dkg-openpgp-stateless-cli
> Revision:	05
> Title:		Stateless OpenPGP Command Line Interface
> Document date:	2023-02-22
> Group:		Individual Submission
> Pages:		46
> URL:            https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-05.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-05

I've just updated the sop draft, with the main goal of trying to
faciliate interoperability testing of developer branches that might
support new specifications.

From the changelog:

------
## Substantive Changes beteween -04 and -05:

- `decrypt`: change `--verify-out` to `--verifications-out`
- `encrypt`: add missing `--with-key-password`
- add the concept of "profiles", use with `generate-key`
- include table of known implementations
- `VERIFICATIONS` can now indicate the type of the signature (`mode:text` or `mode:binary`)
------

The biggest novelty here is the "profiles" mechanism.

"sop generate-key" now takes an optional `--profile=PROFILE` argument,
and any implementer can define an interesting and useful profile.

By default, nothing changes, and implementations can emit whatever they
want to emit.

But the idea here is that when we manage to release crypto-refresh-08,
implementers can enable a profile named
"draft-ietf-openpgp-crypto-refresh-08" and we can see whether other
implementations can handle the keys or certificates produced that way.

That would be invoked like so:


    sop generate-key --profile=draft-ietf-openpgp-crypto-refresh-08 "Alice <[e-mail]>"


If the eventual RFC is released as RFC 9999), then an implementation
might try to make a new key for it with:

    sop generate-key --profile=rfc9999

while still leaving the default profile as something with a wider
interoperability.

There is also a way to learn the new key profiles supported by any sop
implementation, with:

    sop list-profiles generate-key

For future work, we could also consider applying this --profile=
mechanism for `sop encrypt` (e.g. to force some flavor of ESK/SEIPD to
be produced?), but i figure this is enough churn in the specification
for one cycle.  If someone else wants to propose improvements, i'd be
happy to review.

As always, I welcome feedback from implementers or consumers of the sop
interface.  Does it match the semantics that you're expecting?  is it
concretely useful?  How can it be improved or clarified?

    --dkg