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

General Forces and Influences

• RFCs on the issue (which typically refer to X.500 docs)
• browser and other client behaviour (See references at bottom)
• CAcert policies

• audit criteria e.g., to clearly describe risks, liabilities, obligations

• general legal requirement not to be deceptive

• general sense of setting a good example where possible

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

• Legal entity: CAcert, Inc. which is the association name

  • in which case we should also include the jurisdiction where the entity exists, New South Wales, AU

  • Or simply CAcert which is independent of structure and location.

• Actual role being played: CAcert.org - Community Certification Authority

  • Non-profit may be an appropriate alternative to Free, but the .org and Community could be enough?

  • yes, .org and Community should be sufficient.

• The soft entity actually running the CA: CAcert Community

  • not to be confused with the Internet community at large

• Then, a potential CN for the Class I root: CAcert Community Anonymous Root CA

  • the above is just an example to get people thinking.
    • what's anonymous? CAcert? the community? its users? the certificates? the root itself? this 'attribute' buys nothing and has the unintended consequence of flowing down to the sub-roots (eg by way of the issuer field)

Static / Conventional Fields

Convention (and possibly the RFCs) suggest that:

• O = records the name of the legal entity (eg CAcert, Inc., Apple, Inc., etc.)
• OU = technically, this is the organisational unit or division responsible for issuing certificates within the O= organisation.
• CN = perceived to be the unique (ideally short) name. Possibly of the specific CA/root (eg Apple Root CA, Acme Class1 CA, Thawte Server CA, etc.)

The current leading contenders are:

• CAcert.org is the short preferred name, with the .org because it stresses so well what the real organisation is.

• CAcert.org - Community Certification Authority being the name of the organisation and its mission/role/ closest description

What has been debated and dropped:

• Free. Too hard to define, too much a valueless marketing term
• CAcert Inc., The legal entity is a smaller part of the reality. Also some suggestion that the entity might migrate in the future, but the responsibility will remain.

What to put in the O

Leading contenders then are choice of above:

• O=CAcert.org - Community Certification Authority

• O=CAcert.org

There are a few other debated possibilities:

• O=CAcert, Inc. being the legal entity, the association in Australia.

• O=CAcert being the name of the organisation, independent of its structure or location (which may change during the life of the root)

• O=CAcert.org - Free Community Certification Authority being the name of the organisation and its mission

• O=CAcert Community being the soft organisation that runs the CA.

• O=CAcert - Free Community Certification Authority

Notes

• Will the name CAcert survive the timeframe of the root?

  • the name can change if someone files a trademark lawsuit or similar...
    • we can't really mitigate this risk except by moving in advance or by trademarking (as we should) ourselves
    • yes, it is just a comment on the possibility; we shouldn't get too hung up stuff that is "forever"...
  • re-branding exercises frequently suggest a change in name
• Will the (relatively new) focus on the Community survive?
  • it's far from clear (to some) that the (relatively new) focus on community will survive.
  • the Community concept has been settled in policy since September 2007, and was first formulated in 2006.
    • granted, but it is not a 'community' as such (and will be even less so with growth, particularly into the unwashed masses) and there is an alternative reading on 'community' as being the greater (Internet) community (which is not necessarily a bad thing).
• Will the legal entity survive?
  • It was formed around 2004
    • ...but could be erased by a lawsuit or moved to another more CA-friendly jurisdiction (with another name) if laws change
• Who issues the certs?
  • It is conceivable that CAcert, Inc. will issue certificates independent of the 'community'
  • and vice versa....
  • the address verified (AV) and domain verified (DV) certificates issued under Class 3 root may be examples of this.
  • But, the AV, DV is about verification of Name, not issuance. The Class 3 certs do not have any Assurer-verified Name. That doesn't mean they aren't issued by the Community.
  • Who issues the certs? Arguably, the Community does right now.
  • The Board is moving to get more control and place this under SM, CPS, management with a new set of roots.
  • The ambiguity of CAcert[.org] in this respect is not necessarily a bad thing given it is both in tandem
• So one could suggest that the new top-level root will be controlled by CAcert Inc., while the intermediate roots will be controlled by Community elements.
  • this will provide some dual control over the new roots
  • the two will need to agree? The board will not be able to issue without some element in the Community, and the Community elements will need board cooperation
    • this is an interesting symbiotic relationship; CAcert, Inc. is only allowed to issue sub-roots to the community who in turn use them to issue certificates to users (and sub-sub-roots to orgs)

• To some extent, the only test may be whatever is in the fields is not deceptive.

Notes on the legal entity

Considerations:

• A legal Entity may be preferred by the browsers. Or not.
• The structure and/or location of the entity may change.
  • for example if draconian laws were to be enacted down under.
  • AU laws are already passed to un-regulate the CA sector, so no likelihood of laws directing the fields themselves
