[openpgp] Stateless OpenPGP command line interface proposal

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 28 October 2019 20:20 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F3D4A120105 for <openpgp@ietfa.amsl.com>; Mon, 28 Oct 2019 13:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=acNyc3+N; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=pOcHghSt
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KSu-kJ69-D1L for <openpgp@ietfa.amsl.com>; Mon, 28 Oct 2019 13:20:45 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A89612004E for <openpgp@ietf.org>; Mon, 28 Oct 2019 13:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1572294043; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=AXBf0IAgbb/eTkE8ihpWRKcRn1zfJhBDzW96y37QfdU=; b=acNyc3+NAjGdj6ZI6Ug7qFTTzxIVqJVco/KVhgg9JL6zPBo6zeFuLo7m 8q7HapZQbmzLiQI+2gRUy8GuyMt0Bg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1572294043; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=AXBf0IAgbb/eTkE8ihpWRKcRn1zfJhBDzW96y37QfdU=; b=pOcHghSt0CTbcG8ZxRVlij6Gmgb2UVcxu/jjrrWqGd3RpotTRlPm/0TI AGqtw55JDPZuhyJXE6ena3Zn5G3mM1O4qsdve1+HBT51cA423qGZ6BKQ41 aEJUp1JpKOc+4f+YI9Y1O328WvB4FR1RftGwRlTiuEIIrdEj7rwiRR72lC MhE/tfCF7KEJK6cMfnnE8SIJG5fV3OzXdM0UHEpV4FyUwUI9ClYsOyA9Ij PdN1fwcH3KCuDTMmsMgn9Je7QFR+XRQNaNtH7OxRXw4H6GahU2HK7YMfhj MxxXZy64grc4aU7uhhRefWawXnFqMw0Y7XiqOoi0R3tdYlarh2BanA==
Received: from fifthhorseman.net (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D5970F9A5 for <openpgp@ietf.org>; Mon, 28 Oct 2019 16:20:43 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 7D44820594; Mon, 28 Oct 2019 16:20:40 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: openpgp@ietf.org
Autocrypt: addr=dkg@fifthhorseman.net; 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: Mon, 28 Oct 2019 16:20:39 -0400
Message-ID: <87ftjck4fc.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/NNWzVbZijYaPt2oPIVdCjdwjINk>
Subject: [openpgp] Stateless OpenPGP command line interface proposal
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 20:20:47 -0000

Hi OpenPGP folks--

The recently-announced OpenPGP test suite [0] inspired me to try
drafting a spec for a purely-functional, stateless OpenPGP command line
interface.  The idea is that different implementers could provide the
same interface, focusing specifically on the object security aspect of
OpenPGP (leaving aside identity management).

An example (using "sop" as the command, short for "Stateless OpenPGP"):

    sop generate 'Alice Lovelace <alice@openpgp.example>' > alice.sec
    sop convert < alice.sec > alice.pgp

    sop sign --as=text alice.sec < announcement.txt > announcement.txt.asc
    sop verify announcement.txt.asc alice.pgp < announcement.txt

    sop encrypt --sign-with=alice.sec --as=mime bob.pgp < msg.eml > encrypted.asc
    sop decrypt alice.sec < ciphertext.asc > cleartext.out

My hope is that any implementer that provides a command "foo" that meets
the given spec can be interoperably tested against all other

I've just published an initial draft of this specification here:


It's tracked as markdown source in git at:


But i'd very much like other contributions or authors.  If you're an
implementer of an OpenPGP toolkit, and you think you might take a crack
at implementing part of it, i'd love your feedback.  If there's
sufficient interest in the community, i'd be happy to move the `sop`
spec over to https://gitlab.com/openpgp-wg/ so that it's clearly not
something that i'd be a blocker on.

Why do this?  I want to encourage interoperability and testing, and
applications that use OpenPGP tend to have a rather simple model of what
they *want* out of OpenPGP, even though the spec itself is very complex.

A shared spec could help us build some tools that capture that model, as
closely (and as simply) as possible.

In particular, traditional OpenPGP implementations are capable of many
different kinds of work:

  * Object Security
   - Authenticity/Integrity
     - message/object signing
     - signature verification
   - Confidentiality
     - message/object encryption
     - ciphertext decryption
  * Identity Management
   - personal
     - creation and storage of your own secret keys
     - management of your own public keys/certificates
     - publication of certificates (e.g. keyservers, WKD)
     - management of hardware security tokens
   - peers
     - discovery of peer certificates (e.g. keyservers, WKD)
     - curation and maintenance of peer certificates
     - association of peer certs with application contexts
     - certification of peers ("key signing")
     - graph analysis of certifications ("web of trust")

There are probably more things too that i've forgotten about…

My thought was that if we could separate these things out, we can focus
on interoperability of the first part ("Object Security") and treat the
second part ("Identity Management") as a distinct project.

Obviously, both parts are critical to a functional use of OpenPGP, but i
think if we tackle them separately we can provide more plausible and
efficient interoperability, which should in turn lead to the ability to
drive new cryptographic primitives out into the community.

Please take a look and let me know what you think!


[0] id:CA+t5QVv_F7PCbTGSmF4bP66cGVxSHjRJQvawQArQCV4+Pdn4-w@mail.gmail.com