Skip to Content.
Sympa Menu

cacert-policy - Re: New Roots: Hierarchical Structure vs. Most Browsers aka Theory vs. Practice

Subject: Policy-Discussion

List archive

Re: New Roots: Hierarchical Structure vs. Most Browsers aka Theory vs. Practice


Chronological Thread 
  • From: Michael Tänzer <michael.taenzer AT cacert.org>
  • To: cacert-policy AT lists.cacert.org
  • Subject: Re: New Roots: Hierarchical Structure vs. Most Browsers aka Theory vs. Practice
  • Date: Wed, 31 Mar 2010 04:07:23 +0200
  • Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none
  • Openpgp: id=9940BEF1

Daniel Black schrieb:
> On Tuesday 30 March 2010 21:38:52 Michael Tänzer wrote:
>> Yes this is annoying and yes this is an ugly workaround but if we don't
>> we'll have confused users (there really are quite some cases of security
>> aware users who run into problems only including our current class3
>> right now) and probably more points against us if it comes to inclusion
>> in the browsers.
> 
> I'd assume most CAs are issuing off subroots so I'm not sure this makes a 
> difference for those deploying server side or as a s/mine sender.

Server side should be no problem, true.

> Every decision is a tradeoff which just makes it harder.
> 
> In short my assessment of this is:
> 1. good gains for end users who want to trust/not trust specific roots
> 2. harder barrier to entry for end users who don't care ("what I need to 
> add 
> two roots?" at least until root inclusion occurs)

Or they're going like "oh I have to click two buttons instead of one, oh
well, still better than layer ads, clicking through licenses, waiting
because you don't have a premium account for downloading something or
flash advertisements with sound".

The risk I'm seeing here is that apart from Mozilla there might be other
browser vendors who might consider adding CAcert to their trusted roots
once we have got the audit done. But some may choose that they only want
the class3 type of certs to be trusted so they need to exclude the
members subroot somehow. If they have those quirks in their
implementation they're not going to say "CAcert's roots don't get
properly recognised in our browser, let's fix our code", but simply
ignore us.

Apart from that issuing under two roots makes a clear statement how
thorough the validation in the several subroots is.


> I'm tempted to say that #2 is still the dominate factor here for me. There 
> is 
> a decision for educated users to choose the software that supports their 
> need. 
> Its a browser problem, however unwilling, to support the end user's choice. 
> To 
> redesign our root structure for 30 years around the current implementation 
> is 
> a little counter intuitive. Perhaps the whole CNNIC root issue will drive 
> users to drive browsers to do better.

At least until the inclusion in all mainstream browsers CAcert will be
severely biased to a more security interested user base. After the
inclusion the user will have to add at most one root certificate to her
browser to get the full CAcert experience (depending on whether class1
is included or not, independent of whether we do the one root to rule
them all or the root pair approach).

In my eyes it's a huge gain vs. a really tiny caveat.


Cheers,
-- 
Michael Tänzer
CAcert Support Team Leader

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.16.

Top of Page