W3C home > Mailing lists > Public > public-usable-authentication@w3.org > June 2006

Re: Secure Chrome and Secure MetaData

From: James A. Donald <jamesd@echeque.com>
Date: Wed, 21 Jun 2006 09:11:30 +1000
Message-ID: <449880A2.1000306@echeque.com>
To: public-usable-authentication@w3.org

 > If you're on this list and care at all about Secure
 > Chrome and Secure MetaData, and about your colleagues
 > who also care about Secure Chrome and Secure MetaData,
 > you'll refrain from discussing other topics, even if
 > you have the most brilliant insight in the world on
 > them.

I think you are guilty of premature optimization.  One
question surely is: what problem does one want to solve
using Secure Chrome and Secure MetaData?

Being engineers, our natural approach is to break the
problem down into small pieces.  We must, however, not
break this problem down into pieces that cut across the
security perimeter, at least not until a security
perimeter actually exists.

Security is as strong as its weakest link, and is
commonly attacked on the link between applications. PKI
is a fort with a wall on only one side.  Let us not
repeat the error yet again.

The browser's most severe insecurities are that one
receives email that purports to be from a web site where
one has a login relationship, and that email contains
browser links that purport to be from the domain that
originated the email.

Any problem that is declared to be off topic or out of
scope, is usually the problem whereby security comes
under attack.  Thus SPF is dying in large part because
filtering was declared to be out of scope, whereupon
spammers became the earliest and most enthusiastic
adopters of SPF.  Security solutions whereby the account
holder notifying the bank is in scope, but the bank
notifying the account holder is out of scope, are likely
to fail similarly.  Security improvements in email and
the browser have to be integrated and talk to each other
- for example browser login information has to be
available to check email authenticity, or else we have
to develop some new push mechanism without the problems
of email. Verisign's proposed Secure Internet Letterhead
is an attempt to provide an integrated solution, since
to be useful the proposed letterhead must show both on
the browser and on the email client, but this proposal
is likely to fail because it amounts to an outsider who
has little relationship to either party providing trust,
and charging a fee for that trust.

To solve the network effect problem for Secure Internet
Letterhead, which is surely on topic for this list,
Phillip Hallam-Baker, a man with some influence at
Verisign, has suggested some form of integration between
SIL and DK, which, to be useful, would involve the
browser making use of DK information, so that one could
have some kind of display on both web and email that
vouched for the equivalence of the email and the web
site, without Verisign necessarily providing, and
charging for, evidence that both come from a legitimate

          James A. Donald
Received on Tuesday, 20 June 2006 23:13:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC