Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The Web Security Context Working Group is publishing this document to provide a basis for initial review of and commentary on its work. The Working Group had taken an inclusive approach toward publishing various technical proposals in its First Public Working Draft. The Working Group has since decided to adopt a two-phase approach, and expects to take an initial set of proposals to Last Call in or around June 2008. Material that the Working Group does not expect to include with that Last Call has been moved into appendices. No claims as to the efficacy of usability-related material are made.
To facilitate access to relevant background, various sections of this document are annotated with references to input documents that are available from the Working Group's Wiki, and to pertinent issues that the group is tracking. The documents in the wiki include background, motivation, and usability concerns on the proposals that reference them. They provide important context for understanding the potential utility of the proposals.
This document was developed by the Web Security Context Working Group. The Working Group expects to advance this Working Draft to Recommendation Status.
Please send comments about this document to public-usable-authentication@w3.org (with public archive). For comments to be most useful, please follow these guidelines for writing useful issues.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Safe Web Form
Editor
1.1 Associating a history with a web
site
1.2 No
support for non-TLS data exchange
1.3 Creating a
new relationship
1.4 Reliable Text
1.5 Selection
of a text string
1.6 On
screen masking of a text string
1.7 Editing
the stored history
1.8 Picture-in-picture
defense
1.9 Detecting a
possible Man-In-The-Middle attack
2 Usage Modes
2.1 Framework
2.2 Safe Browsing
Mode
3 Security Confidence
Estimate
This section will be refined further in a future version of this specification. It is not part of this specification's normative material at this point.
This section is normative.
This section specifies a user-driven interaction for entry of information deemed security critical by the user. This interaction integrates consumption of relevant security information by the user while facilitating the data entry task and providing a record of the user's trust decisions.
The safe form editor keeps a history of text strings the user has given to a Web site via a special purpose text entry tool.
This section specifies the algorithm the user agent MUST use to determine if a visited web site should be considered the same as one in the history database. This algorithm is based solely on a comparison of information provided by X.509 certificate chains. Let the currently visited web site be SiteA, a candidate match in the stored editor bar history be SiteB. For each certificate chain received from SiteB, attempt a match against the one received from SiteA using the following checks:
The user agent MUST retain sufficient information about all the certificate chains used by a web site to find a match in all cases where the above algorithm indicates there is a match.
The first check in the matching algorithm, which compares public keys, provides a means to transparently update the certificate authority used by a web site. To change certificate authorities, a site acquires a certificate for its existing public key from the new certificate authority. The site should continue using its existing public key until its user base has received the new certificate chain through visits to the site.
Both the first check in the matching algorithm and the second to last, which compares the "CN" attributes of the certificates' subject fields, provide a means to transparently update an organization's name and address. To change this certificate information, an organization acquires a certificate chain that specifies the updated information, but matches against one of these earlier checks.
It is common for an organization to use multiple, unrelated domain names. The final check in the matching algorithm enables sharing of history across all the hostnames used by an organization.
The editor bar supports safe entry of text strings by the user into a web site with which a continuous relationship has been established. The user can expect this continuity to be securely enforced and the transmissions protected from eavesdropping and tampering. Currently, these properties can only be supported on the web through the use of TLS. The editor bar MUST NOT be enabled for exchanges that are not protected by TLS. If the user hits the editor bar attention key when visiting a site not protected by TLS, the user agent MUST present a message warning the user that data entered in the current form may be seen, or tampered with, by attackers. The user agent MUST offer an interaction to attempt navigating to a secure version of the current page. Exercising that interaction MUST navigate the browser to a URL constructed by changing the current page's URL scheme to a corresponding one that uses TLS. For example, an http: URL is converted to an https: URL.
When visiting a web site, the user summons the editor bar via an attention key, or a toolbar button, or in some other way. In response to this request, the editor bar searches its history database for an entry corresponding to the current web site, using the algorithm specified in 1.1 Associating a history with a web site. If no match is found, the text entry tool MUST NOT be enabled. Instead, the user agent MUST present a message that indicates that the user has not transmitted sensitive data to this site before. Along with this message, the user agent MUST offer distinct interactions through which (a) the user can review sites that they have transmitted sensitive data to before, and (b) the user can proceed to establish a relationship with the site they are visiting.
You have not established a relationship with this web site through the editor bar.
If the user choses interaction (a), a list of hyperlinks to web sites in the editor bar's history database MUST be provided.
If the user choses interaction (b), the user agent must provide a message which communicates identity information based on the TLS certificate used consistent with . The user agent MUST offer distinct interactions through which (aa) the user can navigate to a known preferred search engine, and (bb) the user can enter a "petname" for the site they are interacting with.
ExampleCA Inc. claims this web site belongs to "Example Bank Inc. of Sunnydale, California, USA."
If the user choses interaction (aa), the user agent MUST navigate to the user's preferred search engine.
If the user selects the second option, the user agent MUST search the database of existing relationships to find any name similar to the newly chosen one. If any matches are found, the user is notified of the collisions and given the opportunity to instead navigate to the corresponding web site. If no matches are found, the user agent updates its database of stored relationships and enables the text entry tool.
For user agents with a visual user interface, all user interfaces exposed for these interactions SHOULD visually replace the Web content currently displayed to the user.
To defend against web site impersonation, the editor bar is designed to only display text strings provided by the user, or statically provided by the user agent software. Implementations MUST NOT display a text string, or graphic, from any other source within the editor bar user interface. The quoted text in the bootstrap message, the part of the message after "belongs to", MUST be distinguished from the rest of the static text. If the described certificate chain was not issued by one of the user-agent's installed and trusted certificate authorities, the message MUST NOT quote any information from the certificate, instead presenting a message meaning: "This web site's credentials are unrecognized". The same two user actions are still offered by the rest of the message.
The name chosen by the user at the end of the bootstrap interaction, called a [Definition: petname], MUST be the only identifier used by the editor bar user interface to refer to the named site. Each hyperlink in the list provided when the user selects the first option in the first message of the bootstrap interaction MUST use the petname as the hypertext. This list MUST also be accessible to the user via a "Contacts" option. The petname for the current web site MUST also be presented alongside the text entry tool. The user agent MUST provide a means for the user to update the petname used for a web site.
The text entry tool supports user entry of a new text string, or auto-completion of a previously entered text string. The editor MUST provide an indication of which of the two actions is being taken. The text field MUST NOT provide auto-completion of stored editor bar text strings that have not been previously submitted to the currently displayed web site.
The text entry tool history menu supports user selection of a previously entered text string. The menu MUST indicate whether or not an offered selection has been previously submitted to the currently displayed web site. Further, the user action to select a text string previously submitted to the current site MUST be different from that to select a text string previously submitted to some other site. For example, text strings previously submitted to the current site could be displayed in a main menu and other text strings displayed in a sub menu. Consequently, the user would have to click more than once to select a string not previously submitted to the current site, but only once for a string that has been previously submitted.
Both of these selection mechanisms purposely require explicit action by the user. Transmission of a text string in a particular request represents user consent for use of that text string for the purpose of that request. The user agent MUST NOT subvert this consent by auto-filling form fields with information taken from the editor bar history. Information MUST NOT be transferred from the history database to the web page, except as a result of an explicit approval action by the user.
The editor bar specified in this chapter MUST be the only form filling feature of the user agent. A competing form filling feature would undermine the security features of the interaction created by the editor bar.
Some text strings, such as some passwords, are of such high value that displaying them within the user agent, where they may be seen by an onlooker, is too great a risk. This sub-section specifies a mechanism for marking a text string as one which should not be displayed by the user agent.
The text entry tool history menu MUST provide a means for the user to mark a text string as one which is not to be displayed on screen. Invoking this command prompts the user for a "display name". Wherever a text string would be displayed by the editor bar, the provided display name MUST be shown in its place, as well as an indication that the displayed text is a display name, rather than an actual text string. The auto-completion feature of the text entry tool MUST match keystrokes against the display name, instead of the named text string. Whatever way a display name is selected, the named text string MUST be form filled, not the display name text.
Each change to the editor bar history MUST be explicitly made by the user. In particular, a visited web site MUST NOT be able to add, delete, modify or read the editor bar history. A visited web site MUST NOT be able to receive keystrokes sent to the editor bar by the user.
Some identifiers change over time. For example, a credit card number may change when the card is re-issued. The editor bar SHOULD provide a means to delete a text string. Using this feature, the user can reduce interface clutter created by a text string that is no longer in use.
Under some circumstances, a relationship between the editor bar and a site may need to be terminated. The editor bar MUST provide a means for a user to mark a site as one which will no longer be recognized. When this command is invoked, the editor bar MUST behave as if the relationship never existed, for all scenarios specified by this specification.
Many graphical user agents are vulnerable to picture-in-picture attacks: Graphic and script elements within an HTML page are used to simulate the look and feel of browser chrome. The attacker's goal is to recreate a convincing mockup of the browser chrome entirely within the content page, in order to provide (false) indicators of security to the user.
In these user agents, the editor bar MUST be displayed using a theme customized to the user. The user selects this theme at browser installation time. Changes of this theme MUST involve a user interaction that is focused on this specific task. The icon for the Contacts button MUST also be selected by the user at installation time.
If the user navigates to a web site by selecting a hyperlink provided by the Contacts button in the editor bar and the site presents a certificate chain that can not be matched to one of its previously stored certificate chains according to the algorithm in 1.1 Associating a history with a web site, the user agent MUST alert the user that credentials were provided which cannot be securely matched to those that had been seen in the past.
User agents SHOULD provide the option to send a notification to an alert service of the user agent's choosing.
This section is normative.
Web user agents that implement optional features of this specification MUST support the configuration of different [Definition: usage modes ] which determine which of thse optional features are active. A usage mode MAY cover other configuration settings of a Web user agent. A user agent SHOULD allow users to view details of why a request to perform a Web transaction was denied if this decision was based on the currently-active usage mode.
Web user agents SHOULD support a [Definition: Safe Browsing Mode ] as one usage mode. Users SHOULD NOT be able to change the settings of this usage mode. This usage mode MUST be made available through an interaction based on a Secure Attention Sequence.
In this usage mode, interactions MUST be limited to a usage-mode specific set of sites.
Web user agents MUST require all Web transactions in this usage mode to be strongly TLS protected. Use of self-signed certificates MUST be considered cause for a change of security level.
The optional technique MUST NOT be used.
For Web user agents with a visual user interface, Safe Browsing Mode SHOULD be visually distinguishable from other usage modes.
The user agent SHOULD provide a means of reducing the collection of security context information which is available for any loaded page to a numeric value (termed a "security confidence estimate").
The calculation algorithm for the "security confidence estimate" MAY be made selectable by the end user or offered by separately installed user agent plug-ins.
The user agent SHOULD provide a visual indicator in primary chrome which varies relative to the "security confidence estimate" value. Examples of such visual indicators (non-normative) are gauges, thermometers, a selection of several textual descriptions, and color-gradations.
The visual indicator SHOULD be especially conspicuous in display when the "security confidence estimate" value is different than the value which was observed for the loaded page in previous visits to the loaded page.
The user agent MAY elect to display a visual indicator in primary chrome only when a change in "security confidence estimate" values is observed.
The user agent MUST make the details of all available security context information available to the end user, in either primary or secondary chrome.
If a "security confidence estimate" is provided, the provider of the implementation MUST make the calculation algorithm by which the "security confidence estimate" value is calculated available to the end user. Documentation for the user agent or plug-in which is employed is the likeliest place.
The visual realization of the "security confidence estimate" value will depend on the user agent and end user abilities.