On 10/16/2003 07:19 PM, David Honig wrote:
> it would make sense for the original vendor website (eg Palm)
> to have signed the "MITM" site's cert (palmorder.modusmedia.com),
> not for Verisign to do so.  Even better, for Mastercard to have signed
> both Palm and palmorder.modusmedia.com as well.  And Mastercard to
> have printed its key's signature in my monthly paper bill.

Bravo. Those are golden words.

Let me add my few coppers:

1) This makes contact with a previous thread wherein
the point was made that people often unwisely talk
about identities when they should be talking about
credentials aka capabilities.

I really don't care about the identity of the
order-taking agent (e.g. palmorder.modusmedia.com).
What I want to do is establish the *credentials*
of this *session*.  I want a session with the
certified capability to bind palm.com to a
contract, and the certified capability to handle
my credit-card details properly.

2) We see that threat models (as mentioned
in the Subject: line of this thread), while
an absolutely vital part of the story, are
not the whole story.  One always needs a
push-pull approach, documenting the good
things that are supposed to happen *and* the
bad things that are supposed to not happen
(i.e. threats).

3) To the extent that SSL focuses on IDs rather
than capabilities, IMHO the underlying model has
room for improvement.

4a) This raises some user-interface issues.  The
typical user is not a world-class cryptographer
and may not have a clear idea just what ensemble
of credentials a given session ought to have.
This is not a criticism of credentials;  the user
doesn't know what ID the session ought to have
under the current system, as illustrated by the
Palm example.  The point is that if we want
something better than what we have now, we have
a lot of work to do.

4b) As a half-baked thought:  One informal intuitive
notion that users have is that if a session displays
the MasterCard *logo* it must be authorized by
MasterCard.  This notion is enforceable by law
in the long run.  Can we make it enforceable
cryptographically in real time?  Perhaps the CAs
should pay attention not so much to signing domain
names (with some supposed responsibility to refrain
from signing abusively misspelled names e.g.
pa1m.com) but rather more to signing logos (with
some responsibility to not sign bogus ones).
Then the browser (or other user interface) should
to verify -- automatically -- that a session that
wishes to display certain logos can prove that
it is authorized to do so.  If the logos check
out, they should be displayed in some distinctive
way so that a cheap facsimile of a logo won't be
mistaken for a cryptologically verified logo.

Even if you don't like my half-baked proposal (4b)
I hope we can all agree that the current ID-based
system has room for improvement.


Tangentially-related point about credentials:

In a previous thread the point was made that
anonymous or pseudonymous credentials can only
say positive things.  That is, I cannot discredit
you by giving you a discredential.  You'll just
throw it away.  If I somehow discredit your
pseudonym, you'll just choose another and start

This problem can be alleviated to some extent
if you can post a fiduciary bond.  Then if you
do something bad, I can demand compensation from
the agency that issued your bond.  If this
happens a lot, they may revoke your bond.  That
is, you can be discredited by losing a credential.

This means I can do business with you without
knowing your name or how to find you.  I just
need to trust the agency that issued your bond.
The agency presumably needs to know a lot about
you, but I don't.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to