Re: Expired e-mail addresses

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

On Thu, Aug 17, 2023 at 1:32 PM Donald Eastlake <[e-mail]> wrote:

> 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.
>

That is a cost associated with the registry but an easy one to deal with
some forethought.

The full proposal is that there is a process for registering a signed
challenge on the chain, so we immediately get past the whole issue of
notification of the DNS name holder that plagues UDRP.

The fee for making such a challenge can be set to recover costs in full. I
expect it would be similar to the fees IETF charge for providing a
certified copy of an RFC or Internet draft, say $200.

Then the full costs of the dispute arbitration can be shovelled onto the
parties in the dispute. Either they agree to arbitration or the registry
hands the matter off to a US court. There is a process in US law which
allows an entity holding something in trust to pass off the dispute to a
court saying 'we have no opinion on this, we will abide by the court
decision'. I know quite a bit about that process since one of the messups
we inherited with the Network Solutions acquisition was the whole sex.com
mess. The answer to why we didn't use it in that case being, that NetSol
could have if they had been less boneheaded at the start and by the time we
got involved it was far too late.


The issue of lost keys can be handled in a very similar fashion. First note
that I have a very extensive and capable infrastructure for managing
private keys. I am proposing a system that gives end users rather more ease
of use and recovery options than we ever had for CAs in PKIX.

I am firmly opposed to the crypto-perfectionism approach which leads to
nonsense like Signal thinking it knows how often I should be
reauthenticating my device with my PIN, etc. Some users definitely want a
system in which the loss of their key means all their data is rendered
permanently irrecoverable. But most people do not want that. They want the
exact opposite and since they are not spending their time crime-ing, their
concern that the police might get a warrant is much less than their concern
they might lose the pictures of the kids when they were 5.

That is a whole area I have spent five years thinking about and I provide
users with a range of tools to manage their security in the running code
and the architecture is expressly designed to allow for even more. For
example, I do not currently support threshold signatures using the profile
signature key which is their root of trust, but that could easily be added.


Again, the strategy is to shovel these costs off onto another party, in
this case the Mesh Service Provider. I would hope these would compete by
offering extensive key recovery capabilities appropriate to the communities
they serve. The callsign registry does not manage user's Mesh profiles or
have any long term interactions with them. It is a consumer of Mesh
authentication, not a provider.

The callsign registry I propose is the thinnest of thin registries. I am
pretty confident I can meet the $0.10/name for a lifetime registration. It
might be necessary to charge for registration updates but I think that can
probably be avoided.



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
>