Re: clarifications needed re safe form editor cert matching algorithm

So where are we on this extensive thread (that I have now caught up on)? 
In particular, Ian, what would be a specific straw proposal for your pov? 
We have a section for authoring and deployment best practices; we can put 
in recommendations against practices that create habituation that 
undermines the web user agent trust indicators. And other folks (Serge, 
Yngve, Thomas), what are examples of additional or counter proposals?

I love seeing the extensive discussion of the impacts of what we're 
considering. But I for one get lost in the trees by the end of a 
discussion, and need to see some example straw proposals to understand 
what might be the most appropriate next steps. 
        Mez




From:
"Ian Fette" <ifette@google.com>
To:
"Serge Egelman" <egelman@cs.cmu.edu>
Cc:
yngve@opera.com, "Johnathan Nightingale" <johnath@mozilla.com>, "W3C WSC 
Public" <public-wsc-wg@w3.org>
Date:
10/12/2007 03:27 PM
Subject:
Re: clarifications needed re safe form editor cert matching algorithm



If there were a way for the cert owner to express that they intended that 
cert to be used on a different CN (subdomain / whatever) then I would be 
all for it. There is such a way, and it's called Certificate Subject Alt 
Name. The fact that companies are too cheap to spend $60 at Godaddy for a 
6-in-1 cert isn't really sufficient motivation for me to say "let's go 
ahead and drastically diverge from spec/common practice". (As a note, I 
originally thought this was a good idea a few months ago, I think I even 
brought it up with Johnathan over drinks at one point, but now having 
thought about it I'm seeing a large number of downsides and very few 
upsides, with the potential exception of www=hostname.) The reason I don't 
want to treat certs differently is that the cert is expressing the 
preference of the server / site owner. The owner purchased a cert for a 
particular (set) of CNs. If they wanted to specify alternate CNs, they 
could have done so for $60 - $20(price of normal cert) = $40. [prices 
based off of godaddy, sorry Phil.] I'm not really comfortable divining 
intentions as to why a company chose not to spend that extra $40 - maybe 
they were cheap, maybe they didn't actually want to extend trust to all 
their subdomains, I have no way of knowing, except for looking at the CN 
and Subject Alt Name extension. I just don't see the upside in the general 
case - I see it for www vs hostname, but not beyond that. I don't think 
any of us have good numbers for how common the error is beyond that (not 
just anecdotes, but numbers), and given that I'm very uneasy. 


On 10/12/07, Serge Egelman <egelman@cs.cmu.edu> wrote:
Given that the attestation for a non-EV cert is control over the domain,
this still applies to subdomains.  So I'm not sure why all low-grade
certs shouldn't use wildcards (other than more profit for CAs).  Why 
shouldn't we just treat them this way with regard to which warnings we 
show?

Granted, I agree with you guys about the theoretical problems.  The
issue is weighing these against being pragmatic.  We will not be able to 
create effective warnings if we only consider "perfect" situations.  We
need to consider what is actually happening.

serge

Thomas Roessler wrote:
> On 2007-10-12 10:30:50 -0700, Ian Fette wrote: 
>
>> LOL... all I'm saying is this. For the case of www vs bare
>> hostname, I can see this being common enough to warrant
>> investigation. For the other cases, I see a lot of risk in terms 
>> of opening up new attack vectors, changing defaults, breaking
>> standards etc, but I'm not sure I really see the benefit.
>
> Considering that the "real" fix for the problem is a wildcard cert, 
> I'm leaning toward agreeing with you on this one, my prior remark
> nonwithstanding.
>

--
/*
Serge Egelman

PhD Candidate
Vice President for External Affairs, Graduate Student Assembly 
Carnegie Mellon University

Legislative Concerns Chair
National Association of Graduate-Professional Students
*/

Received on Tuesday, 30 October 2007 15:29:22 UTC