[Cryptography] Anonymous rendezvous (was Business opportunities in crypto)

[Phillip Hallam-Baker]

On Tue, May 4, 2021 at 2:03 PM Jerry Leichter <leichter at lrw.com> wrote:

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

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.

The WebPKI was designed to do two things:

1) Allow a party with an established reputation to claim it on the Web.
2) To allow a party with no reputation to establish that they are
accountable to some civil authority.

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.


The WebPKI works fine for organizations but the model doesn't really work
for people. Validating a key purporting to belong to alice at example.com is
really non trivial unless example.com 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.

That is why I am planning to take a different track with the Mesh callsign
registry.

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:

{"callsign" : {
"id" : "@alice",
"key" : "MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4"
"service" : "example.com" } } [Signed MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4]

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.

Of course, this doesn't provide any proof I am talking to the 'right'
'Alice', just the first person to register the name.


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.


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210506/2139c267/attachment.htm>