256 lines
8.9 KiB
HTML
256 lines
8.9 KiB
HTML
|
<?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>
|