Re: updates to Google Chrome Implementation report

There was a question about what SSL cipher suites we support. To answer
that:

On windows, we share system wide SSL settings for supported cipher suites,
that are typically set via group policy (gpedit.msc -> administrative
templates -> network -> ssl configuration settings). We explicitly disable
sslv2 and md4. We will soon be changing this to match our behaviour on
Linux, which is to enable only cipher suites with keys of at least 80 bits.
We don't currently have checks on the size of public keys or RSA moduli, but
if people have suggestions would be open to hearing them.

We don't have anything we accept but consider "weak".

Adding in WTC in case I misspoke anywhere.

Am 2. März 2010 17:35 schrieb Ian Fette (イアンフェッティ) <ifette@google.com>:

> This looks correct. Thanks Mez.
>
> Am 26. Februar 2010 07:31 schrieb Mary Ellen Zurko <mzurko@us.ibm.com>:
>
> · What user interface element is the *TLS indicator*<http://dl.dropbox.com/u/3356996/wsc-ui-diff-20100226.html>defined in this specification.
>> The padlock in the address bar
>>
>> · What user interface element is the *identity signal*<http://dl.dropbox.com/u/3356996/wsc-ui-diff-20100226.html>defined in this specification.
>> The location bar with the extra indicator information.
>>
>> · What broadly accepted practices are considered sufficient for a trust
>> anchor to be deemed augmented assurance qualified (see *5.1.2 Augmented
>> Assurance Certificates*<http://dl.dropbox.com/u/3356996/wsc-ui-diff-20100226.html> ),
>> and what data elements are deemed assured by those certificates. [added
>> “what data elements”.]
>> WebTrust EV audit, in accordance with CA/B Forum EV guidelines.
>> O= and C= are deemed assured by those certificates.
>>
>> II. To derive a human-readable subject name from an augmented assurance
>> certificate, user agents  SHOULD use the Subject field's Organization (O)
>>  and Country (C) attributes.
>>
>> Conforms Advanced
>>
>> IIa (or III replacement) They MUST  use information that is subject to the
>> certificate authority's additional assurances, as  documented in the user
>> agent's conformance statement.
>>
>> Conforms Basic
>>
>> XXVI. This [Definition: *identity signal* ] MUST be part of *primary user
>> interface* <http://www.w3.org/2006/WSC/drafts/rec/rewrite.html> during
>> usage modes which entail the presence of signaling to the user beyond only
>> presenting page content (should -> must)
>>
>> Conforms Basic
>>
>> XXXI User agents with a visual user interface  MUST show the  Identity
>> Signal in a consistent visual position. (should -> must)
>>
>> Conforms Basic
>>
>> XXXVIII ·  To inform the user about the party responsible for that
>>  information, the Issuer field's Organization attribute MUST be displayed in
>> the Identity Signal, or in secondary user interface that is available
>> through a consistent interaction with the Identity Signal. (or in secondary
>> added)
>>
>> Conforms Basic
>>
>> XLIV Where security context information is provided in both primary and
>> secondary interface, the  meaning of the presented information MUST be
>> consistent. Best practice will also avoid inconsistent presentation, such as
>> using identical or semantically similar icons for different information in
>> different places. (presentations moved out of must)
>>
>> Conforms Basic(no change)
>>
>> (should)
>> XLIX ·  An explanation of the information represented by the *TLS
>> indicator* <http://dl.dropbox.com/u/3356996/wsc-ui-diff-20100226.html>  ,
>> e.g., concerning the presence mixed content; (was “level”)
>>
>> Conforms Advanced(no change)
>>
>> LX The [ Definition : *TLS indicator*]  MUST be part of primary user
>> interface during usage modes which entail the presence of signaling to the
>> user beyond only presenting page content (should -> must)
>>
>> Conforms Basic
>>
>>
>>
>> From:        Mary Ellen Zurko/Westford/IBM@Lotus
>> To:        public-wsc-wg@w3.org
>> Date:        02/19/2010 03:16 PM
>> Subject:        updates to Google Chrome Implementation report
>> Sent by:        public-wsc-wg-request@w3.org
>> ------------------------------
>>
>>
>>
>> I've made the following changes, based on our last meeting, and on the
>> discussions Thomas and I had today:
>>
>> XLIII - Conforms Basic(redundant)
>> XLIV - Conforms Basic
>> XXIX - Does Not Conform Basic
>> XXX - Does Not Conform Basic
>> XXXVI - Conforms Basic
>> LXXVIII - Conforms Basic
>> XCVII - Conforms Basic
>>
>> and a bit of cleanup
>>
>> Ian and Thomas, at the very least, should verify they understand and agree
>> with each of these. I'll upload the changed Implemenation report.
>>
>>          Mez
>>
>>
>>
>