RE: report on EV and SSL MITM proxying

Yup. This is the lesson of the day. And, it's a good one for us.

Simply put: Not everyone agrees that: the site hosting the container of the
document/graph defines the standing of the graph. Some expect the browser to
define standing/security/safety. And, some expect the logic of the semweb to
do it.

I feel for my security colleagues. The unbounded assumptions of web (and the
semantic web furthermore) are hard - when compared with the "easy" word of
IETF security where folks can at least put some security bounds in place.
Folks in IETF/NCSA/EV land seem to have settled on a simplifying assumption
for the web:- that untrustworthy browsers/PCs really need to cooperate with
a trustworthy server agent working in the "public trust", which "acts for"
the user/browser.

I think we saw this earlier in Ryan's argument (on phishing and multiple ssl
sessionids for "mixed content" documents). He seemed to express a (well
meant) bias that browsers "really ought to" only have ssl sessions with one
site, for any one document/graph. That is, the https connection "to a
document's container" should be viewed as a protective tunnel to "a secure
space", containing a document processor for "secure documents". In that
world view, the browser is nothing more than an renderer (not a processor).
On that remote processor, security boundaries are enforced to protect the
browser, remotely. The browser is a fancy X terminal, that is.

Then, we saw hints of those same design assumptions from the Opera folks in
a blog posting or two, being yet more specific about "secure rendering" by a
browser. Rather than using the metaphor of a "tunnel" defining when a
document is "safe"  (because a remote trust agent enforces the relation
between graph elements and ssl sessions, safety is defined in https/certs
terms), in Opera land the document processing element of the browser must
confirm -  that all links in a graph under rendering/inspection (and HTML is
just a graph) must be mapped by EV. EV is a universal quantifier, that is,
over all links in a graph. Presumably, it's not a transitive quantifier,
looking ever deeper into the linked data space to see who n element
downsteam links to whom!

And, just for fun, the EV roots/oids are defined per browser, and per
browser deployment (in Windows/IE case). So, there are already several
universal quantifiers, as each browser vendor imposes its own semantic model
on https/EV.




-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Monday, March 21, 2011 10:05 AM
To: peter williams
Cc: 'Yngve Nysaeter Pettersen'; public-xg-webid@w3.org
Subject: Re: report on EV and SSL MITM proxying


On 21 Mar 2011, at 17:51, peter williams wrote:

> I think it all comes down to this:
> 
> If I have a foaf card in XHTML/RDFa (with my self-asserted pubkey) 
> hosted on an EV-site, and I (10s later) add the wrong party (pointing 
> to the webid of a person whose site has NO EV cert), my own site in 
> Opera now no longer shows the green-address bar when rendering my foaf 
> card in XTHML+RDFa. (10s ago, it did.)

(Just reading the above, hope I did not miss something important)

If your browser displays your RDFa foaf profile served by an EV hosted site,
then the browser should show that page as being an EV issued page, no matter
what resources that page points to.

That is the way current pages work.

If your foaf profile embeds remote things such as pictures served from
somewhere else, then the browser will probably show that the page contains
mixed content. Until a good UI and security mechanism for browsers handling
merged content appears this is where we will remain. I think Social Web
servers or light weight specialised clients will be the first to explore
trust with merged graphs.

Henry

Social Web Architect
http://bblfish.net/

Received on Monday, 21 March 2011 17:42:00 UTC