Re: Expired e-mail addresses

[Donald Eastlake <[e-mail]>]

Phil,

You say "The main cost of running such a registry is supporting the
query function" but I don't think so. My understanding is that the
dominant cost of being a credit-card issuer is handling
complaints/chargebacks/lost-cards. Similarly, I think for a registry
such as you describe, the dominant cost would be handling lost/stolen
keys or, more precisely, handling/verifying claims that a key was lost
or stolen.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Thu, Aug 17, 2023 at 12:23 PM Phillip Hallam-Baker
<[e-mail]> wrote:
>
> 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