Disscussion on the Content of the top-level Root, as part of the Roots/NewRootsTaskForce thread.

General Forces and Influences

Name of Issuer

There are approximately three primary fields that are frequently displayed: O, OU, CN. We need to select each of these.

Names for Us

The old issuer name is not good enough, indeed it has been banned by some [2]. We need to decide on the name form and its full and accurate text form. Here's some starter suggestions

Static / Conventional Fields

Convention (and possibly the RFCs) suggest that:

The current leading contenders are:

What has been debated and dropped:

What to put in the O

Leading contenders then are choice of above:

There are a few other debated possibilities:



What to put in the CN

Short name CAcert.org plus root role is suggested. Current contenders for root role are:

Which then leads to a suggest CN of:


What to put in OU ?

Some considerations:


Other CAs

For sanity checks, this is how other CAs seem to do it:





AddTrust AB

AddTrust TTP Network

AddTrust Class 1 CA

OU specifies RA (trusted third party network?)

Apple Inc.

Apple Certification Authority

Apple Root CA


Comodo CA Limited


Secure Certificate Services

Confusing where CN used alone (eg OS X/Safari)


Equifax Secure Certificate Authority


StartCom Ltd.

CA Authority Dep.

Free SSL Certification Authority

Confusing where CN used alone (eg OS X/Safari)

The Go Daddy Group, Inc.

Go Daddy Class 2 Certification Authority


Thawte Consulting

Certification Services Division

Thawte Personal Basic CA

C,ST,L set

VeriSign, Inc.

VeriSign Trust Network

VeriSign Class 1 Public Primary CA


OU: Some (eg Entrust, Verisign) overload OU with information about CPS ('www.entrust.net/SSL_CPS incorp. by ref. (limits liab.)'), copyright ('(c) 2000 Entrust.net Limited') and usage ('(c) 1999 VeriSign, Inc. - For authorized use only'). However, browsers do not seem to display these overloadings, choosing either the first or last.

Meaning of primary fields

Whatever goes in the primary fields should be what we want to signal to the cert reader as "who verified the information." More technically, a cert is a list of claims being made of the subject by the CA. To be useful to the user, the claims need to be displayed, the subject has to be identified, and the CA has to be identified. As actual displays have a big effect, indeed a dominating effect, on the eventual meaning to the user, this may override the meanings of the static conventions laid down in the documents, above.

For comparison, this is what browsers and other client software display to the user, when showing the set of claims:





Mozilla Firefox

Verified by:

O=verifying organisation name

As Mozilla is the current #1 target, this may be the preferred model

OS X/Safari

Issued by:

CN=common name of issuer

Falls back to OU when not set


Issued by:

CN=common name of issuer

certificate dialog, "General" tab. Also says This certificate is intended for the following purpose(s): and this starred comment: *Refer to the certification authority's statement for details. but no indication there what the star '*' refers to.


certificate chain displayed only

certificates in chain named by CN= field

click on padlock






CN=common name of issuer ?

"same as IE or Safari on windows"


Certificate issued by:

CN=common name of issuer ?

Tb is different to FF (Mozo has no good policy on claims as yet)

CN: It looks like the CN= is primarily used as a mix of the short name of the issuer, and some sort of description of what this root is about, that is the the place in the structure of the roots, like "Class 3 Server CA". It may be a good idea for both CN= and O= should include the issuer/verifier name, because browsers are not equivalent.

The OU= is then used as an arbitrary branding comment like "Cool digital trust network". It is also used as a duplicate field to list additional comments, but no browser handles more than one OU.

Licence and Permission

According to some viewpoints, the roots and certificates should include some form of indication that there is permission to use or rely or whatever. E.g, Verisign refers to CPS, includes copyright, and includes a legal statement.

In CAcert, NRPs can USE the certificates under RDL, etc, but are not permitted to RELY. Because of various legal considerations (beyond scope of this doc) there is a requirement to present these issues in as complete and clear fashion as possible. Everywhere. According to this theory, we need a statement in the cert to make this clear.

Potential notices and comments on this:


