Re: Opera's wsc-xit review comments

These are super good Ynvgve; please thank your colleagues for taking the 
time. 

As with your own comments, please turn the ones that should be acted on 
into Issues. 

          Mez





From:
"Yngve Nysaeter Pettersen" <yngve@opera.com>
To:
"public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
Date:
12/10/2007 12:24 PM
Subject:
Opera's wsc-xit review comments




Here are the comments/questions from other reviewers in Opera.

-------

5.1

What about TLS-connections that are neither weak nor strong, like expired
certificates?

5.5.2

What exactly is a redirection "chain"? A simple redirect, or more, how
many?

5.3.3:

"CA root certificates are generally self-signed, and their inclusion in
the rootstores of user agents is based on out of band methods to ensure
their authensity."

It is possible for an organization to accomplish the same for internal
purposes, by distributing the certificates by courier or other secure
means to each server and client. This method is typically used by
government organizations when relying on an outside CA is not regarded as
sufficiently secure. The quality of such certificates is only dependent on
the internal procedures in the organization itself. In principle, an
organization is the ultimate authority to attest certificates for its own
use. This is different from the situation where there is no secure
out-of-band connection to the clients.


5.5

When does a change of security level happen, on all (AND) the points  or
any one (OR) of them? If AND, does this mean that https->http->https on
the same domain is not a change of security level? If OR, does this mean
that a common redirection chain when paying by credit card https (form
submit target)->https (please wait, automatic redirect after 20
seconds)->https (check order status)->https (failure or success page)
induces a change of security level?

Does change of security level only occur for the top level page, or also
for inlines?

6.1.2:

If the user agent is to display a logotype, then the inclusion of a
logotype in the certificate should be MANDATORY. Otherwise, the public may
get the impression that certificates with logotypes are somehow more
reliable than those without.

6.4

What is supposed to be shown in the secondary chrome on weak and/or
non-strong TLS-connections? All the errors, some, at least one, generic
message?

7.1

If the history match uses certificates only, that means it is open to
spoofs where alternate names of the certificate is being used to get it
accepted, and an alternate name is a spoof. Shouldn't the domain name also
play a role in matching history with the current address? E.g.
useonceonly.com to accept a certificate, and then hotmai1.com as an
alternate name.

Does the association algorithm in section 7.1 also apply to 5.5.3, or is
5.5.3 about a resource only as it states? Wouldn't 5.5.3 be better talking
about a domain, not a resource, nor a section of domains as in section 
7.1?

7.3

Section 7.3 is somewhat confusing. Example 1 gives options 1. and 2., but
the text talks about options (a), (b), (aa) and (bb).

Section 7.3 assumes that the user agent is capable of searching. A bank
could easily supply a tool to communicate with the bank only, and not
allow searching on the wide web, this tool would then not be capable of
becoming compliant. Requiring that all user agents support searching the
wide web is an unnecessary constraint, IMHO.

9.4

Section 9.4 will most likely never carry home. Redirects from e.g.
opera.com to www.opera.com are very common. Demanding that web authors
update all sites that redirect to www.opera.com whenever www.opera.com
receives an overhaul duplicates work, and might not even be feasible.
http://opera.com/->http://www.opera.com/->https://www.opera.com/secure
should be allowed, while
http://www.opera.com/->http://www.opera.com/secure->
https://www.opera.com/secure
should not.

10.2

It is important that Safe Browsing Mode is visually distinct from other
usage modes in an area which web pages do not have access to, even in
non-Safe Browsing Mode.




--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer                                 Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************