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

Comment Shortname:

Commenter: Philipp Gühring <pg@futureware.at>

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:

Hi,

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

The CPS's of several CA's are clearly stating that certificates for
non-registered organisations (universities, communities, partnerships,
....) or non-organisations (individuals, ...) must not contain an
Organization attribute.

Taking those 2 things together, this guideline is discriminating against
a large amount of people and institutions.

My current idea to somewhat solve this problem is to use either
Oraganization(O), or Surname(SN) + GivenName(GN) in case O is not available.

Best regards,
Philipp Gühring

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/525 double check on that actual text; put it in the comment

Resolution: Thank you. We have added the following text: Note: Should certificates arise in the future that provide strong assurance of the holder's identity, but do not include an organization attribute, then user agents can make use of the additional assurance level and identity information without violating this specification. Such future certificates could, for example, include high assurance certificates for individuals.

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