Mez' review of wsc-xit

My review, as a participant in WSC. Like everyone else, I will turn my 
review into Issues to be tracked after I see what, if any, clarifying 
discussion comes up. 


SOTD

Typo - double the's

"with references to input documents that are available from the the 
Working Group's Wiki,"


4.1 Overview

"This specification makes no specific assumption about the content with 
which the user interacts, except for one: There is a top-level Web page 
that is identified by a URI [RFC3986]. This Web page might be an HTML 
frameset, an application running on top of a proprietary run-time 
environment, or a document in a format interpreted by plug-ins or external 
systems served as part of a Web interaction. The page's behavior might be 
determined by scripting, stylesheets, and other mechanisms."

And yet, I believe some of our recommendations (for example, in 
Robustness) become ineffective in the case of "a document in a format 
interpreted by plug-ins or external systems served as part of a Web 
interaction. ", since that executes code outside of the web user agent, 
which the previous paragraph defined. At the least, we should say that. 

4.2.1

Typo ont -> not

"or error pages that take the place of a Web page that could ont be 
retrieved."

5.3.1

"designed to establish accountability in accordance with an industry 
standard set of criteria"

Is "industry standard" too constraining? What about government standards, 
and standard standards? Do we really mean to leave them out? I wouldn't, 
so if we do, I'd like to know why?

"It is further assumed that Issuer and Subject information included in 
Augmented Assurance Certificates is valid, and intended to be displayed to 
users."

What does valid mean in this context? Does it refer to checking the chain 
(and URL), or something else? 

"intended to be displayed to users" is interesting, given our charter. 
Does this really mean the low bar it implies; strings that are intended 
for human consumption (but no particular understanding)? 

5.3.4 

[ref-UESOID]  goes nowhere. I'm not able to intelligently review that 
definition, or any of the normative language that makes use of it.

5.3.7

"However, Web user agents MUST NOT conclude that any assertions that may 
be included with the certificate are valid."

Why not, and how does that apply to usefully trusting self signed certs? I 
imagine there are some assertions that would be obviously a bad idea to 
trust in an self signed cert, but all assertions, past, present and 
future? How do we know that's a good idea?

5.5

This section totally needs a reference to 6.4.1. All the items that 
referred to change of security level before that, I kept trying to 
visualize or imagine what the requirements around that user experience 
were (see my comment below on CoSL). Even better, move 6.4 into 5.5. I 
cannot figure out why it's way down there, and I think most readers will 
agree with me. 

5.5.3

"Web user agents that have found a resource strongly TLS protected during 
past interactions MUST consider an interaction with the same resource as a 
change of security level if that interaction is not strongly TLS protected
. "

I believe the "during past interactions" to be stronger than we intend. It 
seems to include a site that used to be strongly TLS protected long ago, 
changed over to a self signed cert, and even after the probation period. I 
would argue that a new pattern has been established by then, therefore 
there is no change in security level. 

5.5.4

"When an user manually enters a https scheme URL, "

That seems to leave out voice input. Perhaps it should say When a user 
explicitly inputs an https scheme url ... 

6.1.1

"This [Definition: [[identity signal]] ] SHOULD be part of primary user 
interface during usage modes which entail the presence of signalling to 
the user that is different from solely page content. "

This wording confused me. I suggest changing the ending to "during usage 
modes whic entail the presence of signally to the user beyond only page 
content".

I would like to propose adding, in that same paragraph, before the 
sentence starting with "Note...", 

"The identity signal MUST be part of primary user interface when any 
identity sources that are from unauthenticated or untrusted sources are 
(also) part of the primary user interface. These sources include URLs."

6.1.2

"The Issuer field's Organization attribute MUST be displayed to inform the 
user about the party responsible for that information."

I'm not (yet) buying this as a MUST. MAY, easily. MUST in secondary user 
interface, you bet. Would some state, as concisely as possible, the 
reasoning behind the MUST? "Just" to inform the user about the party 
responsible for that information seems very much like "additional security 
context information". Nice to have, potentially useful. 

"During interactions with a Web page for which any of the resources 
involved was retrieved through a weakly TLS-protected transaction, the 
identity signal must be indistinguishable from one that would be shown for 
an unprotected HTTP transaction, unless a change of security level has 
occured."

This seems to be the first place in the document that implies anything 
about what "change of security level" (CoSL) should/must be like from a 
user experience (UX). And the implication is, at the least, that it is 
_not_ the same as the UX for weakly TLS-protected web pages. We need to be 
more explicit about the UX for CoSL; at least about this level assumption. 
A straw-cat crack at it would be adding the following to 5.5:

