Re: [openpgp] Keyserverless Use of OpenPGP in Email

[Paul Wouters <[e-mail]>]

Have you looked at the openpgpkey DNS record which is going to be an RFC very soon?

https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07

Paul

Sent from my iPhone

> On Apr 12, 2016, at 09:15, Vincent Breitmoser <[e-mail]> wrote:
> 
> Hi,
> 
> (crossposting to openpgp-email and openpgp-wg, the lists where I expect
> the highest rates of interested people)
> 
> I'd like to discuss a thought that has come up in my work on k9 mail:
> Using OpenPGP in E-Mail without relying on keyservers.  As a motivation,
> just consider someone spins up their botnet to add 1000 or more keys per
> second to the pool - aaaaand it's gone. Other aspects are that a
> keyserver lookup requires network connectivity, introduces noticable
> delay, and has privacy implications which prevent us from doing the
> lookup in an automated fashion.
> 
> First, some basic considerations:  To obtain the public key of a
> communication partner, we obviously have to rely on said communication
> partner to make their key available to us one way or another.  The only
> deployed lookup mechanism are keyservers, but we said we don't have
> that.  The alternative is sending the key in-band with the particular
> communication protocol: No problem for synchronous communication such as
> XMPP because we can simply request them, more difficult for e-mail where
> that option is not available.
> 
> If we don't have bandwidth constraints, we can solve this by sticking
> the public key block right next to every signature we make, which
> effectively eliminates the need for keyservers (with the possible
> exception of the distribution of revocation certs).  However, it also
> adds ~10kb of size to every signature.  This is a rather extreme
> approach, and although 10kb are not a lot these days, they add up.
> 
> To counteract this, we can significantly reduce the number of attached
> public keys if we are just a little bit clever about the decision of
> when to add it.  Roughly, it makes sense to attach the public key to the
> first message of a conversation with each recipient.
> 
> Another question is, where to place the key. In email, we have two
> options: in a separate mime part, or directly next to the pgp signature
> data. I favor the second option, for two reasons:
> - the email client has to know a lot less about openpgp for this to
>  work, the public key is naturally handed to the openpgp-implementation
>  together with the signature data.
> - there isn't yet another weird attachment for recipients who don't have
>  openpgp support
> - the intended purpose of the key is clear, because there are no other
>  circumstances where a key might end up in this position.
> 
> The drawback with this approach is implementation support.  If an
> implementation doesn't expect a public key next to the signature data,
> it's just bloat (or even worse, produces a warning about trailing data.
> I did some tests and this is the case in mutt, but not enigmail), and
> does not even show an option for the user to manually import the key.
> 
> I think that this approach might be a way to overcome the need for a
> click from the user (whether it's "Retrieve from Keyserver" or "Import
> from Attachment") to be able to import and work with a public key. It's
> unacceptable to import a key from keyservers automatically for various
> reasons, but I think an opt-out behavior of importing keys retrieved as
> part of a message is fine, if that key also signed the message.
> 
> I'll leave it at this for now.  I'd be delighted about comments and
> thoughts, in particular from those of you who are involved in the
> decision making of other implementations.
> 
> - V
> 
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp