Re: Current state of editor's draft / IdentitySignal

It took me a while to work through the draft, so the comments might not be 
internally consistent (different ones might be on different "versions"). I 
just went in and read the whole thing, not restricting myself to a 
particular section. 



"There is a top-level Web page that is identified by a URI [ref-URI], and 
which is the set of content that controls what is communicated to the 
user, and what the user interacts with. "

So does that mean this specification would not apply to a rich client when 
the user interaction with content is all non webby and local, but that 
content was asynchronously replicated via web based means? That's 
obviously not a core type of scenario; I'm just trying to figure out the 
point and boundary of this particular part of the overview. 

"We could use this section to deprecate old versions of SSL. Shall we? "

Connect the dots for me - how is that in our charter? And what goal would 
would it support? 

"Instead of performing step (a) (2) of Basic Certificate Processing 
(section 6.1.3 of [ref-PKIX]; verification of validity date), the Web user 
agent verifies that the intersection of the validity period of all 
certificates in the path (including the entity certificate and trust 
anchor) is non-empty. If this intersection is empty, relaxed path 
validation fails."

I don't remember discussion on this ("not remembering" includes the 
possibility that it happened and I didn't understand it). What's the scoop 
with redefining path validity periods? Is the note at the end of 4.2 the 
key to it? [it's times like this that I'm reminded that reading standards, 
like reading Shakespeare, is not a natural act.]

And the pkix ref doesn't go anywhere. 

"Step (a) (3) (status verification) is skipped."

Since the pkix ref doesn't seem to work, can you say a bit about what this 
is? Is this CRL/OCSP? (that's what I'm guessing.) 

"This specification assumes that Web user agents establish that a trust 
root is [Definition: EV-qualified] through security-critical 
application-specific out-of-band mechanism. "

I'm always uncomfortable with "and magic happens here", without even a 
single understandable worked example. Is the understandable worked example 
embedding them in the user agent code? 

"Implementations MUST NOT consider a certificate that otherwise matches 
the definition as an Extended Validation Certificate if the certificate is 
marked as an no interaction certificate. "

I don't understand this, even after following the reference. 

"Implementations MUST NOT use Relaxed Path Validation if the trust anchor 
is EV-qualified. "

But they could use any other random form of validation, including a 
meaningless or null one? 

"This specification assumes that Web user agents establish that a trust 
root is [Definition: qualified to attest] through a security-critical 
out-of-band mechanism that is out of scope for this specification."

It's getting harder and harder for me to hold on to why this is supposed 
to be helpful with trust decisions. It seems a gap in the standard of 
standards writing that there's not an easy way to provide annotations or 
references to back up statements like this. It would certainly cut down on 
the overhead of dealing with comments (where you can provide references to 
examples or group decision making inline, and track them as the draft goes 
along). 

"Self-signed certificates are commonly used for appliances and web sites 
catering to small groups of users,"

They are also commonly used for inward facing functions in enclosed 
organizations such as enterprises. 

"[Definition: (normative) A self-signed certificate is called proven for a 
destination if it has been used for TLS-protected interactions with 
resources whose URIs share the same authority (domain) and port number for 
an extensive amount of time, the "probation time."] "

Is there any background on this, in SSH, or in experience? What has SSH 
used? I suppose it's clear it refers to a specific self signed 
certificate. So that if the self signer changed keys, it would be a new 
one, in a new probation time. 

"If a certificate that otherwise matches the definition for an Extended 
Validation Certificate bears the User Experience suppression extension, 
then it MUST NOT be considered as an Extended Validation Certificate. 
Instead, behavior specified for no interaction certificates MUST be 
applied. "

Which is what? or where? 

Section 5.1

"No claim is made about the effectiveness of these signals to counter 
impersonation attacks. "

>From my point of view, there are two reasons that this is still in 
charter:

1) We've agreed that there is a need for identity information in medium to 
high risk "read only" situations, and have not come up with any 
alternatives other than passive indicators for all such situations so far. 


2) It is unreasonable to assume that user agents will not display source 
or identity information for usability reasons, and that information can 
and will interact with security identity information. 

"User interactions to access this identity signal MUST be consistent 
across all Web interactions, including interactions during which the Web 
user agent has no trustworthy information about the [[ identity ]] of the 
Web site that a user interacts with. In this case, user agents SHOULD 
indicate that no information is available. "

Taken literally, this looks suspiciously like a software problem "no 
information is available" as opposed to an identity statement "the 
identity is unknown or anonymous".

"During interactions with a TLS-secured Web page for which the top-level 
resource has been retrieved through a strongly TLS-protected interaction 
that involves an attested certificate, the identity signal MUST include 
the Subject field's Organization attribute to inform the user about the 
owner of the Web page, and the Issuer field's Organization attribute to 
inform the user about the party responsible for that information. "

I could use references for organization attributes, what they are, and why 
they're useful to the user. I'm guessing that anyone steeped in PKIX 
thinks this is intuitively obvious to the casual observer, but it's not to 
me. 

Once I understand what's being said, I'm guessing I'm going to disagree. 
If there is a user specified nicname, then that's certainly much more 
meaningful (and to my mind secure against attacks that involve the user). 
If "include" is meant to cover that, because the nicname would be verified 
to be about something that includes those attributes, it wasn't clear to 
me on a first reading. 

"Whether the user has visited the site in the past."

I'd like to see this as a MUST, though I recognize my reasons for that are 
internally inconsistent. I believe this to be the most critical piece of 
information for the vast majority of successful attacks today. Yet in no 
scenario I've seen or believe in would a user get to this information "in 
time".  Why is it not a MUST? 

Section 7 could use a comment tracking potential inclusion of 
http://www.w3.org/2006/WSC/wiki/RobustSharedSecret as well. 

"This specification requires that web pages MUST NOT include trust 
indicating images such as padlocks in the web content."

This one is still a bit vague. Sites will certainly want to say they're 
trustworthy. And they're want to use images that indicate they are. It 
seems unreasonable to say they can't. What we seem to want to be saying is 
do not use trust indicators that are easily confused with security context 
indicators in deployed web user agents. 

"Cookies on unsecure connections are vulnerable to interception, and can 
be used for replay attacks even if they were set by a secure server, "

I'm on the fence on this whole one.  While that's true of cookies 
themselves, it's not necessarily true of all credentials today, or of the 
future. Is it possible to construct SAML that is not vulnerable this way? 
I can imagine tying cookie content to IP, which would require another 
level of attack (IP spoofing). Is there anything that could be done with 
IPSec, or are the levels all wrong? As a security person I like this 
recommendation, but practical experience shows that it's not followed, and 
I'd very much like us to understand the counter arguments. 

"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). "

Remind me why (I feel like I keep asking for that; see my comment about 
annotations above). 

"except for the absence of a possibly positive indicator "

That was not at all my reading, and everything we know says that's a 
terrible idea. I had read the following lines as requiring some sort of 
indicator at all times in primary UI if any indicator was ever shown in 
primary UI: 

"User interactions to access this identity signal MUST be consistent 
across all Web interactions, including interactions during which the Web 
user agent has no trustworthy information about the [[ identity ]] of the 
Web site that a user interacts with. In this case, user agents SHOULD 
indicate that no information is available. "

"Web user agents MUST make information about the [[ identity ]] of the Web 
site that a user interacts with available. 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. Otherwise, it MUST at least be available through 
secondary user interface. Note that there may be usage modes during which 
this requirement does not apply: For example, a Web browser which is 
interactively switched into a no-chrome, full-screen presentation mode 
need not preserve any security indicators in primary user interface. "


          Mez