OPENPGP URI PROPOSAL

[Hugo Osvaldo Barrera]

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
> message:
> 

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:
> 
>   https://tools.ietf.org/html/rfc6350#section-6.8.1
> 

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:
> 
>   https://github.com/open-keychain/open-keychain/issues/1281
> 
> hth,
> 
>   --dkg
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20150521/aff84c0d/attachment.sig>