W3C home > Mailing lists > Public > public-xg-webid@w3.org > March 2011

RE: report on EV and SSL MITM proxying

From: peter williams <home_pw@msn.com>
Date: Mon, 21 Mar 2011 08:47:41 -0700
Message-ID: <SNT143-ds10308EA4EB4F516CF2081492B50@phx.gbl>
To: <public-xg-webid@w3.org>
Concerning UI, a new element has been introduced. It concerns the timeliness
of revocation, and the impact of _availability_ of revocation information on
browser https UI. This is distinct from the impact of the information,

If I am online, I may see a green address bar behind the address of an EV
site. If I disconnect my home wifi router from its supporting broadband
modem and then refresh the browser page on the home PC, the same site will
now appear not green (since revocation info is now "not available" for the
non-root cert).

Assume the AIA field in the user cert uses OCSP, and no CRL caches exist. 

If there are multiple browser instances open on the PC, some with pages
refreshed some not, presumably some address bars for the one site are green,
some are not. Or, do browser instances in a PC sync their security state,
and show a consistent set of green/not-green address bars?

If we applied EV UI design notions to client certs in webid, if a foaf card
were to have a pubkey registered at time t, but the same card omits the same
entry for a still live SSL session at time t+1, would we expect the browser
UI for webid to work as in the EV world:- go from green to not-green (on F5
refresh) due to this change in status?

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Yngve Nysaeter Pettersen
Sent: Tuesday, March 08, 2011 9:58 AM
To: public-xg-webid@w3.org
Subject: Re: report on EV and SSL MITM proxying

Opera also have several hardcoded checks before the EV classification is
allowed to stick; one of them is that revocation information must be
available for all non-Root certificates in the chain.
Received on Monday, 21 March 2011 15:48:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:23 UTC