Re: ACTION-453: Initial draft of sec. cons. EV mixed with DV

I've made a few more tweaks; the text now reads like this:

   8.6 Mixing Augmented Assurance and Validated Certificates

   The Augmented Assurance indicator tells the user that the owner and
   author of the webpage being displayed can be identified using
   information from the associated augmented assurance certificate.
   Identity signals in this specification only directly address displaying
   the identity of the party responsible for the top level resource in a
   web page. User agents may choose to make the identities of other
   resources that can affect or control the pages content, but we do not
   put forward a model for users on how they might use such information in
   their trust decisions.

   The identity of the top level resource vouches for the content of all
   dependant resources. What resources these are is under the control of
   the top-level resource, which will typically identify these resources
   using URIs with domain based authority. Therefore, this specification
   requires that, in order to display any augmented assurance related
   indicators, dependent resources must all be strongly TLS protected
   using validated certificates.

   If a augmented assurance page includes content from other strongly
   TLS-protected resources that are not identified by augmented assurance
   certificates, the authors for these third party parts of the document
   cannot be identified to the same extent as for the main document. Given
   that certain types of content, for example external scripts and styling
   can change the containing document's entire appearance, and framed
   content and plugins can be where the user's main interaction occurs,
   the user's real interaction may be with content under the control of a
   completely different party than the one identified by the main
   document's augmented assurance certificate.

   Using third party content also makes the main document reliant upon the
   security of the third party contributor, and expands the available
   attack surface of the service, thus giving attackers several more lines
   of attack.

I've also taken a close look at the relevant normative language
again.  I've made two changes, and am wondering about a third one.

First the easy one: I've made slight fixes to the terminology, and
have linked to the definitions in this phrase:

   A Web User Agent that can display an AA indicator MUST NOT display this
   indicator unless all elements of the page are loaded from servers
   presenting a [282]validated certificate, over [283]strongly
   TLS-protected interactions.

Second, it strikes me that - the way this is phrased - we do not
permit pinned certificates for dependent resources.  The language
about the identity signal does so far permit these; I've changed it
for consistency with the discussion we had in Oslo:

   During interactions with a [334]TLS-secured Web page for which the
   top-level resource has been retrieved through a [335]strongly
   TLS-protected interaction that involves an [336]augmented assurance
   certificate, and for which all dependent resources have been retrieved
   through interactions that involve [337]validated certificates, the
   following applies:

   ...

If the top level certificate is validated, and dependent resources
use pinned certificates, then we currently do not consider that case
mixed content.  I'd like a brief cross-check on the next call that
that's really what we mean.

Thanks,
-- 
Thomas Roessler, W3C  <tlr@w3.org>






On 2008-06-06 13:26:04 -0400, Mary Ellen Zurko wrote:
> From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
> To: "Johnathan Nightingale <johnath" <johnath@mozilla.com>
> Cc: "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
> Date: Fri, 6 Jun 2008 13:26:04 -0400
> Subject: Re: ACTION-453: Initial draft of sec. cons. EV mixed with DV
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> Authentication-Results: mx.google.com; spf=pass (google.com: domain of public-wsc-wg-request@listhub.w3.org
> 	designates 128.30.52.56 as permitted sender) smtp.mail=public-wsc-wg-request@listhub.w3.org
> Archived-At: <http://www.w3.org/mid/OF5D158BCD.8752CC13-ON85257460.005E8ED4-85257460.005FC53E@LocalDomain>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
> Here's a stab that might be more suitable for wsc-xit, based on Yngve's 
> text, and the discussion in Oslo: 
> 
> 
> The EV indicator tells the user that the owner and author of the webpage 
> being displayed can be identified using information from the associated EV 
> certificate. Identity signals in this specification only directly address 
> displaying the identity of the party responsible for the top level 
> resource in a web page. User agents may choose to make the identities of 
> other resources that can affect or control the pages content, but we do 
> not put forward a model for users on how they might use such information 
> in their trust decisions. The identity of the top level resource vouches 
> for the content of all dependant resources, which is why they must all be 
> strongly TLS protected for the web page to display an AA  indicator. 
> 
> If a EV page includes content from other strongly TLS-protected resources 
> that are not identified by EV certificates, the authors for these third 
> party parts of the document cannot be identified to the same extent as for 
> the main document. Given that certain types of content, for example 
> external scripts and styling can change the containing document's entire 
> appearance, and framed content and plugins can be where the user's main 
> interaction occurs, the user's real interaction may be with content 
> created by a completely different author than the one identified by the 
> main document's EV certificate.
> 
> Using third party content also makes the main document reliant upon the 
> security of the third party contributor, and expands the available attack 
> surface of the service, thus giving attackers several more lines of 
> attack.
> 
> 
> 
> 
> 
> 
> From:
> Johnathan Nightingale <johnath@mozilla.com>
> To:
> yngve@opera.com
> Cc:
> "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
> Date:
> 06/02/2008 09:38 AM
> Subject:
> Re: ACTION-453: Initial draft of sec. cons. EV mixed with DV
> Sent by:
> public-wsc-wg-request@w3.org
> 
> 
> 
> 
> I think this is reasonable text, but I wonder if it wouldn't be better 
> in the "Advice to Site Authors" document, since site authors are the 
> ones best placed to make decisions about which third parties they 
> trust?  There it could also be a full on recommendation, even with 
> SHOULD language, instead of just a security consideration in a 
> document about browser authors.
> 
> Cheers,
> 
> Johnathan
> 
> On 31-May-08, at 3:29 PM, Yngve Nysaeter Pettersen wrote:
> 
> >
> > First take (EV used instead of AA):
> >
> > ---------------------
> >
> > The EV indicator tells the user that the owner and author of the 
> > webpage being displayed can be identified using information from the 
> > associated EV certificate.
> >
> > If a EV page includes content from other strongly TLS-protected 
> > resources that are not identified by EV certificates, the authors 
> > for these third party parts of the document cannot be identified to 
> > the same extent as for the main document.
> >
> > Given that certain types of content, for example external scripts 
> > and styling can change the containing document's entire appearance, 
> > and framed content and plugins can be where the user's main 
> > interaction occurs, the user's real interaction may be with content 
> > created by a completely different author than the one identified by 
> > the main document's EV certificate.
> >
> > Such change in content origination will not be readily apparent to 
> > the user, and main document authors should be cautious when using 
> > third party content, and to the best of their ability verify the 
> > identity of these contributors.
> >
> > Using third party content also makes the main document reliant upon 
> > the security of the third party contributor, and expands the 
> > available attack surface of the service, thus giving attackers 
> > several more lines of attack.
> >
> > ---------------------
> >
> > -- 
> > Sincerely,
> > Yngve N. Pettersen
> > ********************************************************************
> > Senior Developer                                                Email: 
> yngve@opera.com
> > Opera Software ASA                   http://www.opera.com/
> > Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
> > ********************************************************************
> >
> 
> ---
> Johnathan Nightingale
> Human Shield
> johnath@mozilla.com
> 
> 
> 
> 
> 
> 
>

Received on Sunday, 15 June 2008 12:28:20 UTC