Re: ACTION-401: Larry as Lo-Fi prototype for 6.1.1

Incidentally, I think this works as a prototype for 6.1.2 as well:

> Information displayed in the identity signal MUST be derived from  
> attested certificates, from user agent state, or be otherwise  
> authenticated. Web user agents MUST NOT use information as part of  
> the [[identity signal]]  that is taken from unauthenticated or  
> untrusted sources.

Yep.  In the case of a site with an unattested, but explicitly trusted  
by the user, certificate, Larry looks like this:

Note the text "You have added a security exception for this site."   
Again, this does not show up by default, only when a (self-signed,  
domain mismatched, etc) cert has been explicitly trusted.

> 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 augmented assurance certificate, the  
> identity signal MUST include the Subject field's Organization  
> attribute to inform the user about the owner of the Web page.

With EV certs, this is done (see screen caps previous email in this  
thread).

> 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 atttested certificate, an applicable  
> domain name label retrieved from the subject's Common Name attribute  
> or from a subjectAltName extension MUST be displayed.

Yep.

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

Yep.  (Again, for examples, see last email).

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

Yep - mixed content, weak encryption - these things give the standard  
http ui.

> For Web user agents that use a visual user interface capable of  
> displaying bitmap graphics, 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 extended  
> validation certificate, the identity signal [[MAY | SHOULD]] include  
> display of an [[issuer | community | subject]] logotype that is  
> embedded in the certificate using the logotype extension [RFC3709].

We do not display logotypes.  This is a MAY/SHOULD requirement though,  
so I don't think it's fatal.

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

Moot point, but we trivially comply.

Cheers,

Johnathan

On 29-Feb-08, at 2:32 PM, Johnathan Nightingale wrote:

> Mez asked in IRC today if I would consider Firefox 3 to be an  
> example of an implementation of the identity signal outlined in  
> section 6.1.1, and if so, would I screencap it and show how it  
> fulfills the requirements there.
>
> The text of the section is:
>
> -- SNIP --
> This section is normative. Examples are informational.
>
> 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.
>
> 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.
>
> User agents with a visual user interface that make the identity  
> signal available in primary user interface SHOULD do so in a  
> consistent visual position.
> -- END --
>
> Here is a screenshot of Firefox 3 beta 4 on Mac, showing the  
> Identity UI:
>
> <pastedGraphic.png>
>
>
> "Web user agents MUST make information about the [[identity]] of the  
> Web site that a user interacts with available."
>
> Firefox 3 has a UI element (the "site button") at the left of the  
> location bar in primary chrome, which makes identity information  
> 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."
>
> The launch point is in primary chrome, not clear if that counts as  
> the signal being in primary or secondary, but it complies with the  
> MUST and maybe the SHOULD.
>
> "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."
>
> The site button behaves in this way.  Sites that present no identity  
> information display:
>
> <pastedGraphic.png>
>
>
> "User agents with a visual user interface that make the identity  
> signal available in primary user interface SHOULD do so in a  
> consistent visual position."
>
> The site button appears in a consistent location, and is available  
> at all times (it does not disappear on non-SSL sites like older  
> padlock implementations in Firefox).
>
> I believe this meets the requirement, but if people require  
> additional details, I recommend http://www.mozilla.com/en-US/firefox/all-beta.html
>
> Cheers,
>
> Johnathan
>
> ---
> Johnathan Nightingale
> Human Shield
> johnath@mozilla.com
>
>
>

---
Johnathan Nightingale
Human Shield
johnath@mozilla.com