Author: Teus Hagen
Creation date: 2008-05-02
Status: WiP 2008-05-02
Next status: DRAFT 2008

0. Preliminaries

In this policy it is defined what CAcert does with the "Subject" and "SubjectAlternativeName" record in the issued X.509 certificate.

The ITU-T Recommendation X.509 of June 1997 (limited by the used OpenSSL implementation) defines the information types (and formats) "Tagged Modules" for the "Subject" (IETF standard RFC3280/4.1.2.6) for a Distinguished Name (DN): a sequence of X.501 styled elements (type/value pairs), type="value" (e.g. "CN=Saskia the Mystical/emailAddress=sky@limit.net") on the issued certificate (see for "type" below).

Subject and SubjectAlternativeName may be used in the Certificate Signing Request (CSR) sent to CAcert. CAcert will use this information as well information checked from assurances and other means to assemble the Subject and SubjectAlternativeName records.

0.1 Other Documents

• See also for the current working documentation for this subject: CPS (wip) 3.1 Naming .
• RFC 3039 Qualified Certificate Profile.

1. Information Policies

1.1 Organisation and Individual certificate information policy

The current policy of CAcert on information of individuals and organisations on an issues certificate by CAcert is: only those (exact) names and other information which are checked via an assurance or by well defined means (e.g. email address and domain evaluation). This is pretty much limited by reasons of private information and traceability information. The set of information about the certficate user on the issued certificate is limited and shall meet common usage security practice on internet.

1.2 Information Assurance

CAcert operation will be organised such that the individual or organisation Member of the CAcert Community for which the certificate is issued has been identified by the web of trust of CAcert Assurers (Assurance Policy). Prerequisite is: what is supplied as information on the issued certificate should be well defined and it should be clear what is check by assurances (or other means) and what not.

1.3 Information and Internet Security Practice

CAcert should not violate common security practice of the use of some "type" - records in the Subject field in the issued certificate. Here we talk about two types of certificates (key usage): server certificates and client certificates for individuals (persons) and for organisations ("trade" entities).

2. Subject Information Records

2.1 Overview of Information Types

Information records are defined in definitions of "type=value" (e.g. CN=www.cacert.org) pairs.
The differnet "types":

• country "C"
• organisation "O"
• organisation unit "OU"
• distinguised name qualifier
• state or province "ST"
• common name "CN"
• locality "L"
• postal address
• title
• surname "FN"
• given name "GN"
• initials
• pseudonym
• generation qualifier
• serial number "SN".

Remarks:

• common practice is that the search for a name in an certificate is prioritised: common name, given name / surname, pseudonym.
• In the following "(not-supported)" will say CAcert will not evaluate the information for the certificate, and not provide it in the issued certificate.
• Comparison of values are based on X.500 specification. Note this for the comparison of names of individuals and organisations. CAcert may use own rules on the comparison.

2.2 Overview of information types used by CAcert

What information types (Tagged Modulels) in the certificates issued by CAcert are implemented?

2.2.1 Information on Individual certificates

An "(optional)" value will say: if required during certificate signing request and defined in the CAcert account information.

List of supported information types in Subject field of certificates of individual CAcert Community Members:

CN: Common Name

On the server certificate:

fully routable DNS domain name (evaluated and practiced by external world)

On the client certificate:

the full name of the person in the account (one of the assured full names, await implementation) with fully routable email address(es) (.../emailAddress=RFC822 (email addess) tuples) (subset of evaluated email addresses in the CAcert account).

FN: surname (optional)

(?need vote?)
if in CAcert archive (see CAP form) archive and on request of user it is supported (it is evaluated via Web of Trust).

GN: given name (optional)

(?need vote?)
if in CAcert archive (see CAP form) archive and on

PS: pseudonym (optional)

(?need vote? leave to future?)
presentation layer full name discussion: if evaluated by Wob of Trust it can be supported (implies X persons from CAcert Community ack this?) Or it is simply (not-supported) (user may decide, CAcert will follow the sugestion).

2.2.2 Information on Organisation certificates

An "(optional)" value will say: if required during certificate signing request and defined in the CAcert account information.

List of supported information types in Subject field of certificates of organisation CAcert Community Members:

CN: Common Name

On the server certificate:

fully routable DNS domain name (evaluated and practiced by external world);

On the client certificate:

organisation client cert: ?? (what is the practice? : organisation name and/or contact email address(es)?).

O: Organisation name (optional)

checked from COAP/trade office registry extract. (? add contact email address here?)

OU: Organisation Unit name (optional)

checked from COAP/trade office registry extract. (? add contact email address here?)

L: Locality name (not-supported)

CAcert will follow suggestiuon of requester, but not check values provided.

ST: State (optional)

only some countries as eg USA, Germany?
checked from COAP/trade office registry extract.

C: Country name (optional)

checked from COAP/trade office registry extract.

pseudonym: (?) (optional)

?need vote? leave to future?
trademarks? Not checkeced by CAcert? or COAP form?

2.3 What Information Types are not supported

Directory attributes:

title, date of birth, place of birth, gender, country of citizenship, country of residence information types are not supported by CAcert.

Biometric information extension

is not supported by CAcert.

Qualified certificate statements

are not supported by CAcert.

Application names

are not supported by CAcert.

3. Certificate types and Services Remarks

CAcert does not support Identity Certificates.

CAcert does not have other downwards trusted roles (Registration Authorities (RA), Local Regsitration Authorities (LRA), or Trusted Agents (TA).

Alternate login certificate names: CAcert uses Common Name (CN) of the CAcert certificate.

Code Signing certificates are supported, currently requires a higher degree of assurances (100 points). More about Code Signing certificates is defined in the Code Signing policy.
?cn=CS....???

Trusted Timestamp service: is planned.

CAcert does not: private key multi-person (n out of m) control, private key escrow, private key backup, private key archival, certificate backup.

CAcert does Certificate Signature Request backup (but it is not guaranteed). CSR can have user provided "Subject" X.501 information.

A1. Notes on Transliterations in Names

Following notes were in the Assurance Policy but now moved to here for consideration.

The Common Name and related certificate fields in the issued certificate is dependent on the assurance of the Name in the web account. Abbreviation and transliteration handling in the CN is defined in the Certificate Implementation Policy and is similar to the name comparison as defined in this policy. However the Common Name may become less discriminative as than the assured Name as the unique certificate serial number will lead to the account of the individual in a unique way, and in this way to the Name and email address of the individual or organisation. The first given name in the Common Name may be abbreviated on request.

The certificate issued by CAcert can have on request of the Member the SubjAltName field. The name as defined by the Member is not checked by CAcert.

table XXXX: Examples of names in different contexts