Legal Notice



To get your own certificate for FREE head over to http://www.cacert.org

This could be considered to be old advertising in the old roots. That might be an implied offer, but even that is a stretch!


For authorised USE only, see http://go.cacert.org/use

uses springboard to relevant docs.


For USE only, see http://go.cacert.org/USE

reference to permanent page on this issue.


(c) 2008 CAcert, Inc.

Relies on licensing under copyright law to control usage (without a copyright license user may not be permitted certain important and typical usages)


(c) 2008 CAcert, Inc. - For acceptable USE, see http://wiki.cacert.org/USE

Uses both approaches.

Default Deny

RELIANCE is only permitted under http://wiki.cacert.org/RELY

Denies everything by default, except per off-root document which can be updated


USE is offered and explained under http://wiki.cacert.org/USE . RELIANCE not permitted, except to members under http://wiki.cacert.org/RELY

Addition of .


There is also the question of which field is used for the purpose of disclaimer, licences, permissions etc:

Once this debate is settled, we can copy the preferred notice down below.

Policy behind the Licences

In more depth, certificates and roots is effected by many things:

From the above, we can draw the following basic Facts of CAcert policy:

Advertising and slogans

We should continue to differentiate ourselves by 'advertising' what we are; a free, community certification authority.

What is the potential slogan?

There are frequent references to advertising of some slogan or other. These might appear in OU or CN, or other fields. First question is, what might CAcert push as an advertising or position:

Where should this go?

Second question is, where might this slogan go?

Technical Issues

Certificate Revocation Lists (CRLs)



Nature of URLs

Note: Replaced long URLs (eg http://www.cacert.org/policy/CertificationPracticeStatement.php) with clean, redirected ones (eg http://go.cacert.org/cps)

These fields are better seen in Safari than in Firefox.

Old, deprecated, not to be used fields




Next Gen






CAcert, Inc. is registered in the state of NSW so we could set this to New South Wales if we were sure that the entity will not change. Leave L=Sydney out as this is not its place of registration.




No problems, unless we don't include it (making it impossible to identify CAcert, Inc., but this may change in the life of the root)

Extended Key Usage

Netscape Server Gated Crypto

allows ancient export browsers to be 'upgraded' from 40 to 128 bit. still relevant today?

Netscape Certificate Authority Policy URL



duplicate of above, might be old field

Netscape Certificate Type

SSL Certificate Authority; Email Certificate Authority

both? either?

Netscape Certificate Comment

To get your own certificate for FREE head over to http://www.cacert.org

see above discussion

discuss... how long can a comment be?




there is no consensus on this issue

Certificate Subject Alt Name


Class 3 ?

End Entity Certs only

End Entity or EE certs information that is collected along the way:

CRL Distribution Points


URI: http://crl.cacert.org/root.crl

change or good? changed; '-revoke' was redundant. mozo says, not in the root

Netscape Certificate Authority Revocation URL



duplicate? mozo says, CRLs in the certs not the root


Authority Key ID


See rfc5280 for format & contents. Certs have an Authority Key ID (AKID), which may contain the SKID value of the issuer's cert, or the issuer name and serial number in the issuer's cert, or both. Including the Issuer's Issuer Name and serial number is usually a mistake, but not always.

Authority Information Access

OCSP: URI: http://ocsp.cacert.org/

is the the OCSP?

Extended Key Usage (EKU)

CPS EKU fields


Microsoft suggests extended key usage is optional (except if you want to use them), Mozo suggests root should not be constrained.

Authority Information Access extension


ditto, for certs not roots

SHA support


SHA1 and SHA2

we could consider doing SHA2 in EE certs

Algorithm Sizes

Other References







Mozilla CA Certificate Policy, Glossary

no official root guidance as yet, but there are some "unofficial docs" and some notes from CAcert emerging



Microsoft Root Certificate Program



Apple Root Certificate Program



Getting Your Root Certificate Included in Opera

Roots/ContentsDiscussion (last edited 2013-02-25 23:07:33 by UlrichSchroeter)