[cap-talk] Global name, attribution, etc. rights - Mark
jed at nersc.gov
Thu Feb 24 21:27:50 EST 2005
At 04:19 PM 2/24/2005, Nick Szabo wrote:
> > >Thu, 24 Feb 2005, Nick Szabo wrote:
> > > > > Most crucially, petnames must be connected to reliable sources of
> > > > > information to help the user (and even the user's computer
> > > > > directly) form accurate conceptions of the entities and the
> > > > > kinds of authorities they should be granted, including reliable
> > > > > "hints" for the petnames themselves.
>Jed at Webstart replied:
> > Just to make sure we don't get drawn again into thinking the Petname
> > mechanism has anything to do with developing trust relationships
> > I'll repeat for the record that all the Petname does is to give the user
> > confidence that if they assign a Petname and then later visit a
> > Web site where their browser displays the same assigned Petname,
> > then they can have confidence that they are dealing with the same
> > Web "entity" (Organization (O)).
>Where did the user get the idea that they are dealing with an
>"organization", and that it's the same entity as they were dealing
>with before? The same place where the "O" came from -- a CA, which
>is (the user hopes) one of the "reliable sources of information ... to
>help the user ... form accurate conceptions of the entities."
Hmmm. Here again we seem to be diverging from the simple binding
to an "entity". Again a word (in this case "organization") seems to be
coming with more baggage. Remember that we started in Tyler's
original implementation with a binding to a single certificate (public key).
If the implementation was still the same as originally would you still
have the above question/comment?
I often like to imagine a situation where I'm dealing with a remote
extraterrestrial "civilization" (intelligence, communicable entity,
whatever). All I know is that they are smart enough to be able
to "assign" one or more public/private key pairs. I don't know if
they are blobs all mingling in some soup or are lizard like creatures
on a desert plain or what. I don't know if they are collaborating
behind the keys or are distinct entities or perhaps even have
very loose security for their keys (passing them around at
What I do know is that I have an identity to communicate with.
In principle that identity could be kept closely held by my remote
When Tyler (at my suggestion) moved the binding for the Petname
up a level to the "Organization (O)" in the certificate, he was just
dealing with a technical problem of the situation where a single
entity (organization, whatever) may have multiple Web sites
(IP addresses, DNS names, servers, etc.) that they need to use
to technically facilitate their communication.
The idea was that the certificate authority would assure that a
single entity would always be communicated to when it put that
"Organization" name in the certificate. All the certificate authority
is doing is providing a means to associate multiple certificates
with the same entity. They are, for the purposes of the Petname,
adding no value to any understanding about the remote entity.
In fact one can safely assume that the responsibility for the
binding of the Organization name to the certificates is the
responsibility of the remote entity.
If that doesn't work for you (or others) then perhaps we need to
look for an alternative means of allowing multiple sites to be
associated with one "entity". In any case I believe that notion
is separable from the proposed value added by the Petname
mechanism - namely securely binding a local name to a
>A CA is hardly the only possible source of such information,
Maybe I should stop you there. We aren't using any "information"
from the CA. We are only using the CA to bundle Web sites
into "Organizations". Even then as I note above there's nothing
essential that the CA provides. For all we care the remote entity
could be signing it's own certificates. In fact in some ways that
would be preferable - except for the extortion mechanism that
the default CAs in the Web browsers are successfully getting
away with in terms of selling certificates (namely avoiding the
>are many kinds of information pertinent to conceptualizing an entity
>that a CA doesn't provide, there are many kinds of entities (see my
>big list in a previous post) that a CA doesn't help conceptualize,
>and the CA ultimately may not be the best source of even information
>about organizations. Also keep in mind that I'm talking about petnames
>in general here (as conceived by their inventor Mark Miller), not about
>the Petname Toolbar in particular.
Then maybe we are talking about two different things. I'm talking
about the most concrete instance I've seen, namely the Petname
toolbar that Tyler provided. Of course Mark Miller has chimed in a
few times on this topic, but looking back at his comments I don't
see any that seem to object to the more narrow notion of Petname
use that is suggested by Tyler's implementation.
>Furthermore, the CA is often providing information relevant not only to
>conceptualizing the entity, but also to granting it authorizations -- such
>as whether and where the user can bring legal action against the entity.
>The user who believes such actions can be brought is more likely
>grant authorizations (such as submitting their credit card number)
>whose security ultimately depends on being able to invoke the law.
Now you're getting into an entirely different area. An area where I
think any progress on this list is unlikely.
>Finally, the petname also doubles as a mnemonic for other memories
>or feelings of the user pertinent to decisions to grant authorization
>to the named entity.
I can accept that. They might even be included explicitly as notes
as others (Norm Hardy and Toby Murray) have suggested.
> > Given the recent discussion on this list about Petnames, it would seem
> > to me fairly simple that if I had a source of information that I had some
> > trust in...
>A phishing victim has also has trust, in the e-mail and in the site it
>links him to. Uninformed trust is the problem; minimizing dependence
>on such trust is the solution.
It may be a problem, but I believe it's *not* the problem the Petname
is intended to solve. I believe there's a separate issue that can
be investigated with regard to the ability to transfer any sort of
trust (sorry Ian) relationship safely - though I've suggested means
of doing so in my examples.
>That's one way to do it, but realize that you are relying on
>least three entities here -- the domain name system (for the URL),
1. No. That much I'm not relying on. The domain name/IP address are
just a hint. If it didn't work or if I took me to the wrong place there would
be no threat to the binding.
>Equifax (for conceptualizing the "Flying Robots" as a still existing
>company that is in fact who you are communcating with,
2. No - here you're attributing too much to Equifax. As noted in
a recent email (I'm coming to regret that suggestion to bind the Petname
to the Organization rather than to the key) I'm only relying on
Equifax (or any CA) to properly associate a single organization
name to a single entity - probably a billing entity from their perspective.
Let's factor out that Organization business if we can. Suppose the
Petname was tied to a single public key. We can perhaps discuss
the organization binding separately.
>and later for
>believing that you can safely give it your credit
>card number when you order the flying robot),
3. No, again there is no trust to Equifax there. Why do you
believe there is?
>and your colleague (a
>sample of one regarding the quality of the robots.
4. Finally, yes. I can decide how much I wish to trust my
colleague with regard to the Web entity. Perhaps we
should go back (sigh) to my previous form of example:
Hey Jed, you should pick up one of the flying robots from:
I bought one for $50 and their really great. You'll know you
have the right site if you find their certificates fingerprint to be:
Are we in agreement that if I go to the site, check the fingerprint,
and assign the Petname as being bound to the fingerprint then
I am only placing any 'trust' that I choose to in the site/organization
on my colleague's recommendation?
>your colleague's contribution to the other trust factors, quite likely
>he only believes it is "the right site" because DNS and Equifax told him
Perhaps, though in my example she is telling me her experience.
From my perspective, insofar as I trust my colleague, I'm only
attributing the 'trust' associated with that experience. E.g. as
If I had already bought a $50 robot from them and had a good
experience - except somewhat less depending on how much
I faith I have in my colleague and on our communication.
>If the authorizations you provide don't cost you more (in expected
>cost of risk that any of these three either made a mistake or
>purposefully deceived you, and the damage done to you as a result),
>than the benefits you expect to get, then by all means rely on the
>referral. But under what circumstances will this be the case?
>The phishing victim, too, has a plausible story for why he can trust
>the web site that looks just like his bank with his bank password.
I'm sorry, but you lost me a bit above. I require rather more assurance
before I put money into bank. Even the old physical means (e.g. it
looks like a bank, friends told me about it, it says "FDIC insured",
etc.) are subject to problems, but they've worked pretty well for
Suppose, for this exercise, that I trust those old physical means
to adequately identify a "bank" that I can trust. Then I go physically
into the bank and I deposit some money. The person that I give
the money to gives me a copy of a brochure that I see copies of
posted around their bank. In that brochure it says something like:
If you'd like to access your account over the World Wide Web,
visit our Web banking site at
Before trusting this site and assigning it a Petname,
please verify that it is using the certificate with MD5
All the CA is doing for us in the scenario that I proposed
is to allow us to avoid comparing fingerprints and to
be able to deal with multiple Web sites associated with
a single Web entity.
If we used the above more limited form of Petname, would
you be satisfied that it could safely provide the value of binding
to the remote Web entity?
> > I realize the above depends on
> > limiting the space of certificate authorities (e.g. defaults like
> > Equifax, Verisign, etc.). Is that the most significant area
> > to address?
>Single points of failure are a substantial flaw. See
>"Trusted Third Parties Are Security Holes",
I believe there is no single point of failure. Do you
agree that there is no single point of failure (except of
course the remote entity itself) when using the
> > Is the idea to develop a digital mechanism for
> > communicating property rights?
>For names, attribution rights, and some other kinds of digital
>property rights, ensuring secure global communication of the
>definitions and owners of those rights also enforces those rights...
You seem to be clamoring to get off into these higher level
issues of property rights, means of assigning trust, etc.
Can't we stick to the simple binding of a name to a
Web entity until we at least agree that we can do
that much effectively with a Petname and it adds some value?
If we can settle that much then perhaps we can begin
to discuss/address some higher level issues. I believe
all such higher level issues depend on a safe and reliable
means to communicate repeatedly with a single "entity",
do they not? Forget for now about what assumptions
you might have about any such entity or how you initially
get into contact for the moment. Can we agree
that you need to be able to communicate repeatedly with
any such entity in order to further any sort of trust
More information about the cap-talk