WKS enabled for gnupg.net and gnupg.org

[Werner Koch]

On Thu,  1 Sep 2016 17:53, gnupg-devel at spodhuis.org said:

> Problem: I like GnuPG in part because of it's support for the concept of
> privacy.  This mailcap setting is rather dangerous from that
> perspective.  Fortunately mutt does not autoview by default, but that's
> a thin layer of ice to be resting upon.

It is not intended as a final solution.  It is merely convenient for
testing.

> The fingerprint: isn't verified (a FIXME), the sender: doesn't appear to
> be validated as being at least in the same domain as a uid on the key.
> The nonce is sent back, but that can be arbitrary text with nvc_parse()
> explicitly handling continuations for multi-line data and gpg-wks-client
> only checking that the nonce is long enough.

Right.  The reason tehre are FIXMEs in the code is that they need to be
fixed before the code gets into wide use.  This is also the reason why
you need a configure option for building the client.

Here are my planned steps:

  - Fix the FIXMEs
  - Create a database for the client to track pending requests.  Then 
    answer only requests we have initiated.
  - Revise the protocol to better protect against spam and for easier
    automated processing
  
> The one saving grace is that it looks like the message isn't signed?  (I
> haven't read the code deeply enough to be sure).

Right, not in this revision of the protocol.  My plan is this:

Create a signed messages with a multipart/mixed content.  The first part
is a human readable description what this message is about.  The second
part is the encrypted confirmation request as we use it currently.  A
MUA may now check that the signature comes from an address from where we
expect a confirmation request and silently drop the message if that is
not the case.  This way the user won't be asked by non-provider
generated confirmation requests to enter their passphrase for
decryption.  The signed message also allows to present a useful prompt
_before_ decryption.

Right now I am unsure on whether the encrypted part should really be a
MIME part (which would technically be the right thing) or just a plain
inline armored or even only base64 encoded blob.  The latter has the
advantage that full PGP/MIME aware clients won't be able to decrypt it
and thus need to employ gpg-wks-client instead - but the mailcap trick
won't work either.


> I've commented this back out of my .mailcap as there's a rethink needed,
> IMO.

As I said, it is useful for testing.

> At a bare minimum, any command designed to be invoked from mailcap
> should respect the privacy of the reader by not communicating remotely
> without positive confirmation from the user first.  gpg-wks-client

Iff that is an expected request I think it is fine to send a response
without user interaction.


> The approach is sane and with right tools integration this could be
> valuable ("click button to register key with email server") but at
> present much more is needed before this can be a template for adoption.
> But hey, that's the point of the -devel list and catching these things
> early, right?

Many thanks for your comments.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20160902/d86c444c/attachment.sig>