[Arcing] The PrismProof Naming Games

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 06 April 2016 23:53 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: arcing@ietfa.amsl.com
Delivered-To: arcing@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CDCF412D14D for <arcing@ietfa.amsl.com>; Wed, 6 Apr 2016 16:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OIJkjNm5FedB for <arcing@ietfa.amsl.com>; Wed, 6 Apr 2016 16:53:04 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92A812D160 for <arcing@ietf.org>; Wed, 6 Apr 2016 16:53:03 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id n1so43191251pfn.2 for <arcing@ietf.org>; Wed, 06 Apr 2016 16:53:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:message-id:subject:mime-version; bh=fWLmgalKkdJvkYVC/AuiuNej3tR9/5K02GcB8yNDajc=; b=iPVpDvSIU9gOP+lKwbgjVI9lcRNK66I08nTcLIB6fUBgh5GXLCas6taPVOEqYw6Mcr ZHmtCRZ5FcCvNdM99rOt77foraT4w2nFqM7FfpISZGVgLc4sVYEGji71oHaeXHnTcSqU yRnoCIIMBGiRfrsZuYnrlv20WMXJar6vAnvHumkHEVWBxJ4vLO0sVlYeeiwpX4ERyL04 VVSYLFQkwmo0fBvApu8ymG1BD7X8W2G/EHNW/JCZVyC0LWFTzsENtos5A/Yj71v1gat+ Tm268yxFPZ4vHdkx06Hb0JyKa7DsSEODKxeMQ56c0bolcCeX+O01WTJfCjB1m1xWnQMo u2ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:message-id:subject :mime-version; bh=fWLmgalKkdJvkYVC/AuiuNej3tR9/5K02GcB8yNDajc=; b=cMCHhPO7rADGUAUJ39hwKWbhcRl9ziMFKveyz22LluKEFyCLqFbEXkGIcAkkh7neEb e3kYoX4jsJHsWkJyouHotTwCZ42wOgKITahGWAf4pq0M/aRaZ1TVu5FsECYAdxQR6wmM 4EIUaJT4RStcFYqM35BznSM6o9gY5A19OWjmIln6E2gwP1IX0sxm3Ved5iB9HA8+hinx JBYdSqkCib+WhQJ2daxJmQ/ec+eIxnG/gl9+6NF8xL+0P4783OHTBpPi5RAADEBZHmGw 2hw7grzxuI7uczFWa3MRTfqJf/8XvDe0eY0jqF2VFqOXhKX8y7gLOdiNPsNPqH4Ygtps TriA==
X-Gm-Message-State: AD7BkJKPb4fIog7ni0+BMjHVgOCDba2VUnSsqGEFGnnZ/V5tlYIMzwnVdkS4PEzzEnXvUg==
X-Received: by with SMTP id d7mr88239pfb.77.1459986783302; Wed, 06 Apr 2016 16:53:03 -0700 (PDT)
Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. []) by smtp.gmail.com with ESMTPSA id 62sm7335017pfk.83.2016. for <arcing@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 16:53:02 -0700 (PDT)
Sender: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wed, 6 Apr 2016 23:53:00 +0000 (UTC)
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: arcing@ietf.org
Message-ID: <994C5976EA09B556.213991A5-DB27-4B37-8DB6-1060D55ACCC7@mail.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_684_1777269432.1459986780791"
X-Mailer: Outlook for iOS and Android
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/yQGVnmU8Q3cTj3jBI3tqUjwQ5iA>
Subject: [Arcing] The PrismProof Naming Games
X-BeenThere: arcing@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names <arcing.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/arcing>, <mailto:arcing-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/arcing/>
List-Post: <mailto:arcing@ietf.org>
List-Help: <mailto:arcing-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arcing>, <mailto:arcing-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2016 23:53:07 -0000

I see two types of naming scheme:
1) One that avoids ambiguity by means of a registry2) One that avoids ambiguity by means of random or cryptographic techniques   2a) Random strings (e.g. GUIDs)   2b) Cryptographic digest of the data itself - limited to static data   2c) Cryptographic digest of a public signature key - permits identification of dynamic data.
The last is the most flexible that does not require registration.
A while back, as part of my PrismProof usable end-to end email project, I looked into ways of creating email addresses that had the following properties:
1) Compatible with existing email clients, contacts directories etc. Can be entered without code changes.2) Break when existing SMTP infratrustructure attempts to process3) Contain a fingerprint of a public key that is a root of trust for an email user.
The objective here is to be able to use an existing email client (Thunderbird, Windows Live Mail, Outlook) to send and receive S/MIME and OpenPGP encrypted mail with zero user impact and without the need to make use of an application plugin. All the 'PrismProof' part was performed by an SMTP/IMAP proxy performing any necessary encryption, key discovery, etc.
[Obviously, this is not the desired endpoint, I want apps to support the infrastructure native. But I have come to loathe application plugins because they do not compose]
The fingerprint format I am using is not particularly important here except to note that it is designed to support versioning and also resist content type substitution attacks by calculating BASE32 (SHA-2-512 (<IANA-content-type> + ":" + SHA-2-512 (<content>)))

So the approach the initial SMTP code took was to use the fact that a question mark is a de-facto non permitted character in an email address even though most clients accept use.
In the 2014 implementation, this was interpreted as 'send mail to alice@gmail.com but only if an email security profile for Alice@gmail.com can be located that has a valid signature with a key authorized under a trust root with the fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ'

Which worked well enough for SMTP.  But then I got thinking of things like, how do I make use of the same approach in other applications, how do I make that General?
So I started looking at
Which looked good till I realized that, 1) I am not doing TOR and 2) in my world, the root of authority is that fingerprint. It specifies the entire trust context in which all else is interpreted. It could specify a different DNSSEC root, it could specify WebPKI roots.
So really, the email address should be:
Or if the profile is personal to just Alice and specifies where to send mail, it could just be

Sent from Outlook Mobile