• If deciding on the precise entity, then the location of registration may be useful
  • NSW, Australia is the incorporating state or registry

  • note that this is distinct to the jurisdiction of the Community, which is DRP

  • stating the location of registration may lead innocent users to imply an acceptance of that jurisdiction, which CAcert needs to clarify every where

  • better to leave out the location of the registry, and force the users to research more ... which should lead them to discovering their USE possibilities under RDL, etc, and that DRP rules over disputes, so less chance of being led astray by implications

• for both of the above reasons, leave the location of the registry out?
  • this sort of detail is better dealt with on the website.
• agreed, leave the location out, but only if also dropping the ', Inc.' and ideally replacing it with '.org'

What to put in the CN

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

• CA
• Certificate Authority.
  • not useful as redundant information, does not indicate anything
• Root CA
  • phrase "Root CA" has been already frowned upon so maybe best to get away from it totally [2].
  • calling a Root "Root" is maybe not that helpful if it is obvious to all concerned
  • what else could it be?
• Root Certificate Authority
  • still says little
• Community CA
• Community Certification Authority
• Community Root CA
  • better to separate it out like Community CA - Root
• Community Root Certfication Authority

Which then leads to a suggest CN of:

• CN=CAcert.org - Community Certification Authority

Notes:

• the word "root" could indicate the root-of-all-roots
• sub-roots which couldd instead use the functional name
  • eg CAcert Organisation Assurance CA
  • CAcert Organisation Assurance Sub-root?)
  • agreed...

• If the O above uses the legal name, then the CN should probably use the Community name.
  • Or vice-versa?
    • ...or not specify given it is actually both in concert: CAcert.org
• Community name may be redundant here if included in O.
  • However, note that practice of others is to use redundant name in many fields,
  • And some browsers are annoyingly different in their display.

What to put in OU ?

Some considerations:

• Many CAs are single purpose, so there isn't a separate Organization Unit
• CAcert is (currently) 100% dedicated to its CA function so OU is not really applicable, except perhaps for the various 'program[mes]': CAP, RAP, OAP, etc.
• Many CAs use the OU field as a sort of branding comment to press a slogan.

• Existing CAcert roots set this to http://www.cacert.org/ . Some client software, like Safari/OS X, automatically identifies a URL in the OU and creates a clickable link. Finally, there is no other obvious locations for the URL to live.

• Another alternative would be to consider the 'CAcert Community' an organisational unit.

Suggestions:

• http://www.cacert.org/ (status quo)

• Web of Trust, Certification Services, Security, Certification Authority. (but not if too generic)

