RE: Text change for wsc-ui Petnames

Hi Thomas,

Responses inline below...

Thomas Roessler [mailto:tlr@w3.org] wrote:
> Tyler,
>
> I fear there's some confusion going on here. The "effective
> TLD" is limiting the level up to which labels can be dropped
> from an origin, to take into account effects like co.uk.  So,
> the "effective TLD" of www.bbc.co.uk is co.uk.

Based on my reading of the Mozilla documentation, I think the concept you're discussing is called "public suffix".

That same documentation also uses the term "base domain" for the concept I am thinking of. I thought the documentation also used "effective TLD" as a synonym for "base domain". We can use the term "base domain" if that is more accurate. The base domain concept is what I meant and what I have implemented.

> That's wrong
> for the presumable purpose of petnames, it's also *not* what
> controls the same-origin policy.

"base domain" does affect same-origin policy enforcement of cross-frame scripting.

> (The navigation policy depends on (a) the origin, and (b)
> client/child relationships between different windows.  It's
> different from the policy that governs other object access.
> The only point where the "effective TLD" might come in here
> is in limiting what suffixes of its current value
> document.domain might be set to.)

Which in turn determines what frames you can script. For example, pages and one.example.org and two.example.org can shorten their document.domain to example.org and so script each other.

> I suspect that you mean the "base domain" (in the lingo of
> the Firefox documentation).  Either way, I'm concerned that
> we'd lose any benefits that the petnames proposal would
> currently offer in the self-signed case -- effectively, by
> depending on domain names in certificates, the usefulness of
> the petname proposal would be limited to domain-validated
> certificates, no?

No. In fact, the current text for petnames explicitly says that the information from the certificate MUST NOT be used for pinned self-signed certificates. These always used the hostname from the page's URL. That's unchanged in the new proposal. Obviously we can't trust information taken from a self-signed certificate. We can only trust the binding between a hostname and a certificate that the user specified when pinning the certificate. It's the bound hostname that we key off of, not anything contained in the certificate.

--Tyler

>
> http://developer.mozilla.org/En/NsIEffectiveTLDService
>
> Regards,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
> On 2008-09-17 17:01:26 +0000, Close, Tyler J. wrote:
> > From: "Close, Tyler J." <tyler.close@hp.com>
> > To: "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
> > Date: Wed, 17 Sep 2008 17:01:26 +0000
> > Subject: Text change for wsc-ui Petnames
> > 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
> > Accept-Language: en-US
> > acceptlanguage: en-US
> > Archived-At:
> >
> <http://www.w3.org/mid/1A961C2CE8A6F041856127ED3EA677261E644A5
> 569@GVW0538EXC.americas.hpqcor
> >       p.net>
> > X-Bogosity: Ham, tests=bogofilter, spamicity=0.197242, version=1.1.6
> >
> >
> > I am proposing some new text for petnames, based on
> implementation experience. The described user interface
> remains unchanged; only the matching algorithm for binding a
> petname to a site needs updating.
> >
> > These changes affect section 5.16 of wsc-ui:
> >
> > "Web Security Context: User Interface Guidelines - 5.1.6 Petnames"
> > <http://www.w3.org/TR/wsc-ui/#sec-petnames>
> >
> > Neither Firefox nor IE (the major browsers that support
> extentions) provides full access to the server's SSL
> certificate. In particular, important fields such as
> subjectAltNames are inaccessible. The petname user interface
> would be easier to deploy if it could be implemented without
> direct reference to information from the server's SSL
> certificate. Both Firefox and IE provide an indication of
> whether or not a page is TLS-secured and what the
> corresponding hostname is. I think this information is
> sufficient to implement a petname user interface, if we make
> use of the "effective TLD" notion that already governs
> cross-frame scripting in the browser.
> >
> > "nsIEffectiveTLDService - MDC"
> > <http://developer.mozilla.org/En/NsIEffectiveTLDService>
> >
> > "document.domain - MDC"
> > <http://developer.mozilla.org/En/DOM/Document.domain>
> >
> > The effective TLD is also what is shown in the identity
> signal popup in Firefox 3.
> >
> > "RE: Firefox 3 identity signal from Close, Tyler J. on
> 2008-09-17 (public-wsc-wg@w3.org from September 2008)"
> >
> <http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0040.html>
> >
> > Basically, I propose that the petname binding be one of petname to
> > effective TLD for TLS-secured pages. I've implemented this
> algorithm
> > in an add-on for Firefox.
> >
> > "Petname Tool :: Firefox Add-ons"
> > <https://addons.mozilla.org/en-US/firefox/addon/957>
> >
> > I suggest the following new recommendation text:
> >
> > """ For TLS-secured pages, the user agent MAY allow the
> user to assign
> > the authenticated entity a [Definition: petname]. This
> assignment MUST
> > create a binding between the petname and the effective TLD
> of the site
> > hosting the page.
> >
> > To discover the petname that corresponds to the entity that is
> > authenticated through a validated certificate, user agents MUST use
> > the entity's effective TLD. """
> >
> > The above paragraphs replace the first two paragraphs in the text,
> > which currently read:
> >
> > """ For TLS-secured pages, the user agent MAY allow the
> user to assign
> > the authenticated entity a [Definition: petname]. If the
> web page uses
> > a validated certificate, this assignment MUST create a binding from
> > the petname to each of the host identifiers the certificate
> is valid
> > for. These identifiers are found in the CN attribute and the
> > subjectAltNames attribute, as specified in [RFC2818]. If
> the Web page
> > uses a pinned self-signed certificate or certificate chain, this
> > assignment MUST create a binding from the petname to the pinned
> > destination only. It MUST NOT create a binding from the
> petname to any
> > other destination.
> >
> > To discover the petname that corresponds to the entity that is
> > authenticated through a validated certificate, user agents MUST use
> > identifiers from the certificate only. In particular, when the
> > certificate includes domain name wildcards, then the same
> petname will
> > be associated to all sites that present a validated
> certificate which
> > includes the same wildcard. """
> >
> > The other text in the section is unaffected by this change.
> >
> > Definition of "effective TLD" is left as an exercise for
> the editor.
> > ;) We no doubt will also need reference to this concept in
> resolving
> > the outstanding finer-grained origin issues with the current wsc-ui
> > text, since effective TLD governs what frames may script what other
> > frames.
> >
> > "Surfacing the browser's cross-frame-scripting policy in
> the chrome from Close, Tyler J. on 2008-09-02
> (public-wsc-wg@w3.org from September 2008)"
> >
> <http://lists.w3.org/Archives/Public/public-wsc-wg/2008Sep/0001.html>
> >
> > --Tyler
> >
> >
> >
>
>

Received on Wednesday, 17 September 2008 17:30:42 UTC