Re: [openpgp] Stateless OpenPGP command line interface proposal

Daniel Kahn Gillmor <> Wed, 30 October 2019 02:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D01A712009E for <>; Tue, 29 Oct 2019 19:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=KPSFbvmi; dkim=pass (2048-bit key) header.b=o3JqG4wz
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6gI3RwVtRdR3 for <>; Tue, 29 Oct 2019 19:04:08 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3FC8120059 for <>; Tue, 29 Oct 2019 19:04:07 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1572401046; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=gp2NCQV6YvoH+lYf3w4VVVj+23vBp71CpWvHVvjQKKk=; b=KPSFbvmi/TDWwbyOJSnTJ269Qt/vtijLNo4uSsa9WfWXlbZI97tM5XRD OxdXirmOMct5UjsewYmpzV7lvjcWAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1572401046; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=gp2NCQV6YvoH+lYf3w4VVVj+23vBp71CpWvHVvjQKKk=; b=o3JqG4wzZhifsGiOxHt9c4hNFmHGdHJO+XaNSoYHZJbeNnUiPAE3dc89 IEF+Swl0h4wEnhGiOGC4Y5YHDZqCyKJQlwerMjatoeWsiiqWUCMmQnuT4u bHChE9w37DcnYOxxh84yyx/Dx8wEAaMKVCTh9Mw6Tk0QAMUVC6TTrl/DzR m6TrjUoqp1etCywNF63j1WRhqqeOX4aUe4YO2t1EdFifT1CVUwA9SbML6J mIirE2OYfWouk2I83+3TU6JURBlqCe8Ldxv4EqvxcwVoBVFZe4pQ97gRwi +M0a0OpVOvSES+QbtnC2QyYbBNV7I7DIiZuh5DyHO+5F7pxJsFdQcg==
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id D1EA3F9A5 for <>; Tue, 29 Oct 2019 22:04:06 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 6D5A620556; Tue, 29 Oct 2019 22:04:03 -0400 (EDT)
From: Daniel Kahn Gillmor <>
In-Reply-To: <>
References: <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Tue, 29 Oct 2019 22:04:02 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [openpgp] Stateless OpenPGP command line interface proposal
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2019 02:04:11 -0000

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:

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

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

You can compare the forms:

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