Yngve's wsc-xit review

Hello all,

Below is my comments/questions based on my own review of the WSC-xit  
document.

Other comments from Opera will be sent Monday.

-------

5.2 Relaxed certificate path validation

This is a bit on the vague side. A couple of examples would help
understanding the definition, as would using "revocation" instead of  
"status".

Also, the use elsewhere in the document should be clearer.

5.3 Certificates

Should this be before 5.2?

5.3.4: should this be removed? No specification, at least yet.

5.3.7 What should selfsigned certificates be indicated as after the
probation (and for that matter, how should they be presented during the
probation). (potential ISSUE?)

5.4:

"HTTP tansactions" -> "HTTP transactions"

"This definition implies that inline images, stylesheets, script content,
and frame content for a secure page need to be retrieved through strongly
TLS protected HTTP transactions in order for the overall page to be
considered TLS-secured."

Suggest rewrite to

"This definition implies that inline images, stylesheets, script content,
frame content, and all other content retrieved by the user agent for a
secure page need to be retrieved through strongly TLS protected HTTP
transactions in order for the overall page to be considered strongly
TLS-secured."

This will include applets and content requested by applets.

I would also prefer that similar language be added about AA sites.  
(potential ISSUE?)

Reference:  
http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-ev

Reference: "What is a secure page", recommendation #6/#16

5.5.1

    Need more precise language. It is too short now.

5.5.2 (from other reviewer) conditions for changed security level not
quite clear enough. Particularly the "terminates on a Web Site different"
point

5.5.3

", or a no-interactoin certificate;" -> "no-interaction" (although see  
5.3.4)

5.5.4

https always means TLS protection is expected. even if the user also
expects it to be done using a selfsigned cert.

6.1.2

What does " 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" mean? In which direction did the level change?

"Extended validation"-> "AA cert"?

6.2

RFC 2965 is the current cookie spec, but the Netscape "spec" is the  
de-facto one.

6.4.2

I think this could be embellished a little bit more, in particular about  
the constructed URL.


7.1

"For each certificate chain received from SiteB". Does this mean that the  
client will have to store the history of certificates it has seen for a  
given site?

(1) "currently valid": does that mean the client should perform a full  
certificate check, including revocation checks?

(2) Need clarification about what "same name" means

(4) What about ("OU") department match/non-match?

Potential problem: Some root CAs are using a root they bought from another  
(often defunct) company, but are in the process of moving to a new one.  
This will cause match failures. Can't do anything about that.

Should there be a way to detect Domain Validated certs? Usuaully "CN" ==  
"O".

What about hostname/domain matching?

I am not sure I like the implied ability to share data between sites with  
different names.

Also, we may need special handling of self-signed certificates

And: How do we defend against spoof roots? Either installed by the user  
(intentionally, or not), or by malware? Filtering proxies can be  
configured to present a generated certificate that permit the proxy to  
filter secure content.

7.3

(from internal comment) The actions listed and the text does not match.  
Actions listed as numbers, text assume "(a)", "(b)". Those are listed  
above as (a) and (b), but the mixing is confusing.


7.8

What if the user want to refurbish the UI?


9.2

Add "key" as alternative to padlock?

Should it be clarified as being written for deployment of TLS-protected  
services?

9.3

"and servers MUST NOT set credential cookies from secure servers that can  
be sent unencrypted" Should the be reordered? "and secure servers MUST NOT  
set credential cookies that can be sent unencrypted".

9.4

"redirect to an unsecure page and then redirect again to a secure page"  
Might want to make this clearer.


10

Primary problem of this is how to encourage the user to switch to the 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
********************************************************************

Received on Sunday, 9 December 2007 21:00:38 UTC