• FeaturesAtRisk

This is a cut and paste of the rewrite.xml from June 10, 2008, with normative language called out

References:

• /2006/WSC/wiki/Opera_9.50_Conformance_with_June_LC

• /2006/WSC/wiki/Firefox_3.0_Conformance_with_June_LC

*1: Note: we don't indicate weak/strong, but by default we have weak ciphers disabled

5 Applying TLS to the Web

5.1.2 Augmented Assurance Certificates

1. 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.
2. Implementations MUST NOT enable users to designate trust roots as AA-qualified as part of
   • a different interaction.
3. Implementations MAY make user interfaces available for the purpose
   • of designating AA-qualified trust roots.
4. Such user interfaces MUST be focused on this
   • specific task.
5. To derive a human-readable subject name from an AAC, user agents MUST use the Subject
   • field's Organization (O) attribute.
6. 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.
7. User agents MAY consider such a certificate as an ordinary validated certificate.

5.1.4 Logotypes

1. When the logotype information is derived from an augmented assurance certificate, then the
   • subject logotype MUST be rendered, if present.
2. Otherwise, when the logotype information is derived from a validated certificate, then the issuer logotype MUST be
   • rendered, if present.
3. 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.
4. In particular, user
   • agents MAY shorten audio logotypes for playback.
5. 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

1. 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.
2. 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.
3. The interaction MUST NOT cause an untrusted root certificate to be accepted automatically for additional sites.
4. A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a petname with the site, if supported.
5. If a client is able to automatically accept a self-signed certificate, or recover from similar problem without user interaction, it MUST NOT do so unless the client also have a history mechanism about security information.

5.1.6 Petnames

1. For TLS-secured pages, the user MAY assign the
   • authenticated entity a [Definition: petname].
2. 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.
3. 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.
4. It MUST NOT create a binding from the petname to
   • any other destination.
5. 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
6. Presentation of a petname MUST support renaming and deleting of a petname binding.
7. 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.
8. The meaning of similar is
   • up to the implementation, but MUST at least include an identical petname.
9. 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.
10. 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.
11. 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.
12. This bookmark presentation MUST support assignment, renaming and deletion of petnames.

5.3 Mixed Content

1. A user agent that can display an AA indicator MUST NOT display this indicator unless all elements of the page are loaded from servers presenting a validated certificate, over strongly protected TLS connections.

5.4.1 TLS errors

1. If multiple error conditions apply, the most severe signalling level currently known MUST be used, as
   • defined in 6.4 Error handling and signalling.
2. 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 to user agents that are capable of storing and using information about certificates that were previously encountered:
   1. 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.
3. 2. 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.
4. User agents MAY offer the possibility to pin the
   • newly encountered certificate to the destination at hand.
5. 3. 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.
6. 4. Otherwise, user agents SHOULD use error signalling of class warning or above (6.4.3
   • Warning/Caution Messages
   • , 6.4.4 Danger Messages).
7. In the same circumstances, the following applies to user agents that are not capable of
   • using information about previously encountered certificates.
   1. Error signalling of class warning or above (6.4.3
      • Warning/Caution Messages
      • , 6.4.4 Danger Messages) MUST be used to signal the error condition.
8. 2. User agents MAY offer a possibility to pin newly encountered certificates to
   • the destination at hand.
9. User agents SHOULD store the state of certificates that were previously encountered.
   • (specifically, whether or not a site previously presented a validated certificate).
10. 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.
11. Historical TLS information MUST NOT be expunged prior to other
    • browsing history information.
12. 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.
13. When certificate information is presented in these interactions,
    • web user agents MUST NOT display identity information from a self signed or untrusted certificate in a warning or error message.
14. Web user
    • agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.
15. 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.
16. When, for a TLS-protected HTTP connection, the certificate presented is found to have been
    • expired, error signalling of class danger (6.4.4 Danger Messages) MUST be used.
17. When certificate status checks are attempted, but where the check fails, (i.e. does not produce an answer as to certificate status), due to network errors or related error conditions, the following applies:
18. 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 danger(6.4.4 Danger Messages) MUST be used.
19. If TLS negotiation otherwise fails, error signalling of level danger (6.4.4 Danger Messages) MUST be used.

5.4.2 Error Conditions based on Third Party or Heuristic Information

1. 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.
2. 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

1. 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.
2. In particular, even if the retrieval
   • of the final resource in the chain of redirections is strongly TLS protected, clients MUST signal an error.

6.1.1 Identity Signal

