Hi Dan,
This seems like a hybrid between a use case and a proposed recommendation.
The use case would be:
Alice has repeatedly visited her bank's web site. Everytime she visits our
bank's website she wants to be reassured that she is actually at the
bank's website and not a spoofed website. And she wants that reassurance
to be accurate every time; neither telling her it's not her bank, nor
telling her a web site that does not belong to her bank is her bank. She
is particularly worried about attacks that have occured and are on the
news and her friends talk about (though she doesn't always understand what
they are).
The rest of your mail would be the core of a proposed recommendation.
If you agree, you could write up both the use case (for the Note) and
draft a proposed recommendation (since we'll start discussing our
recommendations in less than two weeks).
Mez
"Dan Schutzer" <dan.schutzer@fstc.org>
Sent by: public-wsc-wg-request@w3.org
01/10/2007 05:57 AM
To
"'Thomas Roessler'" <tlr@w3.org>, "'WSC WG'" <public-wsc-wg@w3.org>
cc
"'Dan Schutzer'" <dan.schutzer@fstc.org>
Subject
RE: use case: CA acceptance (ACTION-74)
This issue I have with lots of these case studies is it describes these
things in terms that a typical user may not understand. It might be better
to describe this same one differently:
Alice has repeatedly visited her bank's web site. Everytime she visits our
bank's website she wants to be reassured that she is actually at the
bank's website and not a spoofed website. The bank's website can provide
information to the browser that indicates it is the bank's website and not
a spoof - this could include a combination of things: Certificated issued
by a CA that is consistent with past, IP addresses that are registered
with that URL, other things? If the browser checks for this combination of
confirming information, we need a solution that can:
1. Communicate to Alice that the site is valid and/or communicate to Alice
when the site is not valid and/or prevent invalid websites from coming up.
2. Have close to zero error in this communication (very little to no
instances where the browser is communicating false rejects or false
accepts) to prevent chicken little effect where user gets blocked or
warned against going to a real bank site, or where user gets assured it is
the real bank site when it is not.
3. Have this scheme still work against credible spoofing attacks (e.g.
man-in-the-middle, false links embedded in phishing emails)
Without a scheme that
a. easily communicates to the user that they are at the same site they
always go to - the legitimate banks site
b. does not make enough mistakes to make this communications suspect and
untrustworthy
the users needs will not be reflected. And this needs to be done behind
the scenes unrelated to the users knowledge of CA's and certificates.
Dan Schutzer
-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Thomas Roessler
Sent: Tuesday, January 09, 2007 7:44 PM
To: WSC WG
Subject: use case: CA acceptance (ACTION-74)
Another interaction.
Alice visits a bank's web site. The certificate of that site is
issued by a CA that is not part of the set of root certificates that
Alice's browser trusts. Alice is asked whether she wants to accept
this certificate.
Motivates: Practices for metainformation about CA certificates.
Cheers,
--
Thomas Roessler, W3C <tlr@w3.org>