• Legal notice, as below. (eg (c) 2008 CAcert, Inc. - For authorised use only, see http://go.cacert.org/use )

Other CAs

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

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:

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:

Comments:

• burning policy into roots is has its dangers;

  • NRP's Old D a L was withdrawn. It was unprecedented and untested so the 'risk' of change in this area is non-negligible

  • RDL is still new, and carries a risk of change.
  • basic concept is similar to an open source licence and/or a train station notice. These things work as long as there is no misrepresentation, and in the absence of any other offer that might be implied.
  • testing in a court of law will likely take 10 years...
  • approach reflects reality of CA reliance
  • similar posture to other players in the sector, perhaps reflecting more than a decade of experience
  • CAcert has to pick a posture and stick to it

  • CAcert has picked RDL. Dumped NRP's old D a L

  • legal avoidance of misrepresentation calls for presentation of position at all times and places
    • ...which could be satisfied by reference to an explanation elsewhere, or by 'default deny' added above
    • nobody (including members) should be expressly permitted to rely
• springboard may be one way to deal with any risk of change

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

• Netscape Certificate Comment ( 2 16 840 1 113730 1 13 ): which is more flexible with regards content but less likely to be displayed. Field can be very long (eg NetLock). It's what we use today.

• Organization Unit (OU): which appears in browser dialogs but is a clear misuse of the field
• Something else?

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:

• R/L/O audit criteria require the full and reasonable disclose of the risks to the parties
  • in effect this means that no legal tricks should be used to hide the real truth
  • hence NRPs to be told they must not RELY, but they may USE
  • the CA has already been instructed on some of these issues by audit
  • polices are now in place that meet requirements of R/L/O
• policies of the CA.
  • core issue here is that non-Members must not RELY.
  • Is controlled in CCA, RDL, which are the the end-user facing agreements.
  • backed up by DRP

  • of these documents, CCA is full POLICY and have been approved by policy group, the board and the AGM

  • RDL is in DRAFT, see RDL action page

• Copyright is asserted over all roots and certs in the CCA.
  • This can and should be replicated without problem in the roots, however it does not needed to be prominent
  • the purpose of copyright assertion is to meet the above policy of banning reliance by non-Members
  • although one can suggest that it is academically unusual, this tool is not without precedence
• permission to distribute the certs and roots

  • is controlled in RDL so as to enforce especially ban any inappropriate RELIANCE

  • those that are not accepting any offer lack any permission to distribute the roots or certs
  • each person who accepts the RDL can download the roots for their USE, as offered by a Member or download site
  • they can then pass it on to another under RDL.
  • This preserves the ban on RELIANCE by non-Members
  • Members are also permitted to distribute (e.g., via their servers and mailclients) and they take on that responsibility.
  • so as to not endanger the interests of CAcert Members, nor the 3pv, nor the 3pv's users.
  • unfortunately, 3pvs have not thought about these issues much.
  • (Microsoft appears to be the exception, but they are not talking.)

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

• the roots are to assert copyright, but this need not be prominent
• there is no permission to distribute the roots granted within the cert, this is controlled by RDL
• this is policy, and it overrides any "marketing" sense of wanting to distribute the roots
• this policy is new, might evolve further.

Advertising and slogans

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

• Agreed, but it has been argued that we are non-profit, but also at times non-free. The combination of adding '.org' and including 'community' could get this message across without overtly stating it.

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:

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

  • is the old slogan

  • StartCom advertise that they are 'Free'; we could do the same.

  • FREE Certificates is the old viewpoint or strategic vision
  • "free as in beer" ?

    • Free is a potent differentiator and even if we recover costs, issuance is still free

  • while not wrong -- certs are still free and likely to remain so -- it is simplistic
• Community CA
  • somewhat newer viewpoint inspired by R/L/O
  • a far more nuanced view, it more correctly incorporates the non-monetary costs of the community
  • this reaches towards the "free as in freedom" concept of FSF.

    • Addition of the '.org' to CAcert furthers this view (.org => non-profit organisation) and resolves the need to include a URL in an inappropriate field (eg OU)

Where should this go?

Second question is, where might this slogan go?

• O
• OU
• CN
• other...
  • O and CN are used interchangably depending on software. if it is to be seen it should go into either (or both) of these. For example:
    • O=CAcert.org Community Certification Authority
    • CN=O=CAcert.org Community Root Certification Authority

Technical Issues

Certificate Revocation Lists (CRLs)

Notes:

• Root certificates should not include CRL information, likely for performance and scalability reasons (slows down users and doubles our traffic?) and because doing so is unnecessary given this information will be included in the issued certificates.

• If a root is compromised the vendors will remove them via updates regardless of CRL status (does this apply to subroots?).

• We currently do include HTTPS URLs which should be unnecessary given they are signed, and could cause problems with clients (worst case, won't handshake, don't bother with CRL).
• Doing away with CRLs totally could be an easy approach but may not be universally accepted.

• Also with respect to CRL URLs (from bug 570): Using the "www or go".cacert.org third-level domain makes it very difficult to mirror the CRL.

Recommendation:

• Root should not include CRL/OCSP
• Subroots should have a OCSP that a client can handle for querying the subroot revocation.

  • CRLs of subroots is hard as it requires the root to be online (which is bad). Unsolved.

• End Entity certificates should include CRL/OCSP info

• (refs: https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root https://wiki.mozilla.org/CA:Recommendations_for_Roots )

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

• all Netscape fields are comments, not required, probably not useful.

End Entity Certs only

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

Algorithm Sizes

• SHA:
  • SHA1 is fine for the root, as the self-signing is more or less cosmetic; the strength of the root by definition is from its selection in a higher-layer human protocol.
  • The question of support for SHA2 is only relevant for intermediate subroots and for EE certs.
  • Vista and NSS (Mozilla) have SHA2 support, XP gets it as of Service Pack 3 only

  • rfc5758 section 2 - CAs implementations SHOULD use SHA-224, SHA-256, SHA-384, or SHA-512 when generating certificates

• RSA bits

  • 2048 is the minimum specified by Microsoft these days, 4k is the max

  • DRAFT-FIPS-186-3 specifies 1024, 2048, 3072 only.
  • seems like we may as well just stick with 4k

  • EE - limit to 2048+ Second hand ref to Microsoft Policy, Mozilla following suite?. Phone Certificate limitations(?)

Other References

• RFC 5280 (also the deprecated RFC 3280) for semantics

• RFC 3279 / RFC 4055 for the algorithms.

• OpenSSL web pages

• http://keylength.net/ and also, less convenient, See tables 2 and 3, pp 63-64 in NIST guidelines.

• DRAFT-FIPS-186-3

---

• CategoryAudit

• CategoryNewRootsTaskForce