1. Web user agents MUST make information about the identity of the Web site that a user
   • interacts with available.
2. 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.
3. 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 presentation mode that does not display any chrome need not preserve security indicators in primary user interface.
4. 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.
5. 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.
6. In this case, user agents MUST indicate that no information is
   • available.
7. 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.
8. Web Content MUST not obscure security chrome,

6.1.2 Identity Signal Content

1. Information displayed in the identity
   • signal MUST be derived from validated certificates, or from user agent state.
2. Web user agents MUST NOT use information
   • as part of the identity signal that is taken from unauthenticated or untrusted sources.
3. During interactions with a TLS-secured Web page for which a petname has been defined, the identity signal MUST include that petname.
4. 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.
5. *
   • 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.
6. *
   • 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.
7. 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 subject (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.
8. *
   • The identity signal MUST include the Issuer field's Organization attribute to
     • inform the user about the party responsible for that information.
9. *
   • Subject logotypes derived from certificates SHOULD NOT be rendered, unless the
     • certificate used is an augmented assurance certificate.
10. 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.
11. In this
    • situation, the identity signal MAY include indicators that point out any error conditions that occurred.
12. During interactions with mixed content, Web user agents MUST NOT render any logotypes
    • derived from certificates.

6.2 Additional Security Context Information

1. Web user agents MUST provide additional security context
   • information as described in this section through one or more user-accessible information sources.
2. Where security context
   • information is provided in both primary and secondary chrome, the presentation and semantics of the presented information MUST be consistent.
3. The information sources MUST make the following security context
   • information available:
   1. the Web page's domain name
4. 2. Owner information, consistent with 6.1.2 Identity Signal Content
5. 3. Verifier information, consistent with 6.1.2 Identity Signal Content
6. 4. The reason why the identity information is trusted (or
   • not). This includes whether or not a certificate was accepted interactively, whether a self-signed certificate was used, and whether the self-signed certificate was pinned to the site that the user interacts with, and whether trust relevant settings of the user agent were otherwise overridden through user action.
7. The information sources SHOULD make the following security context
   • information available:
   1. Whether a Web page is TLS-protected, whether the protection is
      • weak or strong, and the reasons for the value of the protection.
8. 2. When the Web page is TLS-protected and a validated
   • certificate was used, whether or not a certificate status check has been performed.
9. 3. If a certificate status check has been performed, what
   • the result was.
10. 4. Whether the user has visited the site in the past.
11. 5. Whether the user has shown
    • credentials to this site.
12. 6. Whether the user has stored credentials for this
    • site.
13. 7. Whether the site content was encrypted in transmission.
14. 8. Whether the site content was authenticated.
15. 9. Logotypes embedded in certificates used, consistent with
    • 6.1.1 Identity Signal and 5.1.4 Logotype Certificates.
16. Additionally, the information sources MAY make the following security
    • context information available:
17. 1. When the user most recently visited the site in the
    • past.
18. 2. When the user first visited the site in the past.
19. 3. How often the user visited the site in the past.
20. User agents that provide information about the presence or absence of Cookies [RFC2965] MUST NOT make any claims that suggest that the absence of cookies
    • implies an absence of any user tracking, as there are numerous tracking and session management techniques that do not rely on Cookies.

6.3 TLS indicator

1. Web user agents MUST make information about the state of TLS protection available.
2. The
   • [Definition: TLS indicator] SHOULD be part of primary user interface during usage modes which entail the presence of signalling to the user beyond only presenting page content.
3. Otherwise, it MUST at least be available through secondary
   • user interface.
4. Web content MUST not obscure security chrome,
5. User interactions to access the TLS indicator MUST be consistent across all Web
   • interactions. This includes when TLS has not been used to protect those interactions.
6. In
   • this case, web user agents SHOULD indicate the interaction was not TLS protected.
7. User
   • agents with a visual user interface that make the TLS indicator available in primary user interface SHOULD do so in a consistent visual position.
8. The TLS indicator MUST present a distinct state that is used only for TLS-secured Web pages.
9. The User Agent SHOULD inform users
   • when they are viewing a page that, along with all dependent resources, was retrieved through at least weakly TLS protected transactions, including mixed content.
10. The user agent MAY accomplish this by using a third state in the TLS indicator, or via
    • another mechanism (such as a dialog, infobar, or other means).

6.4.1 Common Error Interaction Requirements

1. Error signalling that occurs as part of primary
   • chrome SHOULD be phrased in terms of threat to user's interests, not technical occurrence.
2. Primary chrome error messages MUST NOT be
   • phrased solely in terms of art, e.g., jargon.
3. They SHOULD NOT refer the user to enter the destination
   • site that caused the error, e.g., to provide feedback or obtain assistance.
4. 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.
5. 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.

6.4.2

• Notifications and Status Indicators

1. These indicators SHOULD also be used for situations in which the risk level may vary
   • based on user preference.
2. For visual user agents, notifications and status indicators MUST be displayed in the
   • user agent's persistent primary chrome.
3. These indicators MAY include user interaction (e.g., forcing the user to click a
   • button to continue the primary task).
4. They MUST include a succinct textual description
   • of their meaning.

6.4.3

• Warning/Caution Messages

1. 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.
2. These warnings SHOULD be used if the likelihood
   • of danger is present, but cannot be confirmed.
3. Warning / Caution messages MUST interrupt the user's current task, such that the user
   • must acknowledge the message.
4. 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.
5. 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).
6. 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.
7. These warnings
   • SHOULD include one recommended option, and a succinct text component denoting which option is recommended.
