RFE: Allow to submit GPG keys via HTTP GET

Issue #33 invalid
Till Maas
created an issue

I would like to be able to submit keys via HTTP GET, e.g. as:

http://keys.fedoraproject.org/pks/add?keytext=-----BEGIN+PGP+PUBLIC+KEY+BLOCK-----%0D%0AVersion%3A+GnuPG+v1[...]

This might allow me to send signatures after keysigning parties in mails encrypted to the user ID that can be important with one simple step (e.g. use something like caff but with links instead of attachments). Probably it is enough to enable the HTTP GET method for the URL because it is already possible via POST

Comments (9)

  1. Till Maas reporter

    kmkaplan, can you please be more specificic? Do you want this feature not to be implemented the way I proposed it? It says should not and this is IMHO a valid case to not do this, because if a recipient of a mail clicks on a link, then the signature should be imported, because everything that needed to be checked was checked.

  2. Kristian Fiskerstrand

    Personally I don't like the proposal. For one thing, imho, this data belongs in a POST, and secondly the use case described does not seem to merit implementation, using attachment is far more robust, allows for importing to the local keyring to verify the content before sending to a keyserver (if sending to a keyserver at all).

  3. Till Maas reporter

    My goal is to improve usability when importing key signatures from other people. E.g. currently it requires a lot of steps to do this:

    1) Open/saving the attachment 2) Importing it 3) Sending it to a keyserver

    Instead there could be just one step:

    1) Click on the link on the e-mail

    Did you attend key signing parties? I noticed that several people do not seem to import signatures after I sent them, making my work that I did to verify and sign them senseless. Therefore for me personally, this is worth it.

    About robustness: A lot of services already use very long links, e.g. in newsletters, it seems to work just fine for them. Not sure, why you think that a link will work less here. Also I get broken attachments from other peole. so it is not in general more robust.

    Importing/verifying the data is not important and if someone wants to do it, can still be done if the signature is still attached. Allowing to import the keys with one click does not make it impossible to attach it. But it is not important, because the sender can already import the signature if he wants. So what should be verified here.

    And if someone does not want to send the signature to a keyserver, they should not ask others to sign their key.

  4. Till Maas reporter

    I forgot to add something: If you are still not conviced, just tell me because I have no problem in implementing a proxy service that does just this by myself, it might just be more useful for others, if they can just use it as well without having to rely on my service.

  5. Till Maas reporter

    On Sun, Feb 22, 2015 at 08:20:12PM -0000, kmkaplan wrote:

    The link will be in an e-mail encrypted to the key that was verified e.g. at a keysigning party, therefore it is very unlikely that there is any software that can access the URL without having access to both the key and the e-mail address, and this is all that is needed verification. So if the signature is sent to the wrong address, the recipient won't be able to decrypt it and do anything. Also automatic scanners won't be able to access the URL unless they run on the end user's system.

    And if the key is not publicly available e.g. for a internal web of trust, then this is known to the signer so they can decide whether or not to use this feature, because the signer needs access to the key to sign it. But then the signer can also just publish it.

    ok.

  6. Alaric Snell-Pym

    Here's a way to provide Till's desired functionality without abusing GET (which I agree would be a bad idea): SKS provides a URL that can be GET-visited with a public key in the URL, which presents the user with a page showing the public key along with a form (a proper POST form) to submit it to the keyserver.

  7. Log in to comment