On 02/10/2015 10:33 PM, Trevor Perrin wrote: >> (2) We need a new protocol that allows a sender to advertise to the >> recipient what their key is and that they prefer encrypted email. The >> email signature is a good signal, but not ideal because there is no real >> binding between the fingerprint on the signature and the email address >> (unless the provider is in the habit of uploading signatures to the >> public keyservers). The OpenPGP header has the same problem. > > Could you expand on what's wrong with existing methods? > > Do you just want to convey the sender's public key? If by OpenPGP > header you mean [1], that allows sending a fingerprint and URL. > That's unfortunately similar to a web bug, but maybe the recipient > could defer fetching the key until they need it to encrypt?
In the short term, we are supporting the OpenPGP header if the URL matches the sender's domain, and we delay actual key fetching until the user sends an email. It is a good idea to delay fetching for several reasons, to prevent email bugs but also because you don't want someone to be able to fill up your keyring simply by sending you a ton of email with different keys. There are a couple problems with the OpenPGP header. I could craft an email that purports to be from [email protected] with an OpenPGP header of my choosing. Maybe the recipient's client is smart and only accepts OpenPGP header when the from header is DKIM signed. Even in this case, both the sender's server and the recipient's server could inject a bogus OpenPGP header. Maybe the sender's server should DKIM sign the OpenPGP header, but it doesn't really have any basis to verify that it should. All of this is too messy. It would be much better to have a header that just specified a list of well known discovery/validation mechanisms. E.g. DANE, webfinger, keybase, CONIKS, etc. The mechanism would need to include some implicit or explicit endorsement of the key by the email provider or central authority or central audit log or quorum/consensus (so, for example, a fingerprint or arbitrary URL would not suffice). The header might be added by the provider or the sender's MUA, so multiple instances should be supported. When the dust settles, and we all join hands and rally around the one true system for automatic key validation, then there is no need for such a header. But that day may never come, or will be a long way out if it does. I also heard some people are partial to in-band approaches :) > I'm not sure PGP signatures contain the public key or a full hash by > default - so you may be right that signing by itself is insufficient > (signatures don't necessarily "bind" the public key - see > "duplicate-signature key selection" [2]). Interesting, although I was just thinking of the same problem as with OpenPGP header, that anyone can create a key with [email protected] for the uid, upload the key to a keyserver, and send an email "from" [email protected], signed with that bogus key. Enigmail will let you quickly fetch the sender's public key by fingerprint from the keyservers if a message is signed and you don't have the public key in your keyring yet, which is kind of nice. I assume it only verifies that the downloaded key actually has that fingerprint if you are running the newer versions of gpg that do this for you. > Or do you have other goals? > - convey a key directory where updated keys can be found? > - convey a signature over the sender's email address? I was thinking of these as separate and specific to the particular "well known" mechanism. Our model is that key updates can happen from any mechanism that is of equal or higher 'validation level' (where we define a scale and categorize each class of mechanism). We would not limit updates to what was in that first header, but it certainly provide a hint as to where to look. -elijah _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
