Edit comment LC-2092 for Web Security Context Working Group

Quick access to LC-2056 LC-2057 LC-2058 LC-2059 LC-2087 LC-2088 LC-2092 LC-2093 LC-2094 LC-2095 LC-2129

Comment LC-2092

Comment Shortname:

Commenter: Sigbjørn Vik <sigbjorn@opera.com>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeWeb Security Context: User Interface Guidelines... Web Security Context: User Interface Guidelines W3C Working Draft 24 July 2008 Abstract Status of this Document Table of Contents 1 Overview 2 Acknowledgments 3 Conformance 3.1 Product classes 3.2 Language conventions 3.3 Conformance levels 3.4 Conformance claims 4 Interaction and content model 4.1 Overview 4.2 Terms and definitions 4.2.1 Common User Interface elements 5 Applying TLS to the Web 5.1 Certificate Handling and Information 5.1.1 Interactively accepting trust anchors or certificates 5.1.2 Augmented Assurance Certificates 5.1.3 Validated Certificates 5.1.4 Logotype Certificates 5.1.5 Self-signed Certificates and Untrusted Root Certificates 5.1.6 Petnames 5.2 Types of TLS 5.3 Mixed Content 5.4 Error conditions 5.4.1 TLS errors 5.4.2 Error Conditions based on Third Party or Heuristic Information 5.4.3 Redirection chains 5.4.4 Insecure form submission 6 Indicators and Interactions 6.1 Identity and Trust Anchor Signalling 6.1.1 Identity Signal 6.1.2 Identity Signal Content 6.2 Additional Security Context Information 6.3 TLS indicator 6.4 Error handling and signalling 6.4.1 Common Error Interaction Requirements 6.4.2 Notifications and Status Indicators 6.4.3 Warning/Caution Messages 6.4.4 Danger Messages 6.5 Chrome Reconfiguration 7 Robustness 7.1 Chrome and User Interface Practices 7.1.1 Use Shared Secrets to Establish a Trusted Path 7.1.2 Keep Security Chrome Visible 7.2 Do not mix content and security indicators 7.3 Managing User Attention 7.4 APIs Exposed To Web Content 7.4.1 Obscuring or disabling Security User Interfaces 7.4.2 Software Installation 7.4.3 Bookmarking APIs 7.4.4 Pop-up Window APIs 8 Security Considerations 8.1 Active attacks during initial TLS interactions 8.2 Certificate Status Checking Failures 8.3 Certificates assure identity, not security 8.4 Binding "human readable" names to domain names 8.5 Warning Fatigue 8.6 Mixing Augmented Assurance and Validated Certificates 9 References
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

A couple of comments regarding the wording of a paragraph.

"User agents SHOULD store the state of certificates that were previously
encountered. (specifically, whether or not a site previously presented a
validated certificate). 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."

This sentence requires UAs to store the certificate information until
other browsing history information (specifically bookmarks) is deleted. As
we know that users never delete their bookmarks, the conclusion must be
that the certificate information can never be deleted.

The intention should be that the certificate information gets stored along
with other historical data as long as the user/UA keeps this around.
Bookmarks in themselves are not historical data, though bookmarks may
contain historical data such as time created, last visited, favicons (the
favicon might contain a timestamp) and other. Different types of
historical data might be treated by a UA in different ways (expunged at
different schedules for instance), so treating certificate data the same
way as all the other types might not be possible.

I propose a rewrite and clarification of the paragraph, particularily with
the intention. As the paragraph stands now, a UA cannot let the user
manually expunge certificate information only, as this would be in
violation of the MUST NOT clause. Proposal follows:

"User agents SHOULD store the state of certificates that were previously
encountered. Such state would typically include at least whether or not
the certificate the site presented was valid, and may also include what
the issues were with it (if any), protocol information, a fingerprint of
the certificate and any other information for the purposes of evaluating
security relevant changes of behavior. This information MUST be treated by
the user agent under the same privacy and caching policies as other
browsing history information, such as visit logs, timestamps in bookmarks,
cookies, and information stored in the user agent cache."

Related issues: (space separated ids)

WG Notes: Discussed in: http://www.w3.org/2008/10/08-wsc-minutes.html http://www.w3.org/2006/WSC/track/actions/524 This part of the spec has been dropped due to lack of implementation/testing.

Resolution: Thank you. We have removed a number of items in wsc-ui due to lack of implementation and testing, and this is one of the items that has been removed.

(Please make sure the resolution is adapted for public consumption)