ietf-openpgp
[Top] [All Lists]

[openpgp] Stateless OpenPGP command line interface proposal

2019-10-28 15:20:58
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
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…

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(_at_)mail(_dot_)gmail(_dot_)com

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>