cacert-policies/X509ImplementationPolicy.html

256 lines
8.9 KiB
HTML
Raw Normal View History

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>
</title>
</head>
<body>
<h1>
</h1>
<p>
<a href="../PolicyOnPolicy.html"><img src="../Images/cacert-wip.png" alt="CAcert Policy Status" height="31" width="88" style="border-style: none;" /></a><br />
Author: Teus Hagen<br />
Creation date: 2008-05-02<br />
Status: WiP 2008-05-02<br />
Next status: DRAFT 2008<br />
<!-- $Id: X509ImplementationPolicy.html 772 2008-05-02 13:46:20Z teus $ -->
</p>
<h2>
0. Preliminaries
</h2>
<p>
In this policy it is defined
what CAcert does with the "Subject" and "SubjectAlternativeName" record in the issued X.509 certificate.
</p>
<p>
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).
<p>
</p>
<p>
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.
</p>
<P>
Other documents: RFC 3039 Qualified Certificate Profile.
</p>
<h2>
1. Information Policies
</h2>
<h3>
1.1 Organisation and Individual certificate information policy
</h3>
<p>
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.
</p>
<h3>
1.2 Information Assurance
</h3>
<p>
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.
</p>
<h3>
1.3 Information and Internet Security Practice
</h3>
<p>
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).
<h2>
2. Subject Information Records
</h2>
<h3>
2.1 Overview of Information Types
</h3>
<p>
Information records are defined in definitions of "type=value" (e.g. CN=www.cacert.org) pairs.
<br>The differnet "types":
<ul>
<li>country "C"</li>
<li>organisation "O"</li>
<li>organisation unit "OU"</li>
<li>distinguised name qualifier</li>
<li>state or province "ST"</li>
<li>common name "CN"</li>
<li>locality "L"</li>
<li>postal address</li>
<li>title</li>
<li>surname "FN"</li>
<li>given name "GN"</li>
<li>initials</li>
<li>pseudonym</li>
<li>generation qualifier</li>
<li>serial number "SN".</li>
</ul>
<p>
Remarks:
<ul>
<li>common practice is that the search for a name in an certificate is prioritised: common name, given name / surname, pseudonym.</li>
<li>In the following "(<i>not-supported</i>)" will say CAcert will not evaluate the
information for the certificate, and not provide it in the issued
certificate.</li>
<li>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.</li>
</ul>
<h3>
2.2 Overview of information types used by CAcert
</h3>
<p>
What information types (Tagged Modulels) in the certificates issued by CAcert are implemented?
<ul>
<h4>
2.2.1 Information on Individual certificates
</h4>
<p>
An "(<i>optional</i>)" value will say: if required during certificate signing request and defined in the CAcert account information.
</p>
<p>
List of supported information types in Subject field of certificates of individual CAcert Community Members:
<dl>
<dt><i>CN: Common Name</i></dt>
<dd><dl>
<dt>On the <i>server</i> certificate:</dt>
<dd>fully routable DNS domain name (evaluated and practiced by external world)
</dd>
<dt>On the <i>client</i> certificate:</dt>
<dd>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).
</dd>
</dl>
</dd>
<dt><i>FN: surname</i> (<i>optional</i>)</dt>
<dd>(?need vote?)
<br>if in CAcert archive (see CAP form) archive and on
request of user it is supported (it is evaluated via Web of Trust).
</dd>
<dt><i>GN: given name</i> (<i>optional</i>)</dt>
<dd>(?need vote?)
<br>if in CAcert archive (see CAP form) archive and on
</dd>
<dt><i>PS: pseudonym</i> (<i>optional</i>)</dt>
<dd>(?need vote? leave to future?)
<br>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 (<i>not-supported</i>) (user may decide, CAcert will follow the sugestion).
</dd>
</dl>
</p>
<h4>
2.2.2 Information on Organisation certificates
</h4>
<p>
<p>
An "(<i>optional</i>)" value will say: if required during certificate signing request and defined in the CAcert account information.
</p>
<p>
List of supported information types in Subject field of certificates of organisation CAcert Community Members:
<dl>
<dt><i>CN: Common Name</i></dt>
<dd>
<dl>
<dt>On the <i>server</i> certificate:</dt>
<dd>fully routable DNS domain name (evaluated and
practiced by external world);</dd>
<dt>On the <i>client</i> certificate: </dt>
<dd>organisation <i>client</i> cert: ?? (what is the practice? :
organisation name and/or contact email address(es)?).
</dd>
</dl>
</dd>
<dt><i>O: Organisation name</i> (<i>optional</i>)</dt>
<dd>checked from COAP/trade office registry extract.
(? add contact email address here?)
</dd>
<dt><i>OU: Organisation Unit name</i> (<i>optional</i>)</dt>
<dd>checked from COAP/trade office registry extract.
(? add contact email address here?)
</dd>
<dt><i>L: Locality name</i> (<i>not-supported</i>) </dt>
<dd>CAcert will follow suggestiuon of requester, but not check values provided.
</dd>
<dt><i>ST: State</i> (<i>optional</i>) </dt>
<dd>only some countries as eg USA, Germany?
<br>checked from COAP/trade office registry extract.
</dd>
<dt><i>C: Country name</i> (<i>optional</i>)</dt>
<dd>checked from COAP/trade office registry extract.
</dd>
<dt><i>pseudonym: (?)</i> (<i>optional</i>)</dt>
<dd>?need vote? leave to future?
<br>trademarks? Not checkeced by CAcert? or COAP form?
</dd>
</dl>
</p>
<h3>
2.3 What Information Types are not supported
</h3>
<p>
<dl>
<dt>Directory attributes:</dt>
<dd>title, date of birth, place of birth, gender,
country of citizenship, country of residence information types are not supported by CAcert.
</dd>
<dt>Biometric information extension </dt>
<dd>is not supported by CAcert.
</dd>
<dt>Qualified certificate statements</dt>
<dd>are not supported by CAcert.
</dd>
<dt>Application names</dt>
<dd>are not supported by CAcert.
</dd>
</dl>
</p>
<h2>
3. Certificate types and Services Remarks
</h2>
<p>
CAcert does not support Identity Certificates.
</p><p>
CAcert does not have other downwards trusted roles (Registration
Authorities (RA), Local Regsitration Authorities (LRA), or Trusted
Agents (TA).
</p><p>
Alternate login certificate names: CAcert uses Common Name (CN) of the
CAcert certificate.
</p><p>
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.
<br>
?cn=CS.<O_org_name_or_full_name>.<code-signing_identification_number>..???
</p><p>
Trusted Timestamp service: is planned.
</p><p>
CAcert does not: private key multi-person (n out of m) control, private
key escrow, private key backup, private key archival, certificate backup.
</p><p>
CAcert does Certificate Signature Request backup (but it is not
guaranteed). CSR can have user provided "Subject" X.501 information.
</p>
<p>
<a href="http://validator.w3.org/check?uri=referer"><img src="../Images/valid-xhtml11-blue" alt="Valid XHTML 1.1" height="31" width="88" style="border-style: none;" /></a>
</p>
</body>
</html>