A web user agent that displays any security context information in primary 
user interface MUST display a different form of security context 
information for change of security level and weakly TLS-protected 
transactions. 

"the identity signal [[MAY | SHOULD]] include display of an [[issuer | 
community | subject]] logotype that is embedded in the certificate using 
the logotype extension [RFC3709]."

I've lost track of where we are on this one. My vote is SHOULD for subject 
and MAY for issuer and community (which I believe to be in line with the 
lo fi prototype Phil sent out recently, coincidentally). 

"During interactions with pages that were (all or in part) retrieved 
through weakly TLS-protected interactions, Web user agents MUST NOT 
display any logotypes derived from certificates."

I would like to see this cover all of identity signal, since identity 
signal is derived from attested certificates. A straw proposal is to 
change that line to: 
During interactions with pages that were (all or in part) retrieved 
through weakly TLS-protected interactions, Web user agents MUST NOT 
display any identity signal content derived from certificates.

6.2

"This section is applicable to secondary chrome alone and "

"Web user agents MUST provide additional security context information as 
described in this section through one or more user-accessible information 
sources. These information sources can be implemented in either primary or 
secondary user interface. "

6.2 is internally inconsistent on the targeted user interface of this 
section. My proposal is to change the comment text to:
When security context information is in secondary user interface it ... 

An addition to the MUST list:
The [petname] for the web site. 

"Whether the user has visited the site in the past. 
Whether the user has shown credentials to this site. 
Whether the user has stored credentials for this site. "
For precision, should these be scoped to the web user agent in question? 
Or is that overly limiting? I lean towards the former. 

"Whether the site content was authenticated. "
Site content? So this does NOT mean SSL authentication of the site/server?

Proposals for the MAY section. If any of these are impossible, tell me, 
I'd like to strike them: 
When the user most recently visited the site in the past. 
When the user first visited the site in the past. 
How often the user visited the site in the past. 

6.3

"The user agent MUST reduce the state of all security context information 
made available to a single value. "

I'm not convinced of the MUST. The thinking in this section has not taken 
into account the richness and diversity of identity information, vs. 
security quality/protection information. If there was a proposal for a way 
to delineate security quality/protection information, or remove identity 
identification data from this value, I might go with it. But I can't come 
up with that myself at this moment. So I propose instead that this be a 
SHOULD. This would also imply a SHOULD for the following: 
"The user agent MUST make the security context information value available 
to the end user, in either primary or secondary chrome"

We still need a lo fi prototype of this. We can't keep this in the 
recommendation without at least an example we've all looked at and had 
"expert" review of. It's too vague to make it all the way to 
recommendation otherwise (remember the whole coding step thing). 

6.4.2

I need some examples of this; a use case where it's a good idea, and one 
where it's bad. And a lo fi prototype of the former. I can't recall why 
this section is here at all. 

7.1

"if they are both installed as trusted certificate chain roots identified 
by the same name in the user agent's presentation to the user."
This seems under specified. Presentation of what, where? primary UI? 
secondary? what if there are two presentations in those two areas? I also 
need examples, where they match and where they don't, with some underlying 
certificate data. 

Proposed change:
"if they are both installed as trusted certificate chain roots identified 
by the same name in the user agent's presentation of [additional security 
context information] to the user."

"If both SiteA's and SiteB's certificates have the same value for the 
Subject field's Common Name (CN) attribute, there is a match; otherwise, 
continue with the matching algorithm. "
I'm struggling to understand why this makes sense. I don't remember web 
user agents (wua's) displaying CN to me in normal or error conditions. So 
I don't see why this makes sense as matching wua displays (examples would 
disprove my memory). And I don't remember CAs promising not to "reuse" CNs 
(but maybe they do?). So it doesn't make sense from that perspective 
either. And I think I read several versions in the wiki, but don't 
remember an explanation of this there. Please explain. 

"If both SiteA's and SiteB's certificates have the same values for all of 
the "O", "L", "ST" and "C" attributes of the Subject field, there is a 
match; otherwise, continue with the matching algorithm. "
OK, the conversation the other day was good, and the explanation later in 
the section is helpful. But I don't remember what these all are. Can you 
provide an easy to follow reference to decrypt them? O is organization. 
Drawing a blank on the other 3. 

