On 08/28/2014 07:00 AM, Simon Josefsson wrote: > I have updated a six (!) year old document describing the OpenPGP > mail/news header field. As it encourages and promotes use of > encrypted/signed email, I thought it would be relevant to this list. > All feedback is appreciated, either directly to me or here. > > http://tools.ietf.org/html/draft-josefsson-openpgp-mailnews-header-07
I am excited to see that you have resumed work on this. There are a ton of projects working on new forms of 'easy' secure email, and they are all experimenting with, or planning to experiment with, new forms of key discovery and validation [1]. The nearly universal goal is automatic key management without the need for user intervention. I think that the OpenPGP header, or something like it, could plan an important role in bridging what we have now to some of the ambitious schemes proposed for the future (e.g. ppe, nyms.io, CT for email, dime, etc). There are some things that some projects have said they plan to do that are problematic, for example attach the sender's public key in every outgoing email or use the fingerprint from the signature of signed messages to discover keys (since these are easily spoofed by a MiTM). Everyone wants to get away from the WoT and from CAs. I think this is good, and that an OpenPGP header could help facilitate this, if it was written with a slightly different intent. Currently, the goal with OpenPGP header is simple untrusted advertisement. As the draft makes clear: > Because the mail header is typically not integrity protected, the > information conveyed in the OpenPGP header field MUST NOT be trusted > without additional verification With some slight modifications, I think the OpenPGP header could support the kind of thing that many of the new generation of email security projects are looking for, namely a secure in-band user-to-user mechanism for key discovery and a way to validate this key with the service provider when supported. Although it is *usually* the case that headers are not integrity protected, they certainly can be with DKIM, which is growing in popularity (as gmail is going to effectively be forcing it on everyone). Even without a DKIM signature, a client could validate the advertised key with the provider if the header provided some clues as to how this could be done. Unfortunately, I don't think these 'how to validate clues' can take the form of an arbitrary URL. As you note, arbitrary URLs are problematic in that they can effectively be used as 'email bugs', tracking who received the message and when it was received. Also, an arbitrary URL can be completely bogus. For example, something like: provider-endorsement: webfinger, dane is better than provider-endorsement: https://example.org/.well-known/webfinger?resource=acct%3Acarol%40example.org Even if the headers are completely unsigned, a client can be smart enough to say, "aha, I understand webfinger, so I will contact the domain in the 'from' email address and query webfinger via https". Provider endorsement of keys is not ideal, but I think it is an important stepping stone toward what we eventually want, and also it is much better than plain TOFU with zero attempt to validate. Once clients are accustomed to provider endorsement, these same clients can be written to audit their providers to ensure they are not advertising bogus keys on their behalf. In what form this auditing will take is the topic of much discussion (everything from network perspective, n-of-m consensus, or a Certificate Transparency style append only log), but it would be good to create an OpenPGP header that can lead us in that direction. Many people will rightly object that provider endorsement is limited because it requires participation from the provider. On the other hand, there is a rapidly growing list of provider who plan to offer OpenPGP encrypted email (including, of course, gmail and yahoo). Many of these models are not great, and the private key is not kept secret from the provider, but provider endorsement could still be useful in these cases in the interest of interoperability. Perhaps what I am describing warrants a separate header. I think it is close enough that it would make sense to combine with OpenPGP header. In the case of LEAP, we have implemented support for the OpenPGP header in the automatic key manager of our client, both sending and receiving, but we are not going to support arbitrary URLs or key ids. It is 2014, after all, and there is no reason to not use the full fingerprint, especially since this is intended to be read by machines. -elijah [1] https://github.com/OpenTechFund/secure-email (pull requests welcome) _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
