This page describes the new structure and hierarchy of the set of new roots. It is part of the Roots/NewRootsTaskForce group of pages, see there for overall. See Roots/Contents for detailed info in each root.

Note that as we decide on the way to do this, the process should be transferred to the CPS (DRAFT) and the Security Manual (DRAFT).

Structure of Roots


The new roots structure is a hierarchical model:

              Top Level Root--------------------                   <== this goes in
              /    |      \               \     \                the root list (browsers)
             /     |       \               \     \
            /      |        \               \     \______ OCSP responder Cert for subroots revocation (if ever required)
           /       |         \               \
          /        |          \               \
      Member       Assured     Assured         Assurer                 <== users may have to
     subroot     Individual    Organisation     subroot                distro the subroot
       |  \       subroot       subroot            \                   themselves
       |   \        |  \           |  \             \
       |    \ ______|___\__________|___\_____________\____ OCSP responder certificate for each subroot signing revocation of end entity certificates
       |            |              |
      \|/          \|/            \|/
   Anonymous     Assured         Special       <== certs distributed
   Certificate  Certificate      Purpose           by user software

Additional subroots for special purposes (e.g., code-signing) can be added later on, as long as the conform to the policies and practices, as audited.

Types of subroots

The subroots are named such:

Possibilities for the future


According to the concept, we can choose one of two strategies:


what goes in the root list

what the subscriber must provide e.g., in Apache


root and subroots

server cert


root only

server cert plus subroot

In general Mozilla and Microsoft chooses the 2nd concept; both will only distribute the top-level root as policy in the future.

Pros & Cons

Pros for 1 (Cons for 2):

Pros for 2 (Cons for 1):

Multiple Roots question: I wonder if it isnt easier for CAcert to get included by Vendors when the actual policy for creating certs can be guranteed to be stable. You talk about new sub-ca certificates in the future under a single/common root. This is good since we can later on increase the number of services, but this is bad for the vendor to trust us. It would help to use multiple roots. This also has some other advantages: users can pick class1 and/or class3 without having to import subroots. Cert revocation does not affect the whole chains. -- BerndEckenfels

CRL signing question: Can it be avoided to use the root cert for CRL signing? The root's secret key should never be used in daily business. (It is good to include the capability for issuing a revocation, but it is not good to use it for the regular resigning). I think it is possible to specify an indirect CRL issuer, but I also think that one is not well supported by major implementations? -- BerndEckenfels


Following terms are being used:

Use of the various terms is very confusing, and is not yet settled. Notes:

Also see Mozilla CA Glossary for Mozilla terms.