On Thu, Aug 17, 2023 at 1:32 PM Donald Eastlake <d3e3e3@xxxxxxxxx> 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 +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
On Thu, Aug 17, 2023 at 12:23 PM Phillip Hallam-Baker
<phill@xxxxxxxxxxxxxxx> 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:alice@xxxxxxxxxxx, 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 <daedulus@xxxxxxxxxxxxx> 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
