Lets fix email addresses.
A Strong email address combines an address with a security policy indication and an optional public key identifier.
The key identifier is a hash of the publicKeyInfo block for the key (or a PGP key fingerprint for backwards compatibility).
KeyIdentifier: ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA
alice@xxxxxxxxxxx
Send email to Alice using encryption if and only if an
encryption key for Alice can be found and Alice has published
the email encryption policy 'encryption preferred' or stronger.
?alice@xxxxxxxxxxx
Send email to Alice using encryption if and only if an
encryption key for Alice can be found, otherwise report an
error.
ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-
VAA?alice@xxxxxxxxxxx
Send email to Alice using encryption if and only if an
encryption key for Alice can be found that is directly endorsed
under the specified key, otherwise report an error.Using strong email addresses allows us to address a wide range of urgent commercial use cases. For example:
Doctor sending an email to a nurse with patient information in it
Lawyer sending a message about a client
Financial adviser sending a message to a client
Company sending a bill to a customer.
These are all valuable commercial use cases that enable paper processes to be replaced with cheaper and more convenient electronic processes.
I can add my strong email address to my linked in profile.
An infrastructure is required to resolve key identifiers to keys but it can be a very simple well-known service lookup or a vcard.
We have 95% of an encrypted email solution today. This proposal adds the missing 5%. It is a scheme that can be understood by ordinary people.
Under the covers, the normal S/MIME and PGP can take place. But people don't need to look under the covers.
I might need to trust a CA to find me a strong email address for a recipient. But once I have found a strong address I don't need to do that again.
I do have a business model etc. but its not the dopey idea of expiring keys every year and having to pay to reissue them.
On Tue, Oct 29, 2013 at 10:38 AM, Jari Arkko <jari.arkko@xxxxxxxxx> wrote:
For background, when I visited the ICANN meeting last summer, they were about to launch a set of panels to advice themselves about key topics in coming years. I promised to join one of them, on identifier technology innovation (along with a few other IETFers). The topic for this effort is future evolution of DNS and other identifiers, including relevant security and management aspects. The viewpoint is primarily to look at this from ICANN’s angle, but of course the matter is interesting to us others as well.
And perhaps we at the IETF should also understand the same things. Hence this e-mail.
I have some ideas on what some of these trends might be. But what do the rest of you think? Where is identifier technology going, and what new things are on the horizon? What do we need to do with IDNs? DNSSEC? What will DANE lead to, and how will id-locator split techniques evolve & be deployed? How will applications or users think about identifiers in the future?
More information at http://www.ietf.org/blog/2013/10/future-identifiers/
Jari
Website: http://hallambaker.com/