8. 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

1. Danger Messages MUST be used when there is a positively identified danger to the user
   • (i.e., not merely a risk).
2. The interactions communicating these messages MUST be designed such that the user's task
   • is interrupted.
3. These interactions MUST be presented in a way that makes it impossible for the user go to or interact with the destination web site that caused the danger situation to occur, without first explicitly interacting with the Danger Message.

6.5 Chrome Reconfiguration

1. If a Web User Agent permits the user to administratively reconfigure

the primary user interface in such a way as to suppress any of the displays required by this specification, then it MUST provide a simple administrative mechanism, such as a single button in a configuration menu, to reset the display to be in conformance with this specification.

7.1.1 Use Shared Secrets to Establish a Trusted Path

1. 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.

7.1.2 Keep Security Chrome Visible

1. For visual user agents, browser chrome SHOULD always be present to signal security context information.
2. This requirement is scoped to a specific interaction: When multiple Web pages might be
   • displayed, security critical chrome MAY be not present for those with which the user is not currently interacting.
3. However, chrome used to communicate security context
   • information that relates to the currently interacted Web page MUST always remain on the screen.

7.2 Do not mix content and security indicators

1. Web User Agents MUST NOT communicate trust information using user interface elements which
   • can be mimicked within chrome under the control of web content.
2. Site-controlled content (e.g. page title,
   • favicon) MAY be hosted in chrome,
3. but this content MUST NOT be displayed in a manner that
   • confuses hosted content and chrome indicators.
4. In particular, Web User Agents SHOULD NOT use a 16x16 image in chrome to indicate security status if
   • doing so would allow the favorite icon to mimic it.

7.3 Managing User Attention

1. User interfaces used to inform users about security critical events or to solicit comment
   • MUST employ techniques that prevent immediate dismissal of the user interface, e.g., by using a temporarily disabled "OK" button on user interfaces that make such an interaction paradigm available.
2. When users interact with security relevant notifications (6.4.3
   • Warning/Caution Messages
   • and above), interactions caused by Web content MUST NOT be granted
   • control of the user agent's interaction.

7.4.1 Obscuring or disabling Security User Interfaces

1. Web user agents MUST
   • prevent web content from obscuring, hiding, or disabling security user interfaces.
2. Web user agents MUST restrict window sizing and
   • moving operations consistent with 7.1.2 Keep Security Chrome Visible.
3. Web user agents MUST NOT allow web content to open new windows
   • with the browser's security UI hidden.
4. Web user agents MUST prevent web content from overlaying
   • chrome.

7.4.2 Software Installation

1. Web user agents MUST
   • NOT expose programming interfaces which permit installation of software, or execution of privileged code without a user intervention.
2. Web user agents MUST inform the user and request consent when
   • web content attempts to install software outside of the browser environment.
3. The
   • interaction used MUST follow the requirements in 6.4.3
     • Warning/Caution Messages
4. . 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.
5. Web user agents MAY provide
   • mechanisms for users to pre-consent to a class of software installations.
6. 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.
7. Web user agents MAY inform the user when web content attempts to execute software
   • outside of the agent environment,
8. and MAY also request user consent,
9. but SHOULD NOT do so
   • unconditionally for all types of content or software.
10. 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

1. 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
2. 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

1. With visual user interfaces that use a windowed interaction paradigm, Web user agents SHOULD restrict the opening of pop-up windows
   • from web content, particularly those not initiated by user action.
2. 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.