Skip to Content.
Sympa Menu

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

Subject: Policy-Discussion

List archive

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

Chronological Thread 
  • From: Michael Tänzer <michael.taenzer AT>
  • To: Policy List <cacert-policy AT>
  • Subject: New Roots: Hierarchical Structure vs. Most Browsers aka Theory vs. Practice
  • Date: Tue, 30 Mar 2010 12:38:52 +0200
  • Authentication-results:; dkim=pass (1024-bit key) header.i= AT; dkim-asp=none
  • Openpgp: id=9940BEF1

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 ;-)

* 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
(, 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).

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.

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