"This matching algorithm needs to be reconciled with PKIX, and with 
material elsewhere in this specification. See ISSUE-121 for a more 
detailed discussion of some of these aspects."
I don't see why. It's doing something different. I understand the "don't 
invent" point of view. I understand the concern about defining a matching 
algorithm for something new, in terms of missing problems, resources, etc. 
But it looks to me like PKIX can't solve this either. 

"Both the first check in the matching algorithm and the second to last, 
which compares the "CN" attributes of the certificates' subject fields, 
provide a means to transparently update an organization's name and 
address. "
This section would benefit from simplification, at least of the MUSTs. Can 
we do without that feature, and is that a useful simplification? I think 
so. It doesn't seem to happen that often. I realize any mismatch between 
user expectations/abilities and tool model may degrade its security. But 
I'd still like to argue this aspect is only a SHOULD. 

"The above paragraph makes assumptions about CA practices. See ISSUE-122."
What assumptions? (issue-222 provides no further help with that question.) 
Nothing jumped out to me. 

7.2

This section seems overly prescriptive. The very first "MUST NOT" covers 
it. The rest can be removed, and given as examples of a (good) conforming 
interface. If they're getting at something additional that needs to be 
said, it needs to be abstracted up a level. They're also pretty close to 
CoSL, but not enough, I fear, for further useful simplification. 

7.3

"via an attention key, or a toolbar button, or in some other way"
Since I think we should do everything we can (at this stage) to tighten up 
this section, we should remove this small piece of text. 

"aa) the user can navigate to a known preferred search engine,"
This is not as abstract as it could be (and I think should be). This 
interaction is for the user to find the site they are looking for, in a 
trustworthy fashion, given the information they have easily at hand. Using 
a known preferred search engine is one way (perhaps the only way we can 
think of right now), but we shouldn't preclude other ways. I propose the 
change:
aa) the user can find the site they intended to go to in a trustworthy 
fashion 

"If the user choses interaction (aa), the user agent MUST navigate to the 
user's preferred search engine."
This is gratuitous; it just says, do what you told the user you'd do. It 
should be removed. 

"the user agent MUST search the database of existing relationships to find 
any name similar to the newly chosen one. If any matches are found, the 
user is notified of the collisions and given the opportunity to instead 
navigate to the corresponding web site. If no matches are found, the user 
agent updates its database of stored relationships and enables the text 
entry tool."
The similar concept is not concrete enough for standards language. Only if 
the two strings were not close in length, none of the characters anywhere 
were within one or two of the others anywhere, or sounded anything like 
them, or looked anything like them, could I be sure they weren't similar. 
My proposal for fixing that is shallow; I'd welcome something better 
thought out:
"the user agent MUST search the database of existing relationships to find 
any name identical to the newly chosen one. It MAY also search for any 
that are similar enough to be confused with each other by the user. If any 
matches are found, the user is notified of the collisions and given the 
opportunity to instead navigate to one of the corresponding web sites. If 
no matches are found, the user agent updates its database of stored 
relationships and enables the text entry tool."

"If the user choses interaction (b), the user agent must provide a message 
which communicates identity information "
7.4 needs to refer to this message. I allow it, I propose the following 
change:
"If the user choses interaction (b), the user agent MUST provide a 
bootstrap message which communicates identity information ..."

7.4

Parts of the first paragraph seem to belong in 7.3. But I can't quite 
propose the change concretely, because I don't understand part of that 
part. 

"The quoted text in the bootstrap message, the part of the message after 
"belongs to", MUST be distinguished from the rest of the static text. "
This is either under or over specified. What's the point of being 
distinguished? Whatever it is, that point should be substituted in for the 
word "distinguished". 

"Definition: petname], MUST be the only identifier used by the editor bar 
user interface to refer to the named site. "
I propose, after this,
A means for the user to get to the secondary chrome security context 
information MAY be provided in the editor bar user interface. 

"Each hyperlink in the list provided when the user selects the first 
option in the first message of the bootstrap interaction MUST use the 
petname as the hypertext. "
You gotta put some labels/definitions on those messages; I went into brain 
meltdown right about here. 
You mean the search for something part of the bootstrap message? That 
seems wrong; the best practice there is a call out to a preferred search 
engine. 
The message before that is "the bootstrap message" too? Come up with two 
names for them. 

"This list MUST also be accessible to the user via a "Contacts" option. "
I have no idea what this is. And it seems like micromanaging for no good 
reason I can see. Remove it (or phrase it in a more useful way with a 
MAY). 

7.5

