RE: use case: CA acceptance (ACTION-74)

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>