On Mon, 14 Mar 2016, John C Klensin wrote:
However, consider a different case. Assume I have a message, whose content I consider sensitive, that I need to transmit to a party I know but with whom I have not corresponded by email before (and, therefore, Doug's "replying to message" case does not apply). Now I don't need to send that by email. I may have the post, fax, assorted courier services, reading it on the phone (PSTN or VoIP), transmission it by IM or text message, and other methods available to me. I might even consider semaphore flags, not because they are "secret" in the "out of sight" sense but because very few people can read them these days and because the message information is more transient and volatile than most of the above. In ranking the above for preserving the secrecy of my sensitive message and making a choice of method, it is at least as important for me to understand just how secure a given method is as that it be "secure" in the abstract.
If your information is "sensitive" then hopefully you could tell your email client that. That email client might try various things, including looking up an OPENPGPKEY record. When found, it could look at signatures - maybe even trying to look those up using OPENPGPKEY or on existing pgp keyservers. It would present you with the data for you to make an informed decision.
Now, _in that context_, your second option is a big problem because it implies accidental disclosure
The accidental disclosure to a "wrong email address" is not worse when encrypted than it is now if you send it unencrypted. If you risk mistyping the username and encrypting it to the wrong user, this draft cannot help you. It has no powers to mind read the user.
So it seems to me that, at least for information perceived by the sender as sensitive enough to deserve special treatment, the "otherwise the message goes in the clear" case is not applicable because the actual case is "otherwise the message doesn't get transmitted over Internet email".
I know of no way to codify the user to email agent interaction based on "user considers content sensitive" other than the user stating "send this message encrypted only", which something like enigmail, a thunderbird email client plugin, can already do. You mistyping the email address again is not something we can protect against in a protocol. You could have a local policy of saying "always confirm email address before sending to any address for the first time" but all of this is completely out of scope for the document.
[1] As an aside, if I've got a trusted way to obtain that fingerprint without using the DNS, I most likely have another way to obtain the key so I don't need this I-D and protocol.
But you cannot tell if pgp.mit.edu is down, or whether an attacker is actively blocking you from obtaining the target's public key. With OPENPGPKEY, you can. Paul