Re: future of identifiers

[Phillip Hallam-Baker <[e-mail]>]

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

      [e-mail]
         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.

      ?[e-mail]
         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?[e-mail]
         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 <[e-mail]> 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/