Lets fix email addresses.
http://tools.ietf.org/html/draft-hallambaker-prismproof-key-00
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(_at_)example(_dot_)com
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(_at_)example(_dot_)com
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(_at_)example(_dot_)com
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(_dot_)arkko(_at_)piuha(_dot_)net> 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/