<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 4, 2021 at 2:03 PM Jerry Leichter <<a href="mailto:leichter@lrw.com">leichter@lrw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>In the real world, a number of things make this a reasonable thing to do.  It costs a lot of time and money to create that physical store - it's highly unlikely it would be worth it to anyone to fake it.  I can see plenty of other people shopping in there, apparently happy with the experience.  Sure, they could be plants - but what would be the point?  So even though I know nothing at all about who those people are, I can still trust what I see of their experience.  And if Macys really does cheat me I can bring legal mechanisms into play - and the store will still be there so I will be able to find them to go after them.  The real-world Macys is embedded in all our entire physical, social and legal frameworks.  In an important sense, in the real world, we never trust anything anonymous:  We're always starting with some kind of connection and strengthening it, not trying to create it out of nothing.  Visit a foreign country where you know no one and no one speaks your language, where you don't understand the culture, where you're missing those fundamental connections, and it's much harder to get things going - but at least you do share the base-level connection that you're among human beings and human beings are pretty much the same. And building a big store is expensive everywhere in the world.</div><br><div>None of these mechanisms apply at the Macys web site.  Creating web sites is cheap.  Hiding who's behind them is cheap.  Reputation mechanisms are supposed to be the equivalent of all those people in the store (and of friends who've been there and trust the place) but they don't scale, as I've argued previously.  The entire fabric of interconnections breaks down, or can be easily broken down by attackers.  Trust isn't transitive, and trust is a basic social good without which society breaks down.</div><div><br></div><div>Who in a virtual world can you trust?  You can bootstrap trust from the real world - I can trust a public key a friend of mine handed to me on his business card.  (It's interesting that that idea - mentioned in early discussions of public-key crypto - never caught on, probably because the keys are just too long.)  I can choose - or be forced - to put trust in a third party:  An organization that creates accounts only for those who the organization accepts; a government on-line identity, as some countries are providing.  All that's fine, as far as it goes - though it creates its own set of issues.  Where it does *not* go to is a purely virtual world with no trusted third parties.  Such a world can exist on its own, but it can't have any trusted ties to the real world out here.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I am not sure how the above is relevant to 'anonymous rendezvous'. It is essentially the design brief that I developed to enable online commerce. The original goal for the WebPKI was to make shopping online to be at least as secure as shopping in a bricks and mortar store. It was NOT about confidentiality, we were limited to 40 bit export crypto at that point.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The WebPKI was designed to do two things:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Allow a party with an established reputation to claim it on the Web.</div><div class="gmail_default" style="font-size:small">2) To allow a party with no reputation to establish that they are accountable to some civil authority.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is not a new problem, it is the problem we solved in 1995. That people decided to ignore what we were trying to do and then insist that we were doing something else entirely doesn't change the fact that we knew what we were doing and why.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The WebPKI works fine for organizations but the model doesn't really work for people. Validating a key purporting to belong to <a href="mailto:alice@example.com">alice@example.com</a> is really non trivial unless <a href="http://example.com">example.com</a> is involved. And DNS names are too expensive for most people -$10/yr is a ridiculous rent for a capability that bears no relationship to the actual service of name binding.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">That is why I am planning to take a different track with the Mesh callsign registry. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The callsign registry is an append only log authenticated by a Merkle Tree. So the name @alice is registered with an entry of the form:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">{"callsign" : { </div><div class="gmail_default" style="font-size:small">"id" : "@alice",</div><div class="gmail_default" style="font-size:small">"key" : "MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4"</div><div class="gmail_default" style="font-size:small">"service" : "<a href="http://example.com">example.com</a>" } } [Signed MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4]</div><br></div><div><div class="gmail_default" style="font-size:small">Registering keys and names at the same time means that there is no need for validation. @alice is bound to MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4 by definition. There is no validation required.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Of course, this doesn't provide any proof I am talking to the 'right' 'Alice', just the first person to register the name.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A relying party can pull up this name and use it to request contact information for @alice which she may or may not be willing to release. That contact info can in turn provide her PGP, Signal, S/MIME. SSH etc. credentials.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If someone were to register @macys then we would have a likely IPR issue. And there is a real problem in that if we use human readable names, people will expect them to resolve to the expected party. So we need a rule to stop name squatting and transfer the name but not prior contacts established through that name. And this may be involuntary in certain circumstances. Obviously @microsoft has to go to the Redmond club or else bad things are going to be happening as the name is used for malice.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So certain registrations may have a TTP EV accreditation associated with them. But those are for the cases where accountability or binding to a reputation is required.</div><div class="gmail_default" style="font-size:small"><br></div><br></div><div> </div></div></div></div></div></div>