- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 22 Dec 2008 15:20:40 +0100
- To: WSC WG <public-wsc-wg@w3.org>
A new editor's draft is available: Web Security Context: User Interface Guidelines Editor's Draft 22 December 2008 $Revision: 1.278 $ $Date: 2008/12/22 14:20:19 $ Changes in document order; section numbers used are the old ones that we also refer to in the various meeting minutes that I'm linking. * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-evcert 5.1.2 Augmented Assurance Certificates As resolved on 10/23, strike: > 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. The paragraph now reads: > <p>Implementations MUST NOT enable users to designate trust roots as > AA-qualified as part of a different interaction. In particular, the > notions of an AA-qualified trust root and an <termref def="def- > interactively">interactively</termref> accepted trust root are > mutually exclusive.</p> http://www.w3.org/2008/10/23-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-logotypes 5.1.4 Logotypes Entire section deleted as resolved on 10/23. http://www.w3.org/2008/10/23-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#selfsignedcerts 5.1.5 Self-signed Certificates and Untrusted Root Certificates As resolved on 10/23, the following text is commented out: > If a client is able to automatically accept a self-signed > certificate, or recover from similar problem without user > interaction, it MUST support a mechanism to store and use > information about certificates that were previously encountered, and > to detect changes against historical usage of certificates as > described in more detail in section 5.4.1 TLS errors. As discussed on 10/24 (in pondering an answer to LC-2094, I believe), I got an action to mention Key Continuity Management in 5.1.5. I've changed the third paragraph of that section as follows: > Using Key Continuity Management [KCM], user agents can use self- > signed certificates (or certificates that chain up to an untrusted > root) to determine that they are consistently communicating with the > same end entity, thereby defending against active attacks as well. > Simply put, 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. [KCM] is a reference to draft-gutmann-keycont-01, that we'll have to update (or remove) in due course, depending on where that document goes. This discharges ACTION-535. http://www.w3.org/2006/02/lc-comments-tracker/39814/WD-wsc-ui-20080724/2094 http://www.w3.org/2008/10/23-wsc-minutes.html http://www.w3.org/2008/10/24-wsc-minutes.html http://tools.ietf.org/id/draft-gutmann-keycont-01.txt * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-petnames 5.1.6 Petnames Added a note that points to ISSUE-224. http://www.w3.org/2006/WSC/track/issues/224 * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors 5.4.1 TLS errors As resolved on 10/23, the text that refers to user agents capable of storing and using information about previous certificates is commented out: > 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: > > • 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. > • If a different certificate was previously pinned to the same > destination, then error signalling of class warning or higher (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. > • 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 higher (6.4.3 Warning/Caution Messages , 6.4.4 Danger > Messages). Additionally, the following text is commented out (decided, too, on 10/23): > 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. http://www.w3.org/2008/10/23-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#identity-requirement 6.1.1 Identity Signal Added a note that points to ISSUE-217. http://www.w3.org/2006/WSC/track/issues/217 * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#signal-content 6.1.2 Identity Signal Content Removed the following text as decided on 10/23: > • 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. Additionally, the following text is rewritten: > 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. ... into: > 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 that matches either the > subject's Common Name attribute or its subjectAltName extension. > User agents MAY shorten such a DNS name by displaying only a suffix. This takes care of ACTION-537 and ACTION-546 (these seem to be duplicates?) and closes ISSUE-216. http://www.w3.org/2008/10/23-wsc-minutes.html http://www.w3.org/2008/10/24-wsc-minutes.html http://www.w3.org/2008/12/03-wsc-minutes.html http://www.w3.org/2006/WSC/track/issues/216 http://www.w3.org/2006/WSC/track/actions/537 http://www.w3.org/2006/WSC/track/actions/546 * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary 6.2 Additional Security Context Information As resolved on 10/23, removed the following items: • When the Web page is TLS-protected and a validated certificate was used, whether or not a certificate status check has been performed. • If a certificate status check has been performed, what the result was. • Whether the user has shown credentials to this site. • Logotypes embedded in certificates used, consistent with 6.1.1 Identity Signal and 5.1.4 Logotype Certificates. http://www.w3.org/2008/10/23-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-common 6.4.1 Commopon Error Interaction Requirements I've changed the second paragraph into the following two, as resolved on 10/24: > Primary chrome error messages MUST NOT be phrased solely in terms of > art. For example, if a certificate includes a DNS name in the > subjectAltName extension that does not match the URI of the site > that the user tries to visit, an error message can explain that the > user is reaching a different site, instead of reporting a > "subjectAltName mismatch". > They SHOULD NOT refer... This takes care of ACTION-536, and relates to LC-2094. http://www.w3.org/2006/WSC/track/actions/536 http://www.w3.org/2008/10/24-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-notification 6.4.2 Notifications and Status Indicators As resolved on 10/24, this section is gone. http://www.w3.org/2008/10/24-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-warning 6.4.3 Warning/Caution Messages As resolved on 10/24, removed the following text: > 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. http://www.w3.org/2008/10/24-wsc-minutes.html Also, per ACTION-541 (relating to ISSUE-222), the text about options now reads as follows: > 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. One of the options offered SHOULD be > recommended, and the warning message SHOULD include 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. http://www.w3.org/2008/10/24-wsc-minutes.html http://www.w3.org/2006/WSC/track/issues/222 http://www.w3.org/2006/WSC/track/actions/541 * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#chrome-reconfig 6.5 Chrome Reconfiguration As resolved on 10/24, this text is gone. http://www.w3.org/2008/10/24-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sharedsecret-goodpractice * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#keepchromevisible-goodpractice 7.1.1 Use Shared Secrets to Establish a Trusted Path 7.1.2 Keep Security Chrome Visible As resolved on 10/24, 7.1.1 is gone. I've turned 7.1.2 into a single 7.1, and removed the forward reference from 6.4.2. Per ACTION-542 (which relates to ISSUE-223), the following text is dropped from that section: > 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. > However, chrome used to communicate security context information > that relates to the currently interacted Web page MUST always remain > on the screen. http://www.w3.org/2008/10/24-wsc-minutes.html http://www.w3.org/2006/WSC/track/actions/542 http://www.w3.org/2006/WSC/track/issues/223 * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#robustness-bookmarks 7.4.3 Bookmarking APIs As resolved on 10/24, the backwards reference to 6.4.2 is dropped. http://www.w3.org/2008/10/24-wsc-minutes.html * http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#Ref References Added reference to OCSP, ACTION-526 * I also fixed the typos listed in LC-2059; ACTION-547 http://www.w3.org/2006/02/lc-comments-tracker/39814/WD-wsc-ui-20080724/2059 http://www.w3.org/2006/WSC/track/actions/547 Happy holidays, -- Thomas Roessler, W3C <tlr@w3.org>
Received on Monday, 22 December 2008 14:20:54 UTC