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

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

On Thu, Jun 18, 2020 at 2:36 PM Michael Richardson <[e-mail]>
wrote:

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