---- [[Roots/Structure/CZ|česky]] | '''english''' ---- ## 30.08.2015 AK == 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 [[https://www.cacert.org/policy/CertificationPracticeStatement.php|CPS]] ('''DRAFT''') and the [[SecurityManual|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: || # || ''what goes in the root list'' || ''what the subscriber must provide'' e.g., in Apache || || 1 || root and subroots || server cert || || 2 || 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. * [[http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/dcad2183363667f1|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 [[https://wiki.mozilla.org/CA:Glossary|Mozilla CA Glossary]] for Mozilla terms. ---- CategoryAudit CategoryNewRootsTaskForce