Re: future of identifiers

Phillip Hallam-Baker <> Wed, 30 October 2013 03:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C207E11E831A for <>; Tue, 29 Oct 2013 20:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4lUCH7S-YFPe for <>; Tue, 29 Oct 2013 20:44:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) by (Postfix) with ESMTP id 171B411E831D for <>; Tue, 29 Oct 2013 20:44:15 -0700 (PDT)
Received: by with SMTP id c11so764277lbj.31 for <>; Tue, 29 Oct 2013 20:44:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KI2dx+ORyA/jInmefrbBsWnVJD8JOEIyscOtXAUjwcU=; b=dxkX2Sr07vxyAmNmYC+S9Nz99tVa3AL0LLsAPolKCKuui0vVvPb72MezyxEQgMTwze d+VK3W6KiqPX3nquELKn5abM/qxc/ZJitD4Xl4xu+rFjCJTqXF4KmNfTYTYzNYuPXYak FRTp/c7Mb0NSimS+T2dOiB3JZ7NSdGZc88LhqZoTk6AzVRb3W7NmQkFTY5u0lTRumxYd 444hDiR17mgqnkI8OylW5SeztCZuS64PcrULgBufbYs4qbQ/P+G905IfvkN5Col2f2RJ So+mt33u3ty4fiqNOspQ/BHjzBKEqR+rD17R6GgR+niSwUBaZQWcy+rGDU3CJgmGAW5D ovYg==
MIME-Version: 1.0
X-Received: by with SMTP id zv9mr18912lbb.48.1383104654812; Tue, 29 Oct 2013 20:44:14 -0700 (PDT)
Received: by with HTTP; Tue, 29 Oct 2013 20:44:14 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 29 Oct 2013 23:44:14 -0400
Message-ID: <>
Subject: Re: future of identifiers
From: Phillip Hallam-Baker <>
To: Jari Arkko <>
Content-Type: multipart/alternative; boundary="001a11c259aaa32d9204e9ed2559"
Cc: " Discussion" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2013 03:44:18 -0000

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).

         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.

         Send email to Alice using encryption if and only if an
         encryption key for Alice can be found, otherwise report an

         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

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

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 <> 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
> Jari