Re: Expired e-mail addresses

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

This is a much more general problem with email: DNS names are rented not
owned, email users have much less than a DNS name.

It should be possible to have an email contact address that never expires.
Yes, they blew it for SMTP, but SMTP holds a diminishing share of the
messaging market. The EU is pushing the walled gardens to support
interoperability. Permanent email addresses are an easy technical problem,
the real issue is social and business.

As always with these things, if you have no spec people demand a spec, then
when you propose a spec, they demand code and once you have code, they say
you are just protecting your code. Well I do have running code, but that is
besides the point. There is really only one approach to permanent human
readable email addresses that makes sense.


First, begin with an unreadable identifier, a fingerprint of the user's
public key. I have tried to make this format as compact as possible and
this is the best I can do to make it pretty for use in a document or
business card:

MDDK-7N6A-727A-JZNO-STRX-XKS7

That is a truncated SHA-2-512 fingerprint in UDF format, if people were
going to use these, the best approach would be to present these to the user
for verification and improve the precision when validating the actual
public key. So we can go from the 120 bit work factor above to 260 bits:

MDDK-7N6A-727A-JZNO-STRX-XKS7-DJAF-XI6O-ZSLU-2VOA-TZQ6-JMHP-TSXP


If this is the user's permanent public key, we can create a permanent email
identifier by establishing a registry to which users submit signed
assertions of the form 'my current active messaging addresses are mailto:
[e-mail], signal:666-666-6666, etc' only in JSON because JSON is
kewl. Or as is the approach in the callsign registry, a signed assertion
giving the current location from which a signed contact assertion can be
obtained. This allows for access control on the contact information.

The natural way to run such a registry, as I proposed back when I tried to
buy out the Haber-Stornetta patents before Bitcoin or Blockchain existed,
is in a chained notary log. I have plenty of prior art. Use of a notary log
allows the potential ambiguity of which update was submitted last to be
eliminated.


But once one decides a registry with a notary chain is needed for any
purpose, it might as well issue human readable aliases which map to the
fingerprints. A very marginal increase in technical complexity. So I can
have @phillip_hallam-baker, @phill_hallam-baker, @hallam and @phb all
mapped to the same fingerprint. And I can have other aliases mapped to
different fingerprints for pseudonymity.

Now of course there are a few IPR etc issues, which I go into at length in
the draft. The bottom line is that just as with any other aspect of
security, the issues of trademarks etc. are so much easier when you
consider them up front rather than pretending they do not exist and then
creating a very expensive band aid.


The main cost of running such a registry is supporting the query function
and so I propose that be something done by other providers. The registry
just publishes the updates to its incremental log in real time and let
other folk do the query. This is critical because a callsign registration
is (normally) for life. Try to register @microsoft if you are not the
Redmond Club and it will be lawyers at dawn.

It would be necessary to charge for registrations to stop the system being
spammed into the ground by squatters. But that could be a very small one,
$5 for 50 registrations should be enough to meet the costs of the registry.
Since supply is limited and so as not to leave money on the table, I
propose to charge exponentially higher prices for names shorter than 9
characters. This surplus then goes to support development of secure open
source software, contribute to standards organization running, etc. etc.


The callsign registry is described here:

https://datatracker.ietf.org/doc/draft-hallambaker-mesh-callsign/

The callsign registry does not require use of the other Mesh technologies.
But I am not aware of anyone else really developing a PKI designed for
personal use by non-technical people. My criteria here is not 'could my
mother use it', she has a science degree, My criteria is 'could my wife use
it without constantly asking me for tech support', she has a degree in
rocket science from MIT.

https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/


On Thu, Aug 17, 2023 at 5:53 AM tom petch <[e-mail]> wrote:

> Is there anywhere, RFC Editor possibly, that tracks changes of e-mail
> addresses for contributors?
> I just posted a response to an Erratum and got a number of bounces, one of
> which was a change of address, change of affiliation, for an AD; this is
> something which could equally apply to any author.
> I have also seen WG Chairs struggle to contact RFC authors in relationship
> to IPR issues or with respect to updating an elderly RFC, likewise IANA
> with regard to registrations..
> It would seem to me that it matters, sometimes more than others, that we
> can still contact people who have contributed in the past.
>
> Tom Petch
>