RE: Text change for wsc-ui Petnames

Thomas Roessler [mailto:tlr@w3.org] wrote:
> On 2008-09-17 17:29:12 +0000, Close, Tyler J. wrote:
>
> So, in the case of a binding to a site that has shown a
> pinned self-signed certificate, the petname is shown when:
>
> - the destination to which the petname was bound is navigated to, AND
>
> - a certificate pinned to the destination OR a domain validated
>   certificate is shown
>
> ... and the change that you propose would actually only
> affect the DV (and better) case, by dumping the association
> with wildcards that's currently in there.

Correct. I think the above description can be simplified by making reference to the wsc-ui concept of a "TLS-secured page", which already combines pinned self-signed with validated. So:

For TLS-secured pages, the shown petname is the one bound to the site's base domain.

> I.e., the scope of petnames would only ever shrink if we
> adopted your change.

Dropping the validated certificate information reduces the number of ways in which a petname can be associated with a site. However, using the "base domain" concept instead actually increases the number of hostnames to which a petname is bound. You can think of this as binding the petname to a wildcard constructed from the site's base domain.

> > These always used the hostname from the page's URL. That's
> unchanged
> > in the new proposal. Obviously we can't trust information
> taken from a
> > self-signed certificate.  We can only trust the binding between a
> > hostname and a certificate that the user specified when pinning the
> > certificate. It's the bound hostname that we key off of,
> not anything
> > contained in the certificate.
>
> Right.
>
> Apologies for the misunderstanding.
>
> The remaining question is then, why do you propose using the
> "base domain" instead of the domain name?

A number of reasons:

1. To get the effect of wildcards without having to access them. With this implementation, you can petname signon.example.org and have that petname show up at service25.example.org, etc, as is a common deployment at many online banks.

2. To more accurately reflect the actual security boundary enforced by the browser. The cross-frame scripting policy is the one that controls the granularity of what can be authenticated in a web browser. The presentation of this security boundary should directly key off this scripting policy.

--Tyler

Received on Wednesday, 17 September 2008 18:03:35 UTC