• Roots
• Structure

• česky | english

Intro

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

Structure

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
                                Certificate

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:

• "Member" -- available for unassured Members, and with DV / AV only certs. No names included.

• "Assured" -- available only for Assured Individual Members, Names can be included (but need not).

• "Organisation" -- available only for Assured Organisation Members, Company Names can be included.

• "Assurer" -- available only for Assurer Individual Members, Names can be included (but need not(?)).

Possibilities for the future

• it could be possible to think about a code-signing subroot

Distribution

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

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

• mozo thread on subroots in Firefox

Pros & Cons

Pros for 1 (Cons for 2):

• simple for subscriber as she only needs to deal with her own cert
• potential selection by each issuer of different profiles
  • which means that unusual roots like DV/AV or the like can be filtered out
  • no scary "one root to bind them all"...

Pros for 2 (Cons for 1):

• subscriber has to load up both the subroot and her cert in her software
  • e.g., Apache HTTPD has to be configured more carefully
  • how does this work with mail clients?
• means that one root can provide a unified acceptance across CAcert's offered subroots
• only a simple negotiation required

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

Terminology

Following terms are being used:

• top-level root

• subroot

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

• We need three terms, for top, intermediate/subs, and leafs.

• Use of the term root is confusing and overloaded.

• The purist view is perhaps that only the top-level one can be the 'root' ... the pragmatic view is that the top plus intermediates are a "root package."
• The PKI terminology is apparently
  • everything is a certificate
  • root certificate is top (which is only a certificate because the code can't handle a public key by itself)
  • intermediate certificate is signed by a top or other intermediate, has the "isARoot" bit set, and is used only for signing other certificates
  • End-Entity certificates or EE certificates are those that do not sign other certificates and presumably have some use to real people.
  • as always, PKI is designed to confuse the beejeezus out of everyone else, and its terminology is not recommendable for real people.
• Users don't care, Members don't care. Therefore we just need terms that we can agree on and use.
• Note that Microsoft got grumpy because old CAcert root had CN='Root CA' in it. Quite fairly...
• Current view is this:

  • the one at the top is called root or top-level root where needed

  • the intermediates are called subroots because that is clearer to others

  • the ones at the bottom are called certificates, because that's what users understand.

Also see Mozilla CA Glossary for Mozilla terms.

CategoryAudit

CategoryNewRootsTaskForce