[HTTPS-Everywhere] what does HTTPS-Everywhere consider a "valid" X.509 certificate? [was: Re: Custom rules]

[Mike Perry]

Thus spake Daniel Kahn Gillmor (dkg at fifthhorseman.net):

> On 10/15/2010 03:50 PM, Chris Palmer wrote:
> >> <ruleset name="Reddit" match-cn="no" trusted="yes">
>
> > This would allow any server with a valid, trusted-CA-issued certificate
> > issued to any subject to authenticate as reddit.com. That is badder than the
> > status quo.

How about match_cn and valid_ca? Dashes will probably make the
attributes a pain to access from JS XML notation. valid_ca will mean
"Is in the current list of CAs in all supported versions of Firefox".

> while i disagree with the original proposal, i don't think the intention
> was to have https-everywhere actually set certificate exceptions in the
> browser.
> 
> I believe the OP wanted to have some config knobs the user could
> twiddle: "use https-everywhere rules which may encourage visiting sites
> with non-matching CNs"  and "use https-everywhere rules that encourage
> visiting sites whose certs do not validate with the stock default CAs"
> 
> if the cert doesn't validate (for however the user defines validation)
> https-everywhere wouldn't somehow override that.
> 
> anyway, it's not a proposal i support, but it's not as bad as the
> variant you describe, which would indeed be downright awful.

I personally see no problems with this, actually. It doesn't make us
have to do anything other than what we already do. Right now, we
refuse all rules that don't have domains with matching CNs, and we
refuse all rules that would require the installation of a custom CA in
*some* supported Firefox version.

Having two flags to represent this distinction, and having all rules
with valid_ca="false" and matches_cn="false" off by default with a UI
option to turn them on seems like a great idea to me. That way, users
that have added the needed CAs and/or granted the necessary security
exceptions themselves can then enable these rules.

We likely won't be implementing this ourselves any time soon, because
there's still a lot of usability and performance work that should be
done first, but unless Peter or Seth strongly object, I'd gladly merge
any patch to do this. 

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101015/a2ef3c2a/attachment.sig>