Re: Text change for wsc-ui Petnames

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.  That's wrong for the presumable purpose of
petnames, it's also *not* what controls the same-origin policy.

(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.)

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?

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/1A961C2CE8A6F041856127ED3EA677261E644A5569@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:14:25 UTC