OPENPGP URI PROPOSAL

[Daniel Kahn Gillmor]

On Thu 2015-05-21 11:59:07 -0400, mofo syne wrote:
> You might see a few copies around. This one is edited and streamlined with
> some advice from Hasimir to help keep this proposal focused. This is
> mirrored in here
> <http://www.reddit.com/r/GnuPG/comments/36lmih/i_wonder_if_there_is_a_gpg_uri/>

This proposal appears to be trying to do a lot of different things.  I'm
not convinced that they are all reasonable goals, or that gnupg-users is
the right mailing list to discuss them on.  The openpgp at ietf.org is a
mailing list where different people discuss the standard in general.

The example you give toward the end of the spec (uri handlers in web
browsers) is an important example for arguing why something like this is
concretely useful.  Have you tried to implement this?  Can modern web
browser handlers work with arbitrary length data?  When i try to trigger
a local handler for an unknown schema in iceweasel (firefox) i see this
message:

--------------
   The address wasn't understood

   Iceweasel doesn't know how to open this address, because one of the following protocols (openpgp) isn't associated with any program or is not allowed in this context.

    You might need to install other software to open this address.
--------------

with no option to choose an external handler or anything.

Chromium, on the other hand, offers to launch "xdg-open" with that URL
as the parameter, which fails because no handler is registered for the
scheme in question.  Is this the intended mechanism, or something else?

>     openpgp://pubkey;version:GnuPG+v2;!base64::<base64 data>

There is already a vCard spec for a full pubkey -- though you might
actually mean "transferable public key" or OpenPGP certificate:

  https://tools.ietf.org/html/rfc6350#section-6.8.1

>     openpgp://msg;version:GnuPG+v2;!base64::<base64 data>

When is this useful?

>     openpgp://sigmsg;hash:SHA1;sig:<base64>;!::<percent encoded message>

what about a message that is both signed and encrypted?  how should it
be represented?

> * Embedded in NFC or 2D barcode for physical messages in posters that is
> able store encrypted messages, public keys, or signed messages. Other than
> posters, it also allows for easier transferring of openpgp messages via NFC
> or 2D barcodes between a webbrowser in a cybercafe to a smartphone.

These seem more likely to be handled by vCard or some similar approach
to me.

> openpgp://fprint;name:clark+kent;::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
>
>     openpgp://fprint;::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

These fingerprints are only 128 bits long, which matches the OpenPGPv3
fingerprint format.  OpenPGPv4 fingerprints are 160 bits long, and any
new fingerprint standard might be longer still.

Your proposal here doesn't mention any sort of versioning for
fingerprints, or take into account other concerns.

A large discussion about fingerprint encodings for low-bandwidth
transmission can be found here:

  https://github.com/open-keychain/open-keychain/issues/1281

hth,

  --dkg