This section can benefit from some tightening up of the text and 
abstraction of the concepts. Here's my proposal:

The text entry tool supports user entry of a new text string and selection 
of a previously entered text string. The editor MUST provide an indication 
of which of the two actions is being taken. A user action to select a text 
string submitted to some other site MAY be offered. The user action to 
select a text string previously submitted to the current site MUST involve 
fewer manual and cognitive steps than the interaction to select a text 
string previously submitted to some other site. For example, text strings 
previously submitted to the current site could be displayed in a main menu 
and other text strings displayed in a sub menu. Representation of such 
strings MUST differentiate between the two types (those submitted to the 
current site, and all others). 

Selection and submission mechanisms MUST require explicit action by the 
user. Transmission of a text string in a particular request represents 
user consent for use of that text string for the purpose of that request. 

The safe editor bar MUST be the only form filling feature of the user 
agent. A competing form filling feature would undermine the security 
features of the interaction created by the editor bar.

7.6

Assuming it's possible, it would be far better if the user agent continue 
to be smart about password field display. This would reduce the burden of 
the editor bar, and the ability to mark strings for masking would be a 
MAY. The display name of each string input to a site in a password field 
could be "[petname] password [n]" where n provides a sequence number. The 
feature that allows for masking of other strings would also allow for 
renaming of these defaults. Here's a crack at the rewrite of the 2nd 
pargraph:

Strings in the text entry tool history that were input into password 
fields MUST have a meaningful and unique [display name]. One (english) 
example is "[site petname] password [n]", where "n" provides a sequence 
number in case of multiple entries. Wherever a text string would be 
displayed by the editor bar, the provided display name MUST be shown in 
its place, as well as an indication that the displayed text is a display 
name. Users SHOULD be provided with an interaction to change display 
names, and MAY be provided with a mechanism to give other sensitive 
strings display names. 

I left out the auto completion part because I don't buy it; I think that 
part is still up for grabs (some simple user testing should show). It can 
obviously be recommended by the examples, prototypes, and code that come 
along as we work on the spec. The last line in that paragraph didn't add 
anything; the editor bar would not work at all if that line was not 
followed. 

7.7

The first paragraph should be more abstract and encompassing. Here's my 
proposal. 

Each change to the editor bar history MUST be explicitly made by the user. 
A web site MUST NOT be able to make any changes to or gather any 
information about the contents of the editor bar history. 

Tightening up the third paragraph:

The editor bar MUST provide a means for a user to remove a site and all 
its history completely from the editor bar tool. 

7.8

Need to be merged into 8.2. 8.2 says MAY; this one says MUST. And there 
are a number of other details. But either way, "there can be only one" 
section on this single concept, and it belongs in section 8 (referencing 
items in this section, as needed). 

7.9 

This section is redundant with other sections, and doesn't belong here. It 
should be removed. 

Anything that isn't redundant should be moved. 

I'm still not buying the notification stuff. MAY at best. 

9.1

"trust indicating images" is way too general. Sites want to look 
trustworthy. If only behaving sites don't look trustworthy, only malicious 
sites will. My proposal:

Web pages MUST NOT include images used by widely deployed web user agents 
to represent specific security context states or values. For example, 
padlocks in the web content.

9.2

This sentence is redundant with 9.1 and should be removed:

"This link MUST NOT carry a padlock along with it."

9.3

"If a web site requires secure login, then all sensitive transactions and 
presentation based on the user's credentials, as well as the service 
provided credential token itself MUST be protected by the same level of 
security. "

I would support a SHOULD for this instead. Other security mechanisms may 
be in play (IPSEC) that make this unnecessary. 

9.4

"Web Sites that require their users to be redirected from an unsecure web 
page to a secure web page MUST do it as a single step rather than 
multi-step (redirect to an unsecure page and then redirect again to a 
secure page). This specification recommends that the web page MUST use 
direct links to a secure page rather than using redirects."

I'm confused. Isn't the first line in conflict with the second? Doesn't it 
say you can do something that the second line says you cannot?

10.2

"Use of self-signed certificates MUST be considered cause for a change of 
security level."
This seems wrongly restrictive to me. If they're installed trust roots 
that are configured for this mode, that's fine. And it raises the 
question; every single time the user makes a page transition? (follows a 
link or types something in). I would remove this. 

11.1

The spec should allow for the configuration of a mode where the truly 
paranoid can get that notification in these circumstances. 

11.2 

I'm not getting what this is trying to say. That it relies on the web user 
agent (and platform) being trustworthy?