Paul, I really want to see a new draft rather than comment further on this, but one point below in the hope of contributing to that draft... --On Thursday, September 17, 2015 02:27 -0400 Paul Wouters <paul@xxxxxxxxx> wrote: >> Yes, but not the other way around. Note my example of >> john+bank@example which works in SMTP but not in this design. > > It works fine in this design if you publish the record at > sha256(john+bank) > or add CNAMEs for your john+FOO email addresses. Adding the > CNAME's > should be easier than adding them as valid ID's on your > OpenPGP key. I either still don't understand how you are proposing that this works or what you are saying (here and in the document) is contradictory. AFAICT at this stage (including our off list conversation), there is no requirement that all addresses have matching DNS entries so that, if I use example@xxxxxxxxxxx, example-1@xxxxxxxxxxx, and example+2@xxxxxxxxxxx but create corresponding DNS entries for only the first two, I won't get encryption for the third. That makes me no worse off than I am today for that third address and better off for the other two. Since John Levine and others read the document differently, I encourage you to clarify that in the next version (if it is correct and more important if it isn't). Assume we mark up everything we don't know for sure, including how useful the approach will be with the above and whether or not hashing [1] is useful, to "experiment" and move on for now [2], I still don't understand the relationship among the email address, DNS label, IDs on the PGP key, and PGP key validating signatures. See if the following clarifies where I am confused. The document seems to say that I should not trust a key found by this method just because of where I find it. That is entirely consistent with other PGP documents and existing keyservers. I should, instead, rely on web of trust relationships, e.g., signatures on the particular key. Ignoring example+2@xxxxxxxxxxx entirely because the recipient declines to put a record for it in the DNS, and using "transform()" for whatever hashing and label-adding you apply to get to the record owner you want... Case 1: Assume that recipient has a PGP key with email addresses example@xxxxxxxxxxx and example-1@xxxxxxxxxxx on it, both signed by someone trusted by the sender. The DNS records are transform(example@xxxxxxxxxxx.) IN OPENPGPKEY key... transform(example-1@xxxxxxxxxxx.) IN CNAME transform(example@xxxxxxxxxxx) Now, for this case, neither of the transformed forms actually appear on the PGP key, so any signature-checking has to be done against the original email addresses. That is fine from a PGP standpoint. However, DNSSEC provides no help because one cannot presume a trust relationship between example.com. and example.foo.: all DNSSEC validation of the CNAME proves is that the record is intact. In particular, it doesn't indicate that example.com has given permission for the alias nor that there is any real relationship between the names from a trust standpoint. I hope that is clear; if it is not, note that transform(example-2@xxxxxxxxxxx.) IN CNAME transform(example@xxxxxxxxxxxxxxxx.) would validate equally well (and would validate whether evil.example.org actually exists). Case 2: As above, but you expect your hash to be added to the PGP key as an address to be signed by everyone who has signed the other two addresses on the key. That is a big deployment factor that doesn't appear to be mentioned explicitly in the draft. Things still work, but, because of that deployment factor, "opportunistic" takes a step backwards. Because addresses on PGP keys are generally assumed to be real email addresses, the would-be recipient has to be sure that the hash is considered a valid address by whatever delivery server is being used and add it as an email alias. That is an even bigger deployment issue, especially if either the hash is not considered to be a valid address at that server or the server operator does not support mailbox aliases (only separate mailboxes). I'm happy to leave the question of whether there are enough restrictions in practice to make your approach infeasible as an experiment, but I think that needs to be spelled out. Note also that this implies that, if I don't use CNAME (see below), every time I create a new OPENPGPKEY record, I need to add that hash to the key and get it re-signed. Case 3: Only example@xxxxxxxxxxx and/or the hash part of transform(example@xxxxxxxxxxx) appear on the key and are appropriately signed and the DNS records are as above. I suggest that, because of the DNSSEC CNAME issue _and_ the absence of an address and signature associated with example-1@xxxxxxxxxxx., that address must be considered inappropriate for the use of PGP. So "adding CNAMEs for..." just doesn't seem to me to be helpful, at least without further explanation of what you have in mind or some intra-zone restrictions. There is another twitch in this that is as much a PGP issue as anything to do with your approach. Latent in some of my earlier comments, and maybe some of John Levine's, is the fact that, if I have a properly set-up and signed key for john@xxxxxxxxxxx, I'd like that to be considered the key for john+xyz@xxxxxxxxxxx but not for john-abc@xxxxxxxxxxx. John might have a different preference. We would both also like ponies because the only thing that keeps those preferences from violating the 5321 "no interpretation except by the delivery server" rule is that we control the addresses and how they are interpreted by the relevant delivery servers. If a sending MUA or Submission server says anything equivalent to "I see john+xyz@xxxxxxxxxxx, I should look up a key for john@xxxxxxxxxxx and use that to encrypt" it has crossed the line, at least absent out of band instructions that are specific to how I organize addresses [3]. An SMTP relay that does it is out of line under _any_ circumstances. best, john [1] I believe hashing is unnecessary, a potential source of confusion, and a waste of time and energy. Depending on how the hash is used, I think it violates the intent of the RFC 5321 prohibition, but not necessarily the latter. I don't know that it is harmful except insofar as it reduces the usability of this feature (and that, it seems to me, is a reasonable experimental question) [2]. [2] Again, I hope you will describe what is actually considered experimental in the next version and will probably protest further if you do not... precisely because these sorts of issues show why that is important in this case. [3] A standard for subaddresses might help with this and might justify changes to sending MUA and/or OpenPGP interpretation of addresses for lookup, but we have no such standard.