Text change for wsc-ui Petnames

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:02:48 UTC