Re: standards? (was: Registration details for IETF 108)

Phillip Hallam-Baker <> Fri, 19 June 2020 02:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A66D3A1046 for <>; Thu, 18 Jun 2020 19:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fn4cejsQtjUs for <>; Thu, 18 Jun 2020 19:25:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 549AD3A103F for <>; Thu, 18 Jun 2020 19:25:59 -0700 (PDT)
Received: by with SMTP id i74so7134539oib.0 for <>; Thu, 18 Jun 2020 19:25:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9VOzOgpJoYdqTQBwK6Plhay5rX1OyanQpQcm82C9hQc=; b=HL9upA5/Do/cI0Yf0RYkWD8W0E00JM8oA6dpW5g4BDfryo5WrJ6PxDRoBwohevuLmC eYkt1WMN9v2jG94Rdx7x/DHtX9O7/fXWf7ulwteaEoDqufhfw11mY7ni8BzOg8Kqv7Fi DBEZFglfmTuSrXOQ96zyF1Ixh0+eW+saJ0fRMw2/lk7wX1iAklCAqXVzYo0xtZlcbcal JvbOUdmVRzJ3+YFvOQqTXe57f+XHsGwK3XK28RQ9ifTIKjWxjHln6sbjn+LozPQdkZ4K 0EBRn1f25yDwuwiFcsYz6fuByR0MfjDnXsNLcEq3QFHSmJyQtMxfIeK+tnkWu4E114hE 9xfA==
X-Gm-Message-State: AOAM533VMVxHFUBmz95hrt38joMskXUrnrEF3MAqrLUskUeUbYVksarv nrNWkBXGiL0ADwwoWxi73vv2u6SqdAyzJ/A0Q7pX6pue
X-Google-Smtp-Source: ABdhPJzu4QlPWsmf+PI0wM3R+jnUxYadk4jYY5R6gIS54b93Qz5yKAJPZper1gYJsED5DvCOBcTrDexFu3ZdIcm0J0g=
X-Received: by 2002:a05:6808:487:: with SMTP id z7mr1596651oid.166.1592533558413; Thu, 18 Jun 2020 19:25:58 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <01d701d638ca$c096b5e0$41c421a0$> <> <> <> <> <> <> <> <1UWAyqDxFn.1IOJoXgqe8i@pc8xp> <> <> <> <> <> <> <> <> <00b801d640f9$5afe7bf0$10fb73d0$> <602817EB7E0004CD1FD5CCC5@PSB> <> <> <5219.1592505397@localhost>
In-Reply-To: <5219.1592505397@localhost>
From: Phillip Hallam-Baker <>
Date: Thu, 18 Jun 2020 22:25:47 -0400
Message-ID: <>
Subject: Re: standards? (was: Registration details for IETF 108)
To: Michael Richardson <>
Cc: IETF Rinse Repeat <>
Content-Type: multipart/alternative; boundary="0000000000000acf0b05a8669d8e"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Jun 2020 02:26:01 -0000

On Thu, Jun 18, 2020 at 2:36 PM Michael Richardson <>

> Phillip Hallam-Baker <> wrote:
>     > There is another patent even more interesting that has now expired:
>     > Micali's fair exchange with invisible trusted third party. This
> allows
>     > Alice to send a message to Bob such that Bob can read it if and only
> if
>     > Bob provides a receipt. The TTP is only involved in the case that
> Alice
>     > defects and does not release the decryption key after Bob signs the
>     > receipt.
>     > Now replacing SMTP is obviously futile, a non starter. There is too
>     > much water under that bridge. But deploying a new open transactional
>     > messaging system that is designed for purpose of transactional email
> is
>     > certainly not futile. In fact it is something we clearly need now
> that
>     > the business processes exist that can leverage it.
> I want to say two interpretations, and I'd like you to pick one or the
> other:
> 1) SMTP in unreplacebale, but (S)MIME format email can be replaced,
>    being a different media type across SMTP. (Possibly a new verb
>    replacing MAIL To)
> 2) SMTP as a transport could be augmented with some transactional message
>    system, that in the end moved (S)MIME formatted emails.
>    This is in much the way that HTTP has reused headers... (but HTTP/2)

Neither. But a little bit of the second.

I started off looking at the problem of how to make management of
credentials for OpenPGP and S/MIME so easy and transparent that people
could make use of end to end encrypted email without having to think about
it. Zero extra effort.

So lets say we meet in person at IETF, I present my iPhone to you with a QR
code, you scan it with your android and we both come away with a complete
contact record for the other, our S/MIME, OpenPGP, Signal, etc. etc. keys
and the means to update them as they change for life (or until one or other
of us decides to drop the connection).

[We can do other forms of exchange but lets leave that for now]

OK so now we can do end to end email over SMTP if we like. But here is the
problem, the infrastructure I need to support that contact exchange scheme
and do it really right is a messaging infrastructure in its own right. And
it has access control so people can't send me email unless I authorize them
to. So no spam. And the messages are limited to 32KB so the inbox doesn't
get clogged up because some twit sent a huge message (anything longer has
to be pulled).

So basically, fixing SMTP means that we end up building a second scheme and
doing it right.