Proposal for uri for gnupg messages

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view

Proposal for uri for gnupg messages

mofo syne
Is there a standard way to encode gpg keys or messages as a uri ? If
not, here is a proposal for one. Typical application of this might be
in transferring a cipertext from a screen to smartphone via a QR code,
or from a poster (e.g. signed message on physical poster).


For pubkey:

    gpg://pubkey;version:GnuPG+v2;$base64::<base64 data>

For pubkey (with implied encoding. Default for pubkey mode payload is base64):

    gpg://pubkey;version:GnuPG+v2;$::<base64 data>

For encrypted msg:

    gpg://msg;version:GnuPG+v2;$base64::<base64 data>

or a signed message

    gpg://sigmsg;hash:SHA1;sig:<base64>;$::<percent encoded message>


# schema description

What's the logic? This is actually inspired by the datauri scheme.
e.g. this example from wikipedia


So the proposed scheme for this gnupg uri is:

    gpg:// [<mode>]

The characters were chosen to not conflict with base64 accepted
characters. Thus reducing parser complexity.

We use the `gpg://` marker since `://` is used by many parser to
detect urls and uri. `;` is used as a delimiter.

The payload (implied keyname by mode) is defined as `
$encoding_type?length::payload ` where encoding_type defaults to the
usual encoding for the current mode if left empty. You could have
other encoding like none rfc1738 conforming octet stream like
`octet?16::8bitbinarystream` hence the optional `?length` notation
(could be omitted if it is always going to be transmitted in a fixed
string array, e.g. QR code). Or a base64 encoded message like
`$base64::<base64 data>`

Also for `[;key:value]` there is an alternative form
`[;key$encoding?length::value]` for specially encoded values (like
octet signature or some future form of encoding). Very much similar to
the form used for payload

## Mode keywords

So far this is what I thought for gpg keywords for the `<mode>`

* `pubkey` = public key
* `prvkey` = private key
* `encmsg` = encrypted message
* `sigmsg` = signed message
* `fprint` = key fingerprint


# Dealing with QR limited code size.

A specific problem with QR codes is most phones cannot read the max
density QR codes. Thus need to split the uri to multiple QR codes.
(e.g. splitting a gpg public key in half)

You have two approaches for encoding this.

1. Use structured append. This is more efficient, but requires more
effort to generate each barcode, since it is a binary setting. But it
is part of the QR standard.

2. Use nonstandard textual metadata "APPEND:" format e.g.
`APPEND:1of3$PARITY?ID[;token][;key:value]::<your msg>` (key:value or
token field could define settings like compression `;lzma` or encoding
`;base64`) . Pros: work on any QR generator. Cons: Not as space
efficient as structured append.


    APPEND:2of3? very long gpg message uri string here
    APPEND:3of3? to be stitched together again and decoded


# Other example




    gpg://fprint;comment:[hidden email];$::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

Gpa-dev mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: Proposal for uri for gnupg messages

Bernhard Reiter-7

On Thursday 21 May 2015 at 14:45:49, mofo syne wrote:
> Is there a standard way to encode gpg keys or messages as a uri ? If
> not, here is a proposal for one.

a better place for this email was gnupg-devel oder gnupg-users
where you did send it.

@all, I think for lack of traffic (last post July 2012) we should remove this
mailinglist. And redirect traffic to gnupg-devel@.


-- (CEO) (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Gpa-dev mailing list
[hidden email]

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view

Re: Proposal for uri for gnupg messages

Daniel Kahn Gillmor-7
On Mon 2015-08-31 04:13:47 -0400, Bernhard Reiter wrote:

> @all, I think for lack of traffic (last post July 2012) we should
> remove this mailinglist [gpa-dev]. And redirect traffic to
> gnupg-devel@.

That sounds like a reasonable proposal to me.


Gpa-dev mailing list
[hidden email]

signature.asc (966 bytes) Download Attachment