Re: [openpgp] Stateless OpenPGP command line interface proposal

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon 2019-10-28 16:20:39 -0400, Daniel Kahn Gillmor wrote:
> drafting a spec for a purely-functional, stateless OpenPGP command line
> interface.
 […]
> I've just published an initial draft of this specification here:
>
>     https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

I got a lot of very useful feedback on this draft (mostly off-list) from
several people over the past day, and i've published a revised version
that incorporates what I learned.

substantive changes between -00 and -01:

 * Changed `generate` subcommand to `generate-key`
 * Changed `convert` subcommand to `extract-cert`
 * Added "Input String Types" section as distinct from indirect I/O
 * Made implicit arguments potentially explicit (e.g. `sop armor --label=auto`)
 * Added `--allow-nested` to `sop armor` to make it idempotent by default
 * Added fingerprint of signing (sub)key to `VERIFICATIONS` output
 * Dropped `--mode` and `--session-key` arguments for `sop encrypt` (no plausible use, not needed for interop)
 * Added `--with-session-key` argument to `sop decrypt` to allow for session-key-based decryption
 * Added examples to each subcommand
 * More detailed error codes for `sop encrypt`
 * Move from `CERT` to `CERTS` (each `CERTS` argument might contain multiple certificates)

Some things that I observed from this process:

  - `sop` should be simple to operate.  It shouldn't ask the user any
    question (or offer any options) that the user doesn't already know
    the answer to, or that will have no effect on how the data produced
    will ultimately be used.

  - Implementers of `sop` are expected to make reasonable decisions in
    those corners of the spec are unclear.  Hopefully interoperability
    test suites will help identify those corners.

  - While we want `sop` implementations to be robust when trying to
    consume weird input, sometimes being robust really should just mean
    a clean failure, rather than trying to make sense of non-sensible
    inputs.

I also note that xml2rfc v3 output is substantially nicer to read than
the htmlized form produced by tools.ietf.org by default right now.

You can compare the forms:

    https://tools.ietf.org/html/draft-dkg-openpgp-stateless-cli-01
    https://dkg.fifthhorseman.net/draft-openpgp-stateless-cli.html

I prefer the latter, which i aim to keep updating if (as i hope) more
revisions are forthcoming.

I welcome further feedback on this spec, both here on-list and also via
https://gitlab.com/dkg/openpgp-stateless-cli

Regards,

       --dkg
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXbjvkwAKCRB2GBllKa5f
+NShAP9HD282x1xFK98EBQQz3mVjB1Ly5ASy+TBs5cJecU4MJwEAhPuvz0kYagqA
r5Z4Jhvct9wMgvIcQJtqQV54HyhK9Qs=
=09Dg
-----END PGP SIGNATURE-----