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: Daniel Black <daniel 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 11:43:49 +1100
  • Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none
  • Organization: CAcert

On Tuesday 30 March 2010 21:38:52 Michael Tänzer wrote:
> Hi there,
> 
> Just noticed that also with the new roots the root task force wants to
> make a single top level root/subroot/end user cert structure.
> 
> While in theory this is a good approach it fails in practice:
> 
> * If browsers really incorporate our top level root then everything is
> fine. Except that I would really question their reasoning because they
> accept unassured accounts by default, but I'm not the average person
> when it comes to paranoia ;-)

The assumption here is that browsers care significantly at how assured a 
person 
is. The below isn't Mozilla's policy yet but at least it shows they are 
catching up to something the policy group here decided a while ago.
https://wiki.mozilla.org/CA:Problematic_Practices#Validate_all_Data_included_in_Certificates

Unassured accounts have domain validation which is pretty close to the low 
level the CPSs of other CAs.
 
> * If browsers (or users) think that it's not safe enough to include the
> member subroot and only want to include all other subroots they will
> fail (AFAIK in all browsers except Firefox). This is due to a stupid
> assumption made in most crypto modules used by browsers that requires a
> root to be self-signed. Yes it's totally insane but that's how they
> work. I've already filled bug reports on Konqueror
> (http://bugs.kde.org/show_bug.cgi?id=163133),

If it depends on a Qt patch it could take a while.  I did a simple SNI patch 

over 6 months that still waiting.
http://qt.gitorious.org/qt/qt/merge_requests/1574

> Opera and I tried to get
> this noticed by Microsoft (yeah, I really tried, I know it was
> pointless). So right now the only option users of these browsers have (I
> haven't tested safari on a mac (on Windows it just uses the Microsoft
> libraries) or Chrome) is to take all or nothing of CAcert which IMHO is
> bad.
> 
> Therefore I would vote for a flat approach (i.e. make the subroots top
> level) due to these practical reasons, or at least make a separate (i.e.
> self-signed) top level root for the less validated subroots so paranoid
> users/browser vendors can include the class3 top level root (which has
> the subroots assured individual, assured organisation, assurer, etc.)
> and users that also want to trust unassured accounts additionally import
> the class1 top level root (which only has the member subroot but may get
> more subroots if we want to).

I certainly see your point here. Providing good control for non-average 
paranoia is a goal.

There's talk of restricting the number of roots. you've mentioned two which 
is 
ok.
https://wiki.mozilla.org/CA:Problematic_Practices#Root_Count_Restrictions


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

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)

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.


-- 
Daniel Black
CAcert

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.16.

Top of Page