ACTION-363 Ian's WSC-XIT review

Here are my comments (which should satisfy ACTION-363)

Ian's comments on WSC-XIT editor's draft 28.11.07

5.3.1 is still too vague for my tastes. I.e. my understanding (and please
correct me if I'm wrong) is that even domain-validated cert providers have a
certification practice statement, and go through some audit before the root
is included in most browsers. The subject entity is authenticated by a
process that is audited and designed to establish acountability - they
validate the CN= field. Our current text says nothing about validating the
O=, L= field. It just says "the subject entity". I might be happier if it
specified that the entire subject entity were validated.

5.3.2 - all of the new terminology is killing me. I assume that a
domain-validated certificate qualifies as an attested certificate. Much like
we say e.g. EV-cert in the augmented cert section, can we say e.g. a
domain-validated cert in the attested? Also, we say that it is assumed that
subject information in an attested certificate is suitable for user display.
Do we really want to make that assumption about the O= part of the subject?
Or is this section meant to refer to the expensive but not EV certificates
that have been sold for a while? (High assurance, or whatever the buzzword
is?) This is much too confusing, and needs to be clarified.

5.3.3 - we say that after meeting some criteria, a ssc is called "proven",
but say nothing further here about what that implies. It seems sort of
strange that it's just left hanging here.

5.3.7 - finally, we say something about the benefits of being "proven". I
would prefer a reference in 5.3.3 to point to 5.3.7 so that, for those of us
who like to read non-linearly, we can actually figure out what the heck it
means to be proven.

5.5.1 change of security level - I find it a bit confusing how we introduce
this notion. Formost, for "attested" certificates, it seems like they are
given a "trusted" level, and then we validate that the cert is valid for the
URI, and then it can change to an "untrusted" level. The notion that
something is trusted before any validation occurs is a bit strange, and I
find this whole bit about change of security level due to validation failing
to be confusing. It seems to me that for something to be trusted, it should
have to pass the validation checks, rather than something being trusted and
then changing after validation is performed.

5.5.3 - You assume that certificate information is kept from prior
interactions. The whole bit about SSC treats key continuity as a MAY - and
yet here we require you to keep info about certs in history (or at least
about certificate status). Is this really something that we want to require
from browsers? What does it actually get us? Maybe I'm missing something,
but it seems that the only URIs which will have been strongly TLS protected
in the past are HTTPS URIs. If the user goes to one of these HTTPS URIs and
ends up in a non-strongly-protected state, this means they're getting an
invalid cert / cert not valid for the URI, which would be a change of
security level anyways under 5.5.1. (The only case I can think of where this
is different from 5.5.1 is if you used to have a cert with strong
encryption, but now get a cert and a transaction with weak encryption. But
this seems like it would be incredibly rare in practice, and I wonder if we
really gain anything in practice here.)

(Flipping the page) It also seems like we will cause huge problems for a
site if they ever decide to dump EV. Let's say that five years from now,
people decide that EV wasn't really worth it, they're not getting a ROI, and
they want to go back to a standard cert. We are going to punish them
severely for this.

6.1: Are we mandating that browsers show a non-lock icon (or its equivalent)
for HTTP sites, and take up space? Even though we only have SHOULD language
about the identity signal being present, we also say that the interactiopn
to access identity signal must be consistent. Let's take FF2 as an example.
You can click the lock, or you can go to Tools -> Page Info, and get some
information. For a non-HTTPS page, there's no lock to click, so although you
can still go to tools -> page info, the interaction is not entirely the
same, because one of the options (clicking the lock) isn't present. Would we
declare this non-conformant as a result? Sounds strange to me that, because
additional mechanisms are present in certain modes, you get a problem. It
seems to me that as long as one of the access mechanisms remain the same,
you should be fine.

6.1.2 - "During interactions with a Web page for which any of the resources
involved was retrived through a weakly TLS-protected transaction... must be
indistinguishable from one that would be shown for an unprotected HTTP
transaction, unless a change of security level has occurred." This seems
wrong on two counts - Let's say I got mixed content, and the top level page
provided an invalid cert. Under the current text, I will have had a change
of security level, so I can display whatever the heck I want? Secondly, even
though there was mixed content, I don't understand why a "page info" or
"security info" tab in secondary chrome can't give information about the
certificate, even though there may be mixed content. It should clearly not
be the same as the information presented for a valid transaction, but we
shouldn't say that the information cannot be presented at all. (I agree
that, to take IE7 as an example, I wouldn't want the little box next to the
URL bar to be saying "eBay" if there were mixed content, but on a secondary
more-info page, I don't see why we couldn't provide some information.)

6.1 again - I'm conufsed as to what is the identity signal. Let's take FF3,
where we have the little green box, plus the page info display. The little
green box seems like an identity signal to me, but is the secondary chrome
(page info) also considered to be a part of the identity signal, and subject
to the same constraints?

6.2 - Aaah, finally I have a better understanding of what the identity
signal is, because I understand what it is not now. It would be nice if
under 6.1 we could draw some of these distinctions.

6.3 - Still seems very odd to me given that we can't come up with a scoring
system we all agree would be a good example.

6.4.1 - If weak TLS is achieved, but no change of security level has
occurred... when is this ever the case? if someone types https://, that
implies expectation of strong tls under 5.5.4, but then they get weak and so
it's a change of security level. Can someone give me an example of when you
would wind up with weak TLS, but it *wouldn't* be a change of security
level? I'm having trouble coming up with one.

7. I still feel that this whole section is going to cause massive adoption
problems. If we do keep it in, I would love to see something like
"WSC-XIT/Transitional" that does not include these requirements (sort of
like XHTML 1.0/Strict and 1.0/Transitional...) Other than that, I think I've
raised most of my issues (including that SubjAltName needs to be factored
into matching)

8.1 - have we come to consensus on language around "commonly used or
intended" parts of UI?

8.1.2 again, confuses me as to "intended or commonly used" - what does it
actually mean in practice. We all have a good idea, a reader might not.

8.1.3 I don't think we should ban favicons in the location bar. I think we
should probably recommend against it, but Johnathan has given good cases
where it should not be a problem - i.e. the case where the seuciry
indicators are a totally different shape and size than the favicon.

8.2 - are we trying to move Passmark SiteSecure into the browser? Do we have
any good data that this is actually going to help, for instance in a MITM
attack? We're going to be adding complex interactions into a browser, and
it's not clear to me what all it helps. Or are we talking about petnames
here? The end goal of this section is not immediately clear to me.

8.3.2 still have issues with "install or execute software outside the
browser" as discussed in one of our recent calls ;-)

8.3.2 "Web user agents MUST prevent web content from overlaying chrome" -
are we talking about outer chrome here? It can get confusing - i.e. if you
have a frameset, an inner frame can have a scrollbar, but that scrollbar can
be overlapped by absolutely positioned floating elements in the outer frame.
Technically the scrollbar belongs to the inner frame, so maybe it's not
chrome, but I can see someone being confused. We might want to be more
specific? Or maybe I'm just paranoid about misinterpretations.

9.5 issues already noted

10.1 - kinda confusing. I think instead of "optional features of this
specification" we should say "optional features of this section" to make
clear we're talking about the optional parts of 10.1 and not the optional
parts of the spec as a whole.

10.2 - SBM - the name might be confusing. "Safe Browsing" is the name used
by Google for our anti-phishing and anti-malware protection. Although
Mozilla now calls it "Phishing Protection", there was a plugin for FF by
Google called Safe Browsing, and I'm just worried about confusion. (We also
say that toolbar includes safe browsing, etc). Is there any chance we could
pick a different name? Maybe "Banking Mode" or "Verified Site Mode" or
something like that, which better describes what's going on anyways?

11.1 - We seem to have switched to British english (dialogue?)