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
Precedence: list

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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=3Dtext alice.sec < announcement.txt > announcement.txt.asc
    sop verify announcement.txt.asc alice.pgp < announcement.txt

    sop encrypt --sign-with=3Dalice.sec --as=3Dmime bob.pgp < msg.eml > enc=
rypted.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
implementers.

I've just published an initial draft of this specification here:

    https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

It's tracked as markdown source in git at:

    https://gitlab.com/dkg/openpgp-stateless-cli

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=E2=80=A6

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!

       --dkg

[0] id:CA+t5QVv_F7PCbTGSmF4bP66cGVxSHjRJQvawQArQCV4+Pdn4-w@mail.gmail.com

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXbdNmAAKCRB2GBllKa5f
+P/DAQCPt8r5e/xtARMzmy17pCvfd5sMKGUyoOXtexylH83iUwEA5C3iHze2jV4s
mp74kVu+NVWzahLuM5wZHj1CVAGgTQ4=
=uweE
-----END PGP SIGNATURE-----
--=-=-=--