RE: report on EV and SSL MITM proxying

I've been playing some more, with "secure documents" / "secure graphs".
Obviously, the focus is on that weird hybrid called the XHTML/RDFa document
of a foaf card, rendered by normal, browser DOM engines (vs RDF plugins).
The impact that the embedded RDF has on the HTML DOC to be rendered is
variable in this world, being a function of browser and javascript. The
point is: that this has impact on the EV state, since it's some function of
the " graph's" references

Let's remember, https (vs SSL) ** in a browser** setting was always
cognizant of the fact that a DOM processor in a browser is responsible for
rendering content obtained from n acts of de-referencing content from the
anchored hrefs/links - where such acts occur automatically DUE TO rendering
the containing document. Thus, n SSL sessions and m SSL connections might
come into being for that "document" - depending on the graph content and
which hrefs/links are de-referenced. 

Some acts of de-referencing are automatic (e.g. image tags, js tags, css
script pulls), and some acts for a given graph/page may be as a result of
javascript callbacks during the DOM onload() event hander. (The onload()
code might act on the pre-rendered graph, recall, opting perhaps to follow
some its references not normally "auto"-followed and then adding content to
the DOM as innerText - using dynamic re-rendering, a la DHTML. 

Now, in the Opera case, we know that there is an advanced notion of a secure
graph/document  - that goes beyond basic EV semantics - where basic means
EV-state is restricted to pairwise channels and their certs, cert issuer
"quality" of user identification, and certain cipher strengths. Opera in
advanced model apparently looks at the "de-referencing state" for a given
document/DOM's links/hrefs, and updates browser state in the
"green/not-green" address bar by then analyzing the set of server certs
bound to each of the SSL SessionIDs  bound to the DOM.

Now, its vague which SSL Sessions for the links on a page/graph contribute
to the 'cumulative EV state". But from the Opera blog pages, "some of" them
have ALL to be SSL sessionids to EV sites. In that defined set (however its
defined), any one not EV makes the brower indicate "not EV assured
(not-green)". If they are all EV, the browser then show the defined UI
(green backgrounds , and various padlock semantics). This communicates to
the user that the "graph" (not the site delivering the outer doc) is
EV-grade. 

All could b defined as the set of: all those anchor tags with hrefs
"normally" auto-dereferenced in HTML processing - which is rather vague 

All could be defined alternatively as: all those anchors and link which the
document/graph has bound an SSL sessionid, whether that sessionid got bound
due to HTML processing or javascript, or plugin interceptors, or whatever...

For example, if the HTML/javascript in an onload() handler interprets the
foaf graph in the pre-rendered RDFa stream and choose to add to the DOM foaf
content obtained by following certain refs in the outer graph whose uris
matches "path pattern X", then the set of active references (defining EV
state) could be different to when the very same RDFa stream is subject to a
javascript function applying match path-pattern "Y", during pre-rendering





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


Im not too worried about a profile pointing to offsite pictures, creating
multiple sessionids and multiple presentations client certs/sigs. (That was
Ryan's axis of argument, and his worry about our mission). That is a
traditional https issue known from the outset; about "mixed content." The
webby world has learned to address it, somehow. It's mixed up in the whole
open web => phishing issue set, which stumbles along somehow.

I'm more concerned with the core "foaf-ness" of webid, when RDFa is
specifically involved. The whole point of RDFa is that it works with the
"web we know today". In my [RDFa] foaf graph, I want now  to refer to the
openid/webid of my friends. Surely, this is what we intended, all along! I
want to define my own foaf group (which means referring to their foaf cards,
using webid-grade URIs)

So, the brightline test can be applied. What necessary condition can I
change so that the theorem flips from valid to invalid, with a change of
just one fact? (i.e. induce the contradiction...Engima bombe like.. and halt
that Turing machine...)

>From the description in the blog post, it appears to happens the moment 
>I
add Henry's openid/webid to my foaf card - as represented in XHTML/RDfa.
Before I add the "EV-untrusted Henry", Opera apparently presents my own foaf
card (currently with no external refs) to the world as "EV-trustworthy". The
moment I associate with Henry, EV/Opera  tells the world I am ( i.e. my site
is) now untrustworthy - by withdrawing EV UI signals at the billion PCs
using opera. Remove the Henry card reference, I'm EV-trusted, again.
 
As we intended foaf card to be hosted on SSL sites (and optionally EV
sites), we seem to have learned something I certainly didn't know, before
today.

Can someone with EV site cooperate with me, so I can test things
empirically?  The blog posts I'm basing my reasoning are years old, and
perhaps life's changed meantime.

-----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 Tuesday, 22 March 2011 00:12:20 UTC