Web Security Context: Experience, Indicators, and Trust

3.2.1 Conformance Labels for Web Content

3.2.2 Conformance Labels for Web User Agents

4.2.1 Common User Interface elements

This section defines terms for user interface elements commonly present in Web User Agents. These definitions are normative.

[Definition: Primary User Interface denotes the portions of a Web user agent's user interface that are are available to users without being solicited by a user interaction.]

Examples of primary user interface include the location bar in common desktop Web user agents, the "padlock" icon present in common desktop Web user agents, or error pages that take the place of a Web page that could not be retrieved.

[Definition: Secondary User Interface denotes the portions of a Web user agent's user interface that are available to the user after they are solicited by a specific user interaction.]

Examples of secondary user interface include the "Page Information" dialogue commonly found in desktop Web user agents, and the "Security Properties" dialogue that can obtained by clicking the padlock icon in common desktop Web user agents.

[Definition: Location Bar is a widget in a Web user agent's user interface which displays (and often allows input of) the textual location (entered as a URL) of the resource being requested (or displayed - after the response is received).]

5.1.1 Interactively accepting trust anchors or certificates

A trust anchor represents an authoritative entity represented via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. Relying parties use trust anchors to determine if digitally signed information objects are valid by verifying digital signatures using the trust anchor's public key and by enforcing the constraints expressed in the associated data.

Trust anchor installation is typically handled by Web user agent vendors and systems administrators, based on out-of-band information. Note that trust anchor update is therefore often handled as part of Web user agent or operating system software update.

However, current Web user agents sometimes support the interactive acceptance of a trust anchor during a session, based on user interaction. Most users cannot sensibly decide how to handle such interactions.

Similarly, end-entity (e.g. web server) certiicates that cannot be currently verified using the Basic Path Validation algorithm may trigger current Web user agents to offer the user a choice to accept the certifiate in any case, sometimes for a single session, sometimes for all future sessions involving that certificate.

[Definition: A trust anchor or certificate is interactively accepted if the acceptance was caused through a user interaction that happens whlie the user is focused on a primary task unrelated to trust and certificate management.]

For example, if a web server certificate is presented for acceptance by a user during ordinary Web interactions, and is accepted by the user, then this matches the test for interactive acceptance. If, however, a systems administrator (or user) adds a trust anchor's certificate to a browser's store of trust roots, then that certificate is not considered accepted interactively.

5.1.2 Augmented Assurance Certificates

Some trust anchors adhere to broadly accepted industry standards (e.g. [EVTLSCERT]) that involve some level of guarantee that certificates chaining up to those roots embody augmented assurance and can therefore be treated more favourably in terms of the primary security indicators. In order to allow a Web user agent to provide such special treatment, the trust anchor, and possibly all certificates in a path chaining up to such a trust anchor may need to be specially marked, e.g. through the use of specific policy object identifiiers.

The specific marking mechanisms to be used and the special treatment to be afforded to such certificates are out of scope of this document but will typically be covered by the underlying augmented assurance specification. Web user agent implementers determine the set of such standards that they support and the associated special treatment to apply, other than as outlined below, where we impose some consistency requirements on the handling of this type of certificate.

Web user agents MUST establish that a trust anchor is [Definition: AA-qualified ] through some out of band mechanism consistent with the relevant underlying augmented assurance specification.

Marking a trust anchor as AA-qualified is a security-critical step and most often will involve the use of some application-specific out-of-band mechanism.

Implementations MUST NOT enable users to designate trust roots as AA-qualified as part of a different interaction. Implementations MAY make user interfaces available for the purpose of designating AA-qualified trust roots. Such user interfaces MUST be focused on this specific task. In particular, the notions of an AA-qualified trust root and an interactively accepted trust root are mutually exclusive.

[Definition: An Augmented Assurance Certificate (AAC) is a public key certificate where the issuer asserts that the subject entity has been authenticated by means of some process that adheres to the requirements of an augmented asurance specification supported by the Web user agent. The certificate chain for such a certificate MUST be validated up to a trust root that is recognized as AA-qualified by the user agent.]

To derive a human-readable subject name from an AAC, user agents MUST use the Subject field's Organization (O) attribute.

If the certificate's Subject field does not have an Organization attribute, then user agents MUST NOT consider the certificate as an augmented assurance certificate, even if it chains up to an AA-qualified trust root. User agents MAY consider such a certificate as an ordinary validated certificate.

5.1.3 Validated Certificates

The term [Definition: validated certificate ] is used to denote a public key certificate that has been verified by chaining up to a locally configured trust anchor. The set of trust anchors used by a given Web User agent is implementation-dependent.

Since Augmented Assurance Certificates chain up to a "special" trust anchor, all valid Augmented Assurance Certificates are also validated certificates.

Self-signed certificates and certificates that chain up to untrusted root certificates, even if pinned to a particular destination, are not considered validated certificates.

5.1.4 Logotype Certificates

RFC 3709 [RFC3709] defines a certificate extension to embed three kinds of logotypes with an X.509 certificate, for use with public key certificates [RFC3280] or attribute certificates [RFC3281].

[Definition: The Community logotype is a logotype that identifies a community.]

[Definition: The Issuer Organization logotype is a logotype that identifies the organization that issued the certificate.]

[Definition: The Subject Organization logotype is a logotype that identitifies the organization to which the certificate was issued.]

Logotype certificates that are validated, are considered validated certificates.

Where this specification suggests or mandates the rendering of (either audio or visual) logotypes, the logotype is chosen as follows:

• When the logotype information is derived from an augmented assurance certificate, then the subject logotype MUST be rendered, if present.

• Otherwise, when the logotype information is derived from a validated certificate, then the issuer logotype MUST be rendered, if present.

Note that an augmented assurance certificate that does not include a subject logo will cause the issuer logotype, if present, to be rendered.

The rendering of audio logotypes SHOULD be limited to a short amount of time, and clearly separate from any rendering of other security context information. In particular, user agents MAY shorten audio logotypes for playback. When a user agent will both display visual logotype information as well as emit/play audio logotype information, the user agent MUST ensure that the display/play of these two forms are time-synchronized so that the start times of their display/play coincides visibly and audibly.

5.1.5 Self-signed Certificates and Untrusted Root Certificates

Self-signed certificates (SSC) are commonly used for appliances and web sites catering to small groups of users, and essentially serve as a container for cryptographic key material in a key exchange that is not verified by any third party. Custom root certificates which are not part of the user agent's store of trust roots (technically, another instance of self-signed certificates, but at the top of a nontrivial certificate chain) are used similarly.

In both situations, use of TLS provides confidentiality protection services against passive attackers. No binding of a third-party asserted identity to the cryptographic key is achieved. In both cases, the certificates are not considered validated certificates.

If a Web site consistently presents the same self-signed certificate (or the same certificate chaining up to the same untrusted root) to a client, then this can be strong evidence that protection against an active attacker has been achieved as well. Conversely, a change of certificates for the same site can be evidence that a man in the middle attack occurs -- or it can be a symptom that the legitimate site has changed to a different certificate.

Web user agents MAY support [Definition: pinning] a self-signed certificate or more generally a certificate chain that leads to an untrusted root certificate to a particular Web site, to enable behavior based on recorded state about certificates shown previously by the same site. Such behavior includes, e.g., warning users about changes of certificates, and not showing warning messages if a site shows a certificate consistent with previous visits.

The interaction that enables users to pin a certificate to a destination SHOULD NOT cause a self-signed certificate to be pinned to more than one site, identified through URI scheme, domain, and port. The interaction MUST NOT cause an untrutsed root certificate to be accepted automatically for additional sites. It SHOULD enable users to assign a petname to the site.

5.1.6 Petnames

For TLS-secured pages, the user MAY 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.

Presentation of a petname MUST support renaming and deleting of a petname binding.

When the user assigns a petname, the petname presentation implementation MUST warn the user if the chosen petname is similar to one currently in use. The meaning of similar is up to the implementation, but MUST at least include an identical petname.

A web user agent that supports petnames MUST also support a presentation of bookmarks that presents the association between each bookmark and the petname of the hosting site. If the hosting site could be assigned a petname, but the user has not yet done so, the presentation MUST present those bookmarks as being associated with a distinct, but not yet petnamed site. If the hosting site cannot be assigned a petname, because the hosting site does not support the previously established constraints for assignment of a petname, the presentation MUST indicate so. This bookmark presentation MUST support assignment, renaming and deletion of petnames.

5.4.1 TLS errors

This section covers TLS-related error conditions, and maps them to the classes of error handling interactions (see 6.4 Error handling and signalling) that are used when these conditions arise.

If multiple error conditions apply, the most severe signalling level SHOULD be used, as defined in 6.4 Error handling and signalling.

When, for a TLS-protected HTTP connection, the certificate chain presented by the server does not lead to a trusted root certificate, and the certificate chain presented was not pinned to the destination at hand, the following applies:

• If a different certificate was previously pinned to the same destination, then error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used. User agents MAY offer the possibility to pin the newly encountered certificate to the destination at hand.
• If a validated certificate (including an augmented assurance certificate) was previously presented by the same destination, then error signalling of class danger (6.4.4 Danger Messages) MUST be used.
• Otherwise, user agents MAY use error signalling of class notification (6.4.2 Notifications and Status Indicators ) to offer pinning a given certificate, consistent with 5.1.5 Self-signed Certificates and Untrusted Root Certificates.
• Otherwise, user agents SHOULD use error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages).

When certificate information is presented in these interactions, human-readable information derived from the certificates (e.g., Common Name or Organization attributes) in question MUST NOT be presented as trustworthy.

When, for a TLS-protected HTTP connection, the certificate presented is found to have been revoked, error signalling of class danger (6.4.4 Danger Messages) MUST be used. If certificate status checks are performed by a user agent, and a certificate is found to be outside its validity period, then the certificate MUST be considered revoked. Otherwise, the fact that a certificate is outside its validity period SHOULD be communicated using error signalling of class warning (6.4.3 Warning/Caution Messages ).

When certificate status checks are attempted, but failed due to network errors or related error conditions, the following applies:

1. If a certificate check was successfully performed before, or if an Augmented Assurance Certificate is used, then error signalling of level danger (6.4.4 Danger Messages) MUST be used.
2. Otherwise, error signalling of level warning (6.4.3 Warning/Caution Messages ) SHOULD be used.

When the URL corresponding to the transaction at hand does not match the certificate presented, and a validated certificate is used, then error signalling of level warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used.

If TLS negotiation otherwise fails, error signalling of level danger (6.4.4 Danger Messages) MUST be used.

The requirements in this section do not require user agents to store information about past interactions longer than they otherwise would. Historical TLS information stored for the purposes of evaluating security relevant changes of behavior MAY be expunged from the user agent on the same schedule as other browsing history information. Historical TLS information MUST NOT be expunged prior to other browsing history information. For purposes of this requirement, browsing history information includes visit logs, bookmarks, and information stored in a user agent cache.

5.4.2 Error Conditions based on Third Party or Heuristic Information

User agents that use third party services or heuristic approaches to assess the possible danger of a pending Web transaction MUST use error signalling of class danger (6.4.4 Danger Messages) to signal positively identified dangers, e.g., identified malicious downloads or exploits of user agent vulnerabilities.

To signal risks that are identified with high likelihood, but involve further user decisions (e.g., phishing heuristics were triggered), error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used.

5.4.3 Redirection chains

When users follow hyperlinks, user agents are often presented with a chain of redirections, maybe based on HTTP codes, maybe based on scripting. In some situations, the link might be located on a TLS-secured page, yet, the chain of redirects involves plain HTTP, or weakly TLS-protected HTTP transactions, thereby leading to additional exposure, with a high potential for user confusion.

Web user agents MUST signal an error of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) when a user interaction with a TLS-secured page causes dereferencing of a URL that leads to a chain of Web transactions that:

• does not involve user interactions, and,
• involves weakly TLS-protected or unprotected HTTP transactions.

Note that this applies whether or not the resource in which the non-interactive chain of redirections terminates is TLS protected in any manner. In particular, even if the retrieval of the final resource in the chain of redirections is strongly TLS protected, clients MUST signal an error. Also note that this section is not limited to HTTP level redirection mechanisms; it also covers redirections that are caused by scripting or HTML constructs.

This section does not apply to situations in which, e.g., an HTML form is served by way of a strongly TLS protected transaction, but the user's input is submitted through plain HTTP.

6.1.1 Identity Signal

This section is normative. Examples are informational.

Web user agents MUST make information about the [[identity]] of the Web site that a user interacts with available. This [Definition: [[identity signal]] ] SHOULD be part of primary user interface during usage modes which entail the presence of signalling to the user beyond only presenting page content. Otherwise, it MUST at least be available through secondary user interface. Note that there may be usage modes during which this requirement does not apply: For example, a Web browser which is interactively switched into a no-chrome, full-screen presentation mode need not preserve any security indicators in primary user interface.

If a positive form of identity is available, the identity signal MUST be part of primary user interface when any identity sources that are from unauthenticated or untrusted sources are (also) part of the primary user interface. These sources include URLs.

User interactions to access this identity signal MUST be consistent across all Web interactions facilitated by the user agent, including interactions during which the Web user agent has no trustworthy information about the [[identity]] of the Web site that a user interacts with. In this case, user agents MUST indicate that no information is available.

User agents with a visual user interface that make the identity signal available in primary user interface SHOULD do so in a consistent visual position.

6.1.2 Identity Signal Content

This section is normative. Examples are informational.

Information displayed in the identity signal MUST be derived from validated certificates, or from user agent state. Web user agents MUST NOT use information as part of the [[identity signal]] that is taken from unauthenticated or untrusted sources.

During interactions with a TLS-secured Web page for which a petname has been defined, the identity signal MUST include that petname.

During interactions with a TLS-secured Web page for which the top-level resource has been retrieved through a strongly TLS-protected interaction that involves an augmented assurance certificate, the following applies:

• The identity signal MUST include human-readable information about the certificate subject, derived as specified in 5.1.2 Augmented Assurance Certificates, to inform the user about the owner of the Web page, unless a petname is displayed.

• For Web user agents that use a visual user interface capable of displaying bitmap graphics the identity signal MAY include display of a suitable logotype, selected according to the rules in 5.1.4 Logotype Certificates.

• Web user agents that use sound to communicate with the user MAY render an audio logotype that is embedded in the certificate using the logotype extension, according to the requirements in 5.1.4 Logotype Certificates.

During interactions with a TLS-secured Web page for which the top-level resource has been retrieved through a strongly TLS-protected interaction that involves an validated certificate (including an augmented assurance certificate), the following applies:

• If the identity signal does not include any other human readable information about the identity of the certificate subect (derived, e.g., from an augmented assurance certificate or a petname), then it MUST include an applicable DNS name retrieved from the subject's Common Name attribute or from a subjectAltName extension.

• The identity signal MUST include the Issuer field's Organization attribute to inform the user about the party responsible for that information.

• Subject logotypes derived from certificates SHOULD NOT be rendered, unless the certificate used is an augmented assurance certificate.

Note that this behavior does not apply when self-signed certificates or certificate chains that chain up to an untrusted root certificate are used.

During interactions with a mixed content Web page, the identity signal MUST NOT include any positive indicators exceeding those in use for unprotected HTTP transactions. In this situation, the identity signal MAY include indicators that point out any error conditions that occurred.

During interactions with mixed content, Web user agents MUST NOT render any logotypes derived from certificates.

6.4.1 Common Error Interaction Requirements

Error signalling that occurs as part of primary chrome SHOULD be phrased consisely when using natural language.

Primary chrome error messages MUST NOT include technical jargon. They SHOULD NOT refer the user to enter the destination site that caused the error, e.g., to provide feedback or obtain assistance. For error messages that interrupt the user's flow of interaction, user agents SHOULD enable the user to easily return to the user agent state prior to initiation of the last user interaction that led to the error signal.

For advanced users, error interactions SHOULD have an option for advanced users to request a detailed description of the condition that caused the interaction to occur.

The error interactions characterized in this section are intended to communciate security context information, and therefore MUST fulfill relevant requirements in 7.1 Chrome and User Interface Practices.

6.4.2 Notifications and Status Indicators

Notifications and status indicators are used when the browser cannot accurately determine a security risk based on the current security context information available. These indicators SHOULD also be used for situations in which the risk level may vary based on user preference.

For visual user agents, notifications and status indicators MUST be displayed in the user agent's persistent primary chrome. These indicators MUST NOT force user interaction (e.g., forcing the user to click a button to continue the primary task). They MUST include a succinct textual description of their meaning.

6.4.3 Warning/Caution Messages

Warning / Caution messages MUST be used when the system has good reason to believe that the user may be at risk based on the current security context information, but a determination cannot positively be made. These warnings SHOULD be used if the likelihood of danger is present, but cannot be confirmed.

Warning / Caution messages MUST interrupt the user's current task, such that the user must acknowledge the message.

For user agents with a visual user interface, headings of these warnings MUST include words meaning "caution" or "warning". The headings of these warnings MUST be the locus of attention.

Warning / Caution messages MUST provide the user with distinct options how to proceed (i.e., these messages MUST NOT lead to a situation in which the only option presented to the user is to dismiss the warning and continue). The options presented on these warnings MUST be descriptive to the point that their meanings can be understood in the absence of any other information contained in the warning interaction. These warnings SHOULD include one recommended option, and a succinct text component denoting which option is recommended. In the absence of a recommended option, the warning MUST present the user with a method of finding out more information (e.g., a hyperlink, secondary window, etc) if the options cannot be understood.

6.4.4 Danger Messages

Danger Messages MUST be used when there is a positively identified danger to the user (i.e., not merely a risk).

The interactions communicating these messages MUST be designed such that the user's task is interrupted.

For visual user agents, these interactions MUST be presented in a way that makes it impossible for the user to view or interact with the destination web site that caused the danger situation to occur. The headings of these warnings MUST include a word meaning "danger." The heading MUST be the locus of attention.

7.1.1 Use Shared Secrets to Establish a Trusted Path

A trusted path can be established between a web user agent or web site and the user through the use of a secret shared between the user and the agent or site. The shared secret may be an image selected by the user, or can be another type of secret (e.g., text or audio) to meet accessibility requirements. If the shared secret is difficult to guess, it is difficult to exactly emulate, so robust against that aspect of spoofing attacks. Having such a trusted path will not ensure that all users do not fall for phishing attacks (see Emporer's New Security Indicators [EMPEROR]), but known attacks against these trusted paths do not include spoofing.

Web user agents that proactively present security context information to the user (or a channel presumed to eventually lead to the user, such as accessibility aides) MAY accept some presentation information from the user, and associate that information with parts of the user interface that are intended or commonly used to communicate trust information to users.

Techniques to implement this practice for visual user agents include giving the user a selection of backgrounds, skins, or tartans, and customize the graphical look of the web browser with them. Knowing the set of secrets the user can choose from can increase the attackers ability to spoof them, particularly if a small subset is popular. Another technique is to take user specific graphics and use them the same way. If a malicious site can get the user to customize it the same way, it might be possible for the site to spoof the browser.

Techniques for user agents that expose a voice-based user interface include chosing different voices for the presentation of Web content and security context information.

7.1.2 Keep Security Chrome Visible

For visual user agents, in usage modes in which browser chrome is used to signal security context information, that chrome should always be visible during interactions with Web content.

This requirement is scoped to a specific interaction: When multiple Web pages might be displayed, security critical chrome need not be present for those with which the user is not currently interacting. However, chrome used to communicate security context information that relates to the currently interacted Web page must always remain on the screen.

7.4.1 Obscuring or disabling Security User Interfaces

Web user agents MUST prevent web content from obscuring, hiding, or disabling security user interfaces.

Techniques to implement this requirement include:

• Web user agents SHOULD restrict window sizing and moving operations consistent with 7.1.2 Keep Security Chrome Visible. This prevents attacks wherein browser chrome is obscured by moving it off the edges of the visible screen.

• Web user agents SHOULD NOT allow web content to open new windows with the browser's security UI hidden. Allowing this operation facilitates picture-in-picture attacks, where artificial chrome (usually indicating a positive security state) is supplied by the web content in place of the hidden UI.

• Web user agents MUST prevent web content from overlaying chrome. User interactions that are perceived to deal with browser chrome must not be detectable for Web content.

7.4.2 Software Installation

Web user agents MUST NOT expose programming interfaces which permit installation of software, or execution of privileged code without a user intervention.

Web user agents MUST inform the user and request consent when web content attempts to install software outside of the browser environment. The interaction used MUST follow the requirements in 6.4.3 Warning/Caution Messages . Web user agents SHOULD NOT provide features which can be used by web content to install software outside of the browser environment without the user's consent. Web user agents MAY provide mechanisms for users to pre-consent to a class of software installations. Web user agents SHOULD inform the user when web content is installing software outside of the browser environment that is covered by a pre-consent.

Web user agents MAY inform the user when web content attempts to execute software outside of the agent environment, and MAY also request user consent, but SHOULD NOT do so unconditionally for all types of content or software. If the agent chooses to do this then it SHOULD do so for specific content types, software types, or security context based on risk.

7.4.3 Bookmarking APIs

Web user agents MUST NOT expose programmatic interfaces that allow bookmarking without explicit user consent. That consent MUST follow the requirements from 6.4.2 Notifications and Status Indicators .

Web user agents MUST NOT expose programmatic interfaces that allow bookmarking an URL that does not match the URL of the page that the user currently interacts with.

7.4.4 Pop-up Window APIs

With visual user interfaces that use a windowed interaction paradigm, Web user agents [[MAY | SHOULD]] restrict the opening of pop-up windows from web content, particularly those not initiated by user action. Creating excessive numbers of new popup windows is a technique that can be used to condition users to rapidly dismissing dialogs. This can be employed in interaction flooding attacks.

Web user agents which offer this restriction SHOULD offer a way to extend permission to individual trusted sites. Failing to do so encourages users who desire the functionality on certain sites to disable the feature universally.