OPENPGP URI PROPOSAL
Hugo Osvaldo Barrera
hugo at barrera.io
Fri May 22 00:46:52 CEST 2015
On 2015-05-21 15:21, Daniel Kahn Gillmor wrote:
> 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
Modern browsers can handle this. Some websites embed base64 uri-encoded images
of several kb in length and all browsers handle this properly.
> 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.
The same happens with several other quite standard protocols. Even some of
those listed on rfc3986. This is a firefox issue, IMHO.
This is configured via about:preferences#applications, since firefox does not
respect OS settings in this aspect at all.
> 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>
That sounds like the expected behaviour if there's no registered handler. The
same would happen with things like "mailto:" if you had none.
> There is already a vCard spec for a full pubkey -- though you might
> actually mean "transferable public key" or OpenPGP certificate:
Yeah, this seems to invalidate the strongest use-case for this specification.
> > 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.
On some scenarios. But we need some sort of glue to import something from a
vCard into gnupg's keyring. I don't think we need a new spec for this though.
> > 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:
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Gnupg-users