Edit comment LC-2087 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-2087

Comment Shortname:

Commenter: Thomas Roessler <tlr@w3.org> on behalf of timeless@gmail.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:

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

why is this a should not instead of a must not?

Related issues: (space separated ids)

WG Notes: Per discussion on 3 September, the Working Group leans toward agreeing. However, there is a concern that, in debugging UI, it makes sense to show such logotypes. There is an open action item to draft a more elaborate piece of text. action-524 - isn't happening decided to go to must not/jan 14 2009 action-563 to update text

Resolution: Thank you. While we have discussed this, and decided on MUST NOT.

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