>The goal is to create a simple way to find <email key> for a known >correspondent. >Can we assume that the email encryptor knows the address of recipients in a >format emitted by the recipients email >system, and is that good enough?
I have a stack of business cards on my desk about 10cm high. Every one has at least one e-mail address that I am presumably expected to type in by hand. (Two have QR codes, but they have text addresses, too, which is good since my laptop doesn't have a QR scanner.) With internationalized addresses, the fuzz problem gets a lot worse. Domain names have normalization rules so there's no ambiguity about whether to use the separate or precomposed accented letters and the like. But internationalized local-parts remain totally opaque to the sender. I expect that inbound MTAs will do lots of normalization on incoming addresses, but there is no way to predict from the outside what they'll do, or what their internal normalized format will be. This means that hand-typed internationalized addresses are unlikely to match the internal form the recipient MTA uses without some intermediate massaging, and nobody but the MTA knows what massaging to do. >I think we can publish OPENPGPKEY draft as is tagging it as Opportunistic key >lookup, > if it has to be labeled EXPERIMENTAL that is fine. That seems appropriate. The design is well-defined, but we have no experience to tell us whether it'll be workable in practice. This reminds me of the early EAI drafts which were also experimental. The address protocol was well defined, but it turned out to be unworkable in practice, so for the standards track we did something different. R's, John PS: I still don't understand the opposition to base32. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
