Add proposed files

2024-05-14 20:31:44 +02:00
5 changed files with 611 additions and 780 deletions
--- a/CAcert-CPS-Pojmy.txt
+++ b/CAcert-CPS-Pojmy.txt
@ -0,0 +1,30 @@
 Assured member   - a member of the CAcert community who has 50+ APs (COD13 Assurance Policy #2.3)
  (AP: Prospective Member with created account + Member)
 Unassured member - a member of the CAcert community who has <50 APs (COD13 Assurance Policy #2.3)
  (AP: Assured Member + Prospective Assurer + Assurer)
 Root CA certificate - the main certificate of a CA (Main Root)
 Subordinate CA certificate (Subroot, intermediate CA certificate)
 Issuer DN - Distinguished Name of the issuer authority
 Subject DN - Distinguished Name of the subject, for which the certificate is issued
 ...
 and 1.3 from CPS COD6
 Certification Authority
 Registration Authority
 Subscriber
 Relying Party
 Member
 Arbitrator
 Vendor
 Non-Related Person
 ...
 abbrev.
 CA   (Certification Authority)
 OCSP (On-line Certificate Status Protocol) - the protocol and server giving the quick informaton about revoked certificates based on their serial numbers
 CSR  (Certificate Signing Request) - user's utilities, as OpenSSL, XCA, and others, generate pairs of keys; one key of each pair is claimed as the private key and saved on user's machine; the other key with some added information about the user is usually given the PEM (Base64 coded) format and serves as the requeat to issue a certificate
 WoT  (Web of Trust) - 
 CRL  (Certificate Revoke List) - the list of revoked certificates
 AP   (Assurance Points) - points a member can collect by means of assurance appointments
 RSA: Rivest–Shamir–Adleman cryptography, developed 1978
 ECC: Elliptic Curve Cryptography - gives greater cryptographic strength then RSA at equivalent key size, developed 1985
 DN   Distinguished Name
 X.509v3
--- a/CAcertCommunityAgreement.html
+++ b/CAcertCommunityAgreement.html
@ -1,779 +0,0 @@
 <?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>
 <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" />
 <title> CAcert Community Agreement </title>
 <style type="text/css">
 <!--
 .comment {
        color : steelblue;
 }
 .first-does-not-work {
        color : red;
 }
 .q {
        color : green;
        font-weight: bold;
        text-align: center;
        font-style:italic;
 }
 .change {
        color : blue;
        font-weight: bold;
 }
 .change2 {
        color : mediumaquamarine;
 		font-weight: bold;
 }
 .change3 {
        color : Chartreuse;
 		font-weight: bold;
 }
 .change4 {
        color : darkcyan;
 	font-weight: bold;
 }
 .change5 {
        color : green;
 	font-weight: bold;
 }
 .change6 {
        color : orange;
 	font-weight: bold;
 }
 .change7 {
        color : lightSalmon ;
 	font-weight: bold;
 }
 .change8 {
        color : deepPink;
 	font-weight: bold;
 }
 .change9 {
        color : darkblue;
 	font-weight: bold;
 }
 .change10 {
        color : indianRed;
 	font-weight: bold;
 }
 .change11 {
        color : cornflowerBlue;
 	font-weight: bold;
 }
 .change12 {
        color : purple;
 	font-weight: bold;
 }
 .change13 {
        color : lightGreen;
 	font-weight: bold;
 }
 .strike {
        color : blue;
        text-decoration:line-through;
 }
 .strike2 {
        color : mediumaquamarine;
        text-decoration:line-through;
 }
 .strike4 {
        color : darkcyan;
        text-decoration:line-through;
 }
 .strike5 {
        color : green;
        text-decoration:line-through;
 }
 .strike6 {
        color : orange;
        text-decoration:line-through;
 }
 .strike7 {
        color : lightSalmon;
        text-decoration:line-through;
 }
 .strike8 {
        color : deepPink;
        text-decoration:line-through;
 }
 .strike9 {
        color : darkblue;
        text-decoration:line-through;
 }
 .strike10 {
        color : indianRed;
        text-decoration:line-through;
 }
 .strike11 {
        color : cornflowerBlue;
        text-decoration:line-through;
 }
 .strike12 {
        color : purple;
        text-decoration:line-through;
 }
 .strike13 {
        color : lightGreen;
        text-decoration:line-through;
 }
 -->
 </style>
 </head>
 <body>
        <p style="text-align: center;">
        <big>
        <br /><b>WARNING:</b><br />
        The proper policy document is located<br />
        <a href="//www.cacert.org/policy/CAcertCommunityAgreement.php">
        on the CAcert website </a>.<br />
        </big>
        This document is a <b>work-in-progress</b> to include future revisions only,<br />
        and is currently <b>only relevant for the [policy] group</b>.<br />
        <span class="change">Additions in COLOR</span>  <span class="strike">strikes in COLOR</span> <!--now up for <a href="//wiki.cacert.org/PolicyDecisions#p20101009">vote in PG</a>,.<br />-->
        </p>
    <a href="http://validator.w3.org/check?uri=referer"><img style="float: right; border-width: 0" src="http://www.w3.org/Icons/valid-xhtml11" alt="Valid XHTML 1.1" height="31" width="88" /></a>
     <ul>
        <li>Benedikt<span class="change2">20140215</span>: 
 			<ol>
 				<li> header: to match current PoP requirements</li>
 				<li>1.1: Opend the options to accept CCA by other ways than the listed ones</li>
 			</ol>
 		</li>
 		<li>Benedikt <span class="change">20140330</span> merged with 20140401 which was an update to this: 
 			<ol>
 				<li>1.1: Clarified the general character of CCA as general terms and conditions</li>
 				<li>1.3: Updated with additional cases</li>
 				<li>1.3: Changed "privacy related data" to "personal data"</li>
 			</ol>
 		</li>
 		<li>Ian <span class="change3">20140405</span>(original version and idea from Ted as 20140329, added "with" by Eva): 
 			<ol>
 				<li>2.3: Included obligation to assist truthfully in Arbitration with truthful information (This obligation already can be derived from DRP 2.6.2)</li>
 			</ol>
 		</li>
        <li>Marcus <span class="change5">20140407</span>: 
 			<ol>
 				<li>3.3: We should not use the online forum for any support request containing personal data as the online forum is open for everyone.</li>
 			</ol>
 		</li>
        <li>Eva <span class="change6">20140417</span>: 
 			<ol>
 				<li>3.5: CAcert is not limited to use primary email-address, if other contact forms are more sensible.</li>
 			</ol>
 		</li>		
 		<li>Eva <span class="change7">20140501.1</span> updated at 20140514 and 20140602:
 			<ol>
 				<li>0.1: Remove references to withdrawn policy</li>
 				<li>2.3: Ban of sharing of accounts.</li>
 			</ol>
 		</li>		
 		<li>Benedikt <span class="change9">20140504.1</span>: 
 			<ol>
 				<li>4.3: Review </li>
 				<li>4.4: Remove </li>
 			</ol>
 		</li>		
 		<li>Benedikt <span class="change11">20140508.2</span>: 
 			<ol>
 				<li>4.2: Review (drop Links to selection of policies)</li>
 			</ol>
 		</li>	
 		<li>Benedikt <span class="change4">20140515</span>: 
 			<ol>
 				<li>0.1: Remove reference to policy in WIP status</li>
 			</ol>
 		</li>
 		<li>Eva <span class="change10">20140522</span>: 
 			<ol>
 				<li>4.1: Remove </li>
 			</ol>
 		</li>			
 		<li>Eva <span class="change12">20140602</span>: 
 			<ol>
 				<li>3.3: other termination reasons added, rephrased</li>
 				<li>3.3a: consequences of termination, added</li>
 			</ol>
 		</li>	
 		<li>Eva <span class="change8">20140705.2</span>: 
 			<ol>
 				<li>2.5: Clarify context of allowed certificte usage (as in CPS) </li>
 			</ol>
 		</li>	
     </ul>
  <hr />
 <div class="comment">
 <table width="100%">
 <tr>
 <td rowspan="2">
  Name: CCA <a style="color: steelblue" href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">COD9</a><br />
  Status: WIP<br />
  Editor: <a style="color: steelblue" href="https://wiki.cacert.org/Community/HomePagesMembers/BenediktHeintel">Benedikt</a><br />
  Licence: <a style="color: steelblue" href="https://wiki.cacert.org/Policy#Licence" title="this document is Copyright &copy; CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP.  More at wiki.cacert.org/Policy">CC-by-sa+DRP</a><br />
 </td>
 <td valign="top" align="right">
  <a href="https://www.cacert.org/policy/PolicyOnPolicy.php"><img src="images/cacert-policy.png" alt="CCA Status - POLICY" height="31" width="88" style="border-style: none;" /></a>
 <!-- XXXXXXXXXXXXXX delete this going to DRAFT -->
 <br />
  <a href="https://www.cacert.org/policy/PolicyOnPolicy.php"><img src="images/cacert-wip.png" alt="CCA Status - WIP" height="31" width="88" style="border-style: none;" /></a>
 </td>
 </tr>
 </table>
 </div>
 <h2> CAcert Community Agreement </h2>
 <h3> <a name="0"> 0. </a>  Introduction </h3>
 <p>
 This agreement is between
 you, being a registered member ("Member")
 within CAcert's community at large ("Community")
 and CAcert Incorporated ("CAcert"),
 being an operator of services to the Community.
 </p>
 <h4> <a name="0.1"> 0.1 </a>  Terms </h4>
 <ol><li>
    "CAcert"
    means CAcert Inc.,
    a non-profit Association of Members.
    Note that Association Members are distinct from
    the Members defined here.
  </li><li>
    "Member"
    means you, a registered participant within CAcert's Community,
    with an account on the website and the
    facility to request certificates.
    Members may be individuals ("natural persons")
    or organisations ("legal persons").
  </li><li>
    "Organisation"
    is defined under the Organisation Assurance programme,
    and generally includes corporations and other entities
    that become Members and become Assured.
  </li><li>
    "Community"
    means all of the Members
    that are registered by this agreement
    and other parties by other agreements,
    all being under CAcert's Arbitration.
  </li><li>
    "Non-Related Person" ("NRP"),
    being someone who is not a
    Member, is not part of the Community,
    and has not registered their agreement.
    <span class="strike7">Such people are offered the NRP-DaL
    another agreement allowing the USE of certificates.</span>
  </li><li>
    <span class="strike7">"Non-Related Persons - Disclaimer and Licence" ("NRP-DaL"),
    another agreement that is offered to persons outside the
    Community.</span><span class="change7">(withdrawn)</span>
  </li><li>
    "Arbitration"
    is the Community's forum for
    resolving disputes, or jurisdiction.
  </li><li>
    "Dispute Resolution Policy" ("DRP" => COD7)
    is the policy and
    rules for resolving disputes.
  </li><li>
    "USE"
    means the act by your software
    to conduct its tasks, incorporating
    the certificates according to software procedures.
  </li><li>
    "RELY"
    means your human act in taking on a
    risk and liability on the basis of the claim(s)
    bound within a certificate.
  </li><li>
    "OFFER"
    means the your act
    of making available your certificate to another person.
    Generally, you install and configure your software
    to act as your agent and facilite this and other tasks.
    OFFER does not imply suggestion of reliance.
  </li><li>
    "Issue"
    means creation of a certificate by CAcert.
    To create a certificate,
    CAcert affixes a digital signature from the root
    onto a public key and other information.
    This act would generally bind a statement or claim,
    such as your name, to your key.
  </li><li>
    "Root"
    means CAcert's top level key,
    used for signing certificates for Members.
    In this document, the term includes any subroots.
  </li><li>
    "CAcert Official Document" ("COD" <span class="strike4">=> COD3</span>)
    <span class="strike4">in a standard format for describing the details of
    operation and governance essential to a certificate authority.
    Changes are managed and controlled.
    CODs define more technical terms.
    See 4.2 for listing of relevant CODs.</span>
 	<span class="change4"> is an official managed and
 controlled document (e. g. a Policy) of CAcert.</span>
  </li><li>
    "Certification Practice Statement" ("CPS" => COD6)
    is the document that controls details
    about operational matters within CAcert.
 </li></ol>
 <h3> <a name="1"> 1. </a>  Agreement and Licence </h3>
 <h4> <a name="1.1"> 1.1 </a>  Agreement </h4>
 <p>You <span class="strike">and CAcert both</span> agree to the terms and conditions in this agreement. Your agreement is given by <span class="change2"> but not limited to</span> <span class="strike2">any of</span></p>
 <ul><li>
    your signature on a form to request assurance of identity
    ("CAP" form),
  </li><li>
    your request on the website
    to join the Community and create an account,
  </li><li>
    your request for Organisation Assurance,
  </li><li>
    your request for issuing of certificates, or
  </li><li>
    if you USE, RELY, or OFFER
    any certificate issued to you.
 </li></ul>
 <p>
 Your agreement
 is effective from the date of the first event above
 that makes this agreement known to you.
 This Agreement
 replaces and <span class="strike2"> supercedes prior agreements,
 including the NRP-DaL.</span> <span class="change2">supersedes any prior agreements.</span>
 </p>
 <h4> <a name="1.2"> 1.2 </a>  Licence </h4>
 <p>
 As part of the Community, CAcert offers you these rights:
 </p>
 <ol><li>
    You may USE any certificates issued by CAcert.
  </li><li>
    You may RELY on any certificate issued by CAcert,
    as explained and limited by CPS (COD6).
  </li><li>
    You may OFFER certificates issued to you by CAcert
    to Members for their RELIANCE.
  </li><li>
    You may OFFER certificates issued to you by CAcert
    to NRPs for their USE, within the general principles
    of the Community.
  </li><li>
    This Licence is free of cost,
    non-exclusive, and non-transferrable.
 </li></ol>
 <h4> <a name="1.3"> 1.3 </a>  Your Contributions </h4>
 <p>
 You agree to a non-exclusive non-restrictive non-revokable
 transfer of Licence to CAcert for your contributions.
 That is, if you post an idea or comment on a CAcert forum,
 or email it to other Members,
 your work can be used freely by the Community for
 CAcert purposes, including placing under CAcert's licences
 for wider publication.
 </p>
 <p>
 You retain authorship rights, and the rights to also transfer
 non-exclusive rights to other parties.
 That is, you can still use your
 ideas and contributions outside the Community.
 </p>
 <p>
 Note that the following exceptions override this clause:
 </p>
 <ol><li>
    Contributions to controlled documents are subject to
    Policy on Policy ("PoP" => COD1)
  </li><li>
    Source code is subject to an open source licence regime.
 </li>
 	<li><span class="change">Personal data</span></li>
 	<li><span class="change">Postings under competing licenses if clearly stated when posted<span></li>
 </ol>
 <h4> <a name="1.4"> 1.4 </a>  Privacy </h4>
 <p>
 You give rights to CAcert to store, verify and process
 and publish your data in accordance with policies in force.
 These rights include shipping the data to foreign countries
 for system administration, support and processing purposes.
 Such shipping will only be done among
 CAcert Community administrators and Assurers.
 </p>
 <p>
 Privacy is further covered in the Privacy Policy ("PP" => COD5).
 </p>
 <h3> <a name="2"> 2. </a>  Your Risks, Liabilities and Obligations </h3>
 <p>
 As a Member, you have risks, liabilities
 and obligations within this agreement.
 </p>
 <h4> <a name="2.1"> 2.1 </a>  Risks </h4>
 <ol><li>
    A certificate may prove unreliable.
  </li><li>
    Your account, keys or other security tools may be
    lost or otherwise compromised.
  </li><li>
    You may find yourself subject to Arbitration
    (DRP => COD7).
 </li></ol>
 <h4> <a name="2.2"> 2.2 </a>  Liabilities </h4>
 <ol><li>
    You are liable for any penalties
    as awarded against you by the Arbitrator.
  </li><li>
    Remedies are as defined in the DRP (COD7).
    An Arbitrator's ruling may
    include monetary amounts, awarded against you.
  </li><li>
    Your liability is limited to
    a total maximum of
    <b>1000 Euros</b>.
  </li><li>
    "Foreign Courts" may assert jurisdiction.
    These include your local courts, and are outside our Arbitration.
    Foreign Courts will generally refer to the Arbitration
    Act of their country, which will generally refer
    civil cases to Arbitration.
    The Arbitration Act will not apply to criminal cases.
 </li></ol>
 <h4> <a name="2.3"> 2.3 </a>  Obligations </h4>
 <p>
    You are obliged
 </p>
 <ol><li>
    to provide accurate information
    as part of Assurance.
    You give permission for verification of the information
    using CAcert-approved methods.
  </li><li>
    to make no false representations.
  </li><li>
    to submit all your disputes to Arbitration
    (DRP => COD7).
 </li><span class="change3"><li>
    to assist the Arbitrator by truthfully providing information, or with any other reasonable request.
 </li></span>
 <span class="change7"><li>
    to not share your CAcert account.
 </li></span></ol>
 <h4> <a name="2.4"> 2.4 </a>  Principles </h4>
 <p>
 As a Member of CAcert, you are a member of
 the Community.
    You are further obliged to 
    work within the spirit of the Principles
    of the Community.
    These are described in
    <a href="http://svn.cacert.org/CAcert/principles.html">Principles of the Community</a>.
 </p>
 <h4> <a name="2.5"> 2.5 </a>  Security </h4>
 <p>
 CAcert exists to help you to secure yourself.
 You are primarily responsible for your own security.
 Your security obligations include
 </p>
 <ol><li>
    to secure yourself and your computing platform (e. g. PC),
  </li><li>
    to keep your email account in good working order,
  </li><li>
    to secure your CAcert account
    (e. g., credentials such as username, password),
  </li><li>
    to secure your private keys,<span class="change8"> ensuring that they are
 	only used as indicated by the certificate, or by wider agreement with others,</span>
  </li><li>
    to review certificates for accuracy,
    and
  </li><li>
    when in doubt, notify CAcert,
  </li><li>
    when in doubt, take other reasonable actions, such as
    revoking certificates,
    changing account credentials,
    and/or generating new keys.
 </li></ol>
 <p>
 Where, above, 'secure' means to protect to a reasonable
 degree, in proportion with your risks and the risks of
 others.
 </p>
 <h3> <a name="3"> 3. </a>  Law and Jurisdiction </h3>
 <h4> <a name="3.1"> 3.1 </a>  Governing Law </h4>
 <p>
 This agreement is governed under the law of
 New South Wales, Australia.
 </p>
 <h4> <a name="3.2"> 3.2 </a>  Arbitration as Forum of Dispute Resolution </h4>
 <p>
 You agree, with CAcert and all of the Community,
 that all disputes arising out
 of or in connection to our use of CAcert services
 shall be referred to and finally resolved
 by Arbitration under the rules within the
 Dispute Resolution Policy of CAcert
 (DRP => COD7).
 The rules select a single Arbitrator chosen by CAcert
 from among senior Members in the Community.
 The ruling of the Arbitrator is binding and
 final on Members and CAcert alike.
 </p>
 <p>
 In general, the jurisdiction for resolution of disputes
 is within CAcert's own forum of Arbitration,
 as defined and controlled by its own rules (DRP => COD7).
 </p>
 <p>
 We use Arbitration for many purposes beyond the strict
 nature of disputes, such as governance and oversight.
 A systems administrator may
 need authorisation to conduct a non-routine action,
 and Arbitration may provide that authorisation.
 Thus, you may find yourself party to Arbitration
 that is simply support actions, and you may file disputes in
 order to initiate support actions.
 </p>
 <h4> <a name="3.3"> 3.3 </a>  Termination </h4>
 <span class="strike12">
 <p>
 You may terminate this agreement by resigning from CAcert.  You may do this at any time by
 writing to CAcert's online support forum and filing dispute to resign.
 All services will be terminated, and your certificates will be revoked.
 However, some information will continue to be held for certificate processing purposes.
 </p>
 <p>
 The provisions on Arbitration survive any termination by you by leaving CAcert.
 That is, even if you resign from CAcert, you are still bound by the DRP (COD7),
 and the Arbitrator may reinstate any provision of this agreement or bind you to a ruling.
 </p>
 <p>
 Only the Arbitrator may terminate this agreement with you.
 </p>
 </span>
 <span class="change12">
 <p>The CAcert Community Agreement is terminated</p>
 <ol>
 	<li>based on a Policy Group decision following (PoP => COD1). This
 		terminates the Agreement with every member.</li>
 	<li>with a ruling of the Arbitrator or the completion of a termination
 		process defined by an Arbitrator ruling (DRP => COD7).</li>
 	<li>by the end of existence of a member (i.e. death in the case of
 		individuals).</li>
 </ol>
 <p>A member may declare the wish to resign from CAcert at any time by
 writing to <em>support AT cacert.org</em>. This triggers a process for
 termination of this agreement with the member.</p>
 <h4> <a name="3.3"> 3.3a </a> Consequences of Termination </h4>
 <p>The termination discontinues the right to USE, OFFER and CREATE
 personal certificates in any account of the former member. Those
 certificates will be revoked and all services to the former member will
 be terminated as soon as possible. However, some information will
 continue to be held for certificate processing purposes.</p>
 <p>The provisions on Arbitration for the time of membership survive any
 termination. Former members
 are still bound by the DRP (COD7), and the Arbitrator may reinstate any
 provision of this agreement or bind them to a ruling.</p>
 <p>As far as Organisations are concerned details are also defined in the
 Organisation Assurance Policy (OAP => COD11).</p>
 <p>Every member learning about the death of a member or termination of
 existence of a member should notify <em>support AT cacert.org</em>.</p>
 </span>
 <h4> <a name="3.4"> 3.4 </a>  Changes of Agreement </h4>
 <p>
 CAcert may from time to time vary the terms of this Agreement.
 Changes will be done according to the documented CAcert policy
 for changing policies, and is subject to scrutiny and feedback
 by the Community.
 Changes will be notified to you by email to your primary address.
 </p>
 <p>
 If you do not agree to the changes, you may terminate as above.
 Continued use of the service shall be deemed to be agreement
 by you.
 </p>
 <h4> <a name="3.5"> 3.5 </a>  Communication </h4>
 <p><span class="change6">
 You are responsible for keeping your primary email account in good working order and able to receive emails from CAcert.</span></p>
 <p>Notifications to CAcert are to be sent by email to the address <em>support AT cacert.org</em>. You should attach a digital signature<span class="strike6">, but need not do so in the event of security or similar urgency</span>.</p>
 <span class="strike6">
 <p>Notifications to you are sent by CAcert to the primary email address registered with your account. You are responsible for keeping your email account in good working order and able to receive emails from CAcert.</p>
 <p>Arbitration is generally conducted by email.</p></span>
 <h3> <a name="4"> 4. </a> Miscellaneous </h3>
 <h4> <a name="4.1"> 4.1 </a> <span class="strike10">Other Parties Within the Community</span> <span class="change10">(withdrawn)</span></h4>
 <p class="strike10">
 As well as you and other Members in the Community,
 CAcert forms agreements with third party
 vendors and others.
 Thus, such parties will also be in the Community.
 Such agreements are also controlled by the same
 policy process as this agreement, and they should
 mirror and reinforce these terms.
 </p>
 <h4> <a name="4.2"> 4.2 </a>  References and Other Binding Documents </h4>
 <p class="strike11">
 This agreement is CAcert Official Document 9 (COD9)
 and is a controlled document.
 </p>
 <p>
 You are also bound by 
 <span class="change11">
 the Policies of the Community under the control of Policy on Policy ("PoP" => COD1) and listed in
 <a href="https://svn.cacert.org/CAcert/Policies/ControlledDocumentList.html">Controlled Document List</a>.
 </span>
 </p>
 <span class="strike11">
 <ol><li>
    <a href="http://www.cacert.org/policy/CertificationPracticeStatement.php">
    Certification Practice Statement</a> (CPS => COD6).
  </li><li>
    <a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">
    Dispute Resolution Policy</a> (DRP => COD7).
  </li><li>
    <a href="PrivacyPolicy.html">
    Privacy Policy</a> (PP => COD5).
  </li><li>
    <a href="http://svn.cacert.org/CAcert/principles.html">
    Principles of the Community</a>.
 </li></ol>
 </span>
 <p class="strike11">
 Where documents are referred to as <i>=> COD x</i>,
 they are controlled documents
 under the control of Policy on Policies (COD1).
 </p>
 <p class ="strike11">
 This agreement and controlled documents above are primary,
 and may not be replaced or waived except
 by formal policy channels and by Arbitration.
 </p>
 <p class="change11">
 Controlled documents are primary, and may not be replaced or waived except by formal policy
 channels and Arbitration.
 </p>
 <p class="change11">
 This agreement is controlled document COD9.
 </p>
 <h4> <a name="4.3"> 4.3 </a>  Informative References </h4>
 <p>
 The governing documents are in English. Documents may be translated for convenience. 
 Because we cannot control the legal effect of translations, the English documents are the ruling ones.
 </p>
 <p class="strike9">
 You are encouraged to be familiar with the Assurer Handbook,
 which provides a more readable introduction for much of the information needed.
 The Handbook is not however an agreement, and is overruled
 by this agreement and others listed above.
 </p>
 <p class="change9">
 Beside this Agreement and the Policies, there are other documents, i.
 e. Policy Guides, Manuals and Handbooks, supporting and explaining this
 Agreement and the Policies. These documents are not binding and in doubt
 this Agreement and the Policies are valid.</p>
 <h4> <a name="4.4"> 4.4 </a> <span class="strike9">Not Covered in this Agreement</span> <span class="change9">(withdrawn)</span></h4>
 <p class="strike9">
 <b>Intellectual Property.</b>
 This Licence does not transfer any intellectual property rights ("IPR") to you.  CAcert asserts and
 maintains its IPR over its roots, issued certificates, brands, logos and other assets.
 Note that the certificates issued to you are CAcert's intellectual property
 and you do not have rights other than those stated.
 </p>
 </body>
 </html>
--- a/remarks.md
+++ b/remarks.md
@ -0,0 +1,574 @@
 # 00. X.509 certificates and their properties
 ## 01. The directives for certificates
 are given by the CA/Browser Forum (CAB). The following text reflects their
 conclusion concerning certificates valid for the year 2024.
 ## 02. Tree types (types of ciphering)
 * RSA: Rivest–Shamir–Adleman cryptography, developed 1978
 * ECC: Elliptic Curve Cryptography - gives greater cryptographic strength then RSA at equivalent key size, developed 1985 
 The RSA type tree is the subject of the following text.
 ## 03. Tree structure (see Fig. 1)
 * Root CA certificate (Root CA certificate) (06.)
 * Subordinate CA certificates (Subroots, intermediate certs, 08.-10.) for issuing end certificates of different types of purposes e.g. Email, Server, Personal Signing, login to various servers and/or applications, and more; issued only by the Root CA certificate; every Subordinate CA certificate has its own Certificate Revoke List (CRL)
 * End Certificates issued only by corresponding Subordinate CA certificates (12.-17.), for use with e.g. Email, Server, Personal Signing, login to various servers and/or applications, and more.
 So the certificate chain has its length of 3: Root CA certificate -> Subordinate CA certificate -> End certificate.
 ## 04. The Subjects for CAcert should contain
 L=Genève PostalCode=1208 STREET=Clos Belmont 2                              (Location)
 O=CAcert Inc.                                                               (Organization)
 C=CH                                                                        (Country)
 CN=CAcert {Root|PersonA|PersonU|ClientA|ClientU|ServerA|ServerU} CA <year>  (Common Name)
 OU=http://www.cacert.org                                                    (Org.Unit)
 (Note: OU for CAcert was used in old certs, but it is considered as deprecated now.)
 The Issuer Distinguished Name item in Subordinate CA certificates (Subroots) is equal to Subject Distinguished Name (Subject DN) and Issuer Distinguished Name (Issuer DN) of the Root CA certificate (Main Root).
 The Issuer DN item in Patterns (see below) is equal to Subject DN in the respective Subordinate CA cert.
 ## 05. RSA types - X.509v3; all texts are coded UTF-8
 There are 2 sets suggested per 3 Subordinate CA certificates each. The 1st set is used for CAcert *assured* members, the 2nd set is used for CAcert members who are *unassured* yet. 
 A Member status is classified as follows (APs, see COD13 - Assurance Policy #2.3):
 * Status *unassured*: 0 to 49 Assurance Points (APs).
 * Status *assured*: 50 to 100+ APs.
 * Status *Assurer*: 100+ APs and the *Assurer Challenge* test passed.
 (Some differences can also be done for an user having the Assurer status.)
 Set #1: 3 subordinate CA certificates for issuing certs for assured members:
         (1) Person-assured; (2) Client-assured; (3) Server-assured
 Set #1a: 3 subordinate CA certificates for issuing certs for organizations:
         These are basically identical to the set #1, only differ in their Subject DN
         there are parameters L=, O=, C=, CN=, and OU= concerning the organization
         which the subordinate CA certificate is issued for.
 Set #2: 3 subordinate CA certificates for issuing certs for unassured members:
         (1) Person-unassured; (2) Client-unassured; (3) Server-unassured
 Every set consists of 3 Subordinate CA certs: Person, Client, and Server.
 "Person" is designed for real people. It provides person name, Email
 address(es) as SAN, and possibly the document/code signing ability.
 "Client" is designed to be used for machines that act as a client and needs to authenticate to other systems, client certificates contain SAN DNS names and may contain a single host name in the Subject DN Common Name (CN) field. SAN are possible.
 "Server" is designed to be used for machines that need to authenticate to relying parties, server certificates contain SAN DNS names and may contain a single host name in the Subject DN Common Name (CN) field. SAN are possible.
 ## 06. Properties of the Root CA certificate
 * Cert version: 3 (X.509v3)
 * Serial number: random number, length is 16 Bytes (CAB recommendation)
 * Signature Algorithm: sha256WithRSAEncryption
 * Signature Algorithm Hash: (sha256) implied by the signature algorithm
 * Issuer DN: C=<country>,L=<Location>,O=<organization>,CN=<Common_Name>
 * Validity (Not Before & Not After), Duration = 20 years (CAB recommendation)
 * Subject DN: as this is the Root CA, this item is equal to the Issuer DN item
 * Subject Public Key Info
  * Public Key Algorithm: RSAEncryption *(implied by the public key)*
   * RSA Public-Key: (4096 bit), then the Modulus value, Exponent 65537 (0x10001)
   * Public Key Parameters: 05 00
 * X509v3 Extensions
 * X509v3 Key Usage (critical)
  * Certificate (only subordinate CA certificates) Signing, CRL Signing; Offline CRL Signing
 * X509v3 Basic Constraints (critical)
  * Certificate of a CA: true
  * Path length restriction: none
 * X509v3 Subject Key Identifier (20 Byte ID)
 * Signature Algorithm: sha256WithRSAEncryption
 * Fingerprint: 20 Bytes *(fingerprint is dependent on the used hash algorithm,
  a certificate's TBSCertificate structure can be hashed/fingerprinted using
  any hash algorithm. 20 Bytes is what a SHA1 hash produces, it can be longer
  or shorter for other algorithms and is not directly included in the
  certificate)*
 ## 07. (removed, merged with 05.))
 ## 08. Properties of the "Person-assured" & "Person-unassured Subordinate CA certificates (Subroots, Intermediate Roots)
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: C=<Country>,L=<Location>,O=<Organization>,CN=<Common_Name>; if org., OU=<Org.Unit>
 Validity (Not Before & Not After), Duration = 5 years
 Subject DN (if the Organization Assurer, see the comment to the 05., Set #1a):
    C= (see 04. above)
    L= (see 04. above)
    O= (see 04. above)
    for "Person-assured": CN=CAcert Person-assured CA <year>
    for "Person-unassured": CN=CAcert Person-unassured CA <year>
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001)
   Public Key Parameters: 05 00 (i.e. NULL, see RFC 4055 # 1.2)
 X509v3 Extensions
  X509v3 Key Usage (critical)
   General Subordinate CA certificate purposes:
    Digital Signature, Certificate Signing, CRL Signing
 X509v3 Extended Key Usage: 
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
    Code signing (1.3.6.1.5.5.7.3.3) (for "Person-assured" only)
    Email protection (1.3.6.1.5.5.7.3.4)
    OCSP signing (1.3.6.1.5.5.7.3.9)
  X509v3 Basic Constraints: critical
   CA:TRUE, pathlen:0
  X509v3 Subject Key Identifier: (20 Byte ID)
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the Root CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
   URI:http://www.cacert.org/certs/rsa_root_<year>.crt (Root CA cert. file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/<CRL_file>:
     for "Person-assured": rsa_personA_<year>.crl
     for "Person-unassured": rsa_personU_<year>.crl
  Signature Algorithm: sha256WithRSAEncryption
  Fingerprint: 20 Bytes
 ## 09. Properties of the "Client-assured" & "Client-unassured" Subordinate CA certificates
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: C=<country>,L=<Location>,O=<Organization>,CN=<Common_Name>,OU=<Org.Unit>
 Validity (Not Before & Not After), Duration = 5 years
 Subject DN (if the Organization Assurer, see the comment to the 05., Set #1a):
    C= (see 04. above)
    L= (see 04. above)
    O= (see 04. above)
    for "Client-assured": CN=CAcert Client-assured CA <year>
    for "Client-unassured": CN=CAcert Client-unassured CA <year>
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001)
   Public Key Parameters: 05 00 (NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical)
   General Subordinate CA certificate purposes:
    Digital Signature, Certificate Signig, CRL Signing
 X509v3 Extended Key Usage:
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
    OCSP Signing (1.3.6.1.5.5.7.3.9)
  X509v3 Basic Constraints: critical
   CA:TRUE, pathlen:0
  X509v3 Subject Key Identifier: (20 Byte ID)
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the Root CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
   URI:http://www.cacert.org/certs/rsa_root_<year>.crt (Root CA cert. file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/<CRL_file>:
     for "Client-assured": rsa_clientA_<year>.crl
     for "Client-unassured": rsa_clientU_<year>.crl
  Signature Algorithm: sha256WithRSAEncryption
  Fingerprint: 20 Bytes
 ## 10. Properties of the "Server-assured" & "Server-unassured" Subordinate CA certificates
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: C=<Country>,L=<Location>,O=<Organization>,CN=<Common_Name>,OU=<Org.Unit>
 Validity (Not Before & Not After), Duration = 5 years
 Subject DN (derived from Issuer, varies in Subject: CN=name-reflecting-purpose)
            (if the Organization Assurer, see the comment to the 05., Set #1a)
    C= (see 04. above)
    L= (see 04. above)
    O= (see 04. above)
    for "Server-assured": CN=CAcert Server-assured CA <year>
    for "Server-unassured": CN=CAcert Server-unassured CA <year>
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001)
   Public Key Parameters: 05 00 (= NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical)
   General Subroot purposes:
    Digital Signature, Certificate Signing, CRL Signing
 X509v3 Extended Key Usage:
    TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
    OCSP Signing (1.3.6.1.5.5.7.3.9)
  X509v3 Basic Constraints: critical
   CA:TRUE, pathlen:0
  X509v3 Subject Key Identifier: (20 Byte ID)
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the Root CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
 - URI:http://www.cacert.org/certs/rsa_root_<year>.crt (Root CA cert. file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/<CRL_file>:
     for "Server-assured": rsa_serverA_<year>.crl
     for "Server-unassured": rsa_serverU_<year>.crl
  Signature Algorithm: sha256WithRSAEncryption
  Fingerprint: 20 Bytes
 ## 11. Users' (end) certificates
 These are issued by (signed with) Subordinate CA certificates only. Some properties are constant for those certs, some differ according to the respective Subordinate CA certificate only, and some depends on the user's data. That's why it seems to be a good idea to
 design the patterns for certs issued.
 ## 12. The proposal of the pattern "Person-assured"
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes; source: Signer
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: equal to the "Person-assured" Subordinate CA certificate's Subject; source: "Person-assured" Subordinate CA certificate  Validity (Not Before & Not After), Duration = 1 year (CAB recommandation)
 Subject DN: CN = real_name of the user, E = Email address(es); source: user's account
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001); source: CSR
   Public Key Parameters: 05 00 (NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical):
   Digital Signature, Key Encipherment, Key Agreement
  X509v3 Extended Key Usage: (source: "Person-assured" Subordinate CA certificate, and the user's account)
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
    Code signing (1.3.6.1.5.5.7.3.3); TRUE/FALSE, source: user's account
    Email protection (1.3.6.1.5.5.7.3.4)
  X509v3 Basic Constraints: critical
   CA:FALSE
  X509v3 Subject Key Identifier: (20 Byte ID); source: CSR
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the "Person-assured" Subordinate CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
 - URI:http://www.cacert.org/certs/rsa_personA_<year>.crt ("Person-assured" Subordinate CA certificate file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/rsa_personA_<year>.crl ("Person-assured" Subordinate CA certificate CRL file)
 Signature Algorithm: sha256WithRSAEncryption
 Fingerprint: 20 Bytes
 For 1 or more verified (and selected by the user) Email address(es) a SAN string will be added; (source: user's account & user's selection).
 ## 13. The proposal of the pattern "Person-unassured"
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes; source: Signer
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: equal to the "Person-unassured" Subordinate CA certificate's Subject; source: "Person-unassured" Subordinate CA certificate
 Validity (Not Before & Not After), Duration = 6 months
 Subject DN: CN = "CAcert WoT User" OR "<user's name> (unassured)", E = Email address(es); source: user's account
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001); source: CSR
   Public Key Parameters: 05 00 (NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical):
   Digital Signature, Key Encipherment, Key Agreement
  X509v3 Extended Key Usage: (source: "Person-unassured" Subordinate CA certificate)
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
    Email protection (1.3.6.1.5.5.7.3.4)
  X509v3 Basic Constraints: critical
   CA:FALSE
  X509v3 Subject Key Identifier: (20 Byte ID); source: CSR
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the "Person-unassured" Subordinate CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
 - URI:http://www.cacert.org/certs/rsa_personU_<year>.crt ("Person-unassured" Subordinate CA certificate file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/rsa_personU_<year>.crl ("Person-unassured" Subordinate CA certificate CRL file)
 Signature Algorithm: sha256WithRSAEncryption
 Fingerprint: 20 Bytes
 For 1 or more verified (and selected by the user) Email address(es) a SAN string will be added; (source: user's account & user's selection).
 ## 14. The proposal of the pattern "Client-assured"
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes; source: Signer
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: equal to the "Client-assured" Subordinate CA certificate's Subject; source: "Client-assured" Subordinate CA certificate
 Validity (Not Before & Not After), Duration = 1 year (CAB recommandation)
 Subject DN: CN = client's FQDN; source: user's account
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001); source: CSR
   Public Key Parameters: 05 00 (NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical):
   Digital Signature, Key Encipherment, Key Agreement
  X509v3 Extended Key Usage: (source: "Client-assured" Subordinate CA certificate)
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
  X509v3 Basic Constraints: critical
   CA:FALSE
  X509v3 Subject Key Identifier: (20 Byte ID); source: CSR
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the "Client-assured" Subordinate CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
 - URI:http://www.cacert.org/certs/rsa_clientA_<year>.crt ("Client-assured" Subordinate CA certificate file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/rsa_clientA_<year>.crl ("Client-assured" Subordinate CA certificate CRL file)
 Signature Algorithm: sha256WithRSAEncryption
 Fingerprint: 20 Bytes
 For 1 or more verified (and selected by the user) domains -> FQDNs a SAN string will be added; (source: user's account & user's selection).
 ## 15. The proposal of the pattern "Client-unassured"
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes; source: Signer
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: equal to the "Client-unassured" Subordinate CA certificate's Subject; source: "Client-unassured" Subordinate CA certificate
 Validity (Not Before & Not After), Duration = 6 months
 Subject DN: CN = client's FQDN; source: user's account
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001); source: CSR
   Public Key Parameters: 05 00 (NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical):
   Digital Signature, Key Encipherment, Key Agreement
  X509v3 Extended Key Usage: (source: "Client-unassured" Subordinate CA certificate)
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
 X509v3 Basic Constraints: critical
   CA:FALSE
  X509v3 Subject Key Identifier: (20 Byte ID); source: CSR
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the "Client-unassured" Subordinate CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
 - URI:http://www.cacert.org/certs/rsa_clientU_<year>.crt ("Client-unassured" Subordinate CA certificate file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/rsa_clientU_<year>.crl ("Client-unassured" Subordinate CA certificate CRL file)
 Signature Algorithm: sha256WithRSAEncryption
 Fingerprint: 20 Bytes
 For 1 or more verified (and selected by the user) domains -> FQDNs a SAN string will be added; (source: user's account & user's selection).
 # 16. The proposal of the pattern "Server-assured"
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes; source: Signer
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: equal to the "Server-Assurer" Subordinate CA certificate's Subject; source: "Server-Assurer" Subordinate CA certificate
 Validity (Not Before & Not After), Duration = 1 year (CAB recommandation)
 Subject DN: CN = server's FQDN; source: user's account
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001); source: CSR
   Public Key Parameters: 05 00 (NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical):
   Digital Signature, Key Encipherment, Key Agreement
  X509v3 Extended Key Usage: (source: "Server-Assurer" Subordinate CA certificate)
    TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
   X509v3 Basic Constraints: critical
   CA:FALSE
  X509v3 Subject Key Identifier: (20 Byte ID); source: CSR
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the "Server-assured" Subordinate CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
 - URI:http://www.cacert.org/certs/rsa_serverA_<year>.crt ("Server-assured" Subordinate CA certificate file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/rsa_serverA_<year>.crl ("Server-Assurer" Subordinate CA certificate CRL file)
 Signature Algorithm: sha256WithRSAEncryption
 Fingerprint: 20 Bytes
 For 1 or more verified (and selected by the user) domains -> FQDNs a SAN string will be added; (source: user's account & user's selection).
 ## 17. The proposal of the pattern "Server-unassured"
 Cert version: 3 (X.509v3)
 Serial number: random number, length is 16 Bytes; source: Signer
 Signature Algorithm: sha256WithRSAEncryption
 Signature Algorithm Hash: sha256
 Issuer DN: equal to the "Server-nonAssurer" Subordinate CA certificate's Subject; source: "Server-nonAssurer" Subordinate CA certificate
 Validity (Not Before & Not After), Duration = 6 months
 Subject DN: CN = server's FQDN; source: user's account
 Subject Public Key Info
  Public Key Algorithm: RSAEncryption
   RSA Public-Key: (3072 bit), then the Modulus value, Exponent 65537 (0x10001); source: CSR
   Public Key Parameters: 05 00 (NULL)
 X509v3 Extensions
  X509v3 Key Usage (critical):
   Digital Signature, Key Encipherment, Key Agreement
  X509v3 Extended Key Usage: (source: "Server-unassured" Subordinate CA certificate)
    TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
   X509v3 Basic Constraints: critical
   CA:FALSE
  X509v3 Subject Key Identifier: (20 Byte ID); source: CSR
  Authority Key ID (20 Bytes ID, equal to the Subject Key ID of the "Server-unassured" Subordinate CA certificate)
  Authority Information Access (AIA): 
   OCSP (1.3.6.1.5.5.7.48.1) - URI:http://ocsp.cacert.org/
   CA Issuer (1.3.6.1.5.5.7.48.2)
 - URI:http://www.cacert.org/certs/rsa_serverU_<year>.crt ("Server-nonAssurer" Subordinate CA certificate file)
  X509v3 Certificate Policies: 
   Policy: 1.3.6.1.4.1.18506.2.3.1 (18506 = org. number, here: CAcert; 2.3.1 = CPS)
  X509v3 CRL Distribution Points: 
   Full Name:
    URI:http://crl.cacert.org/rsa_serverU_<year>.crl ("Server-nonAssurer" Subordinate CA certificate CRL file)
 Signature Algorithm: sha256WithRSAEncryption
 Fingerprint: 20 Bytes
 For 1 or more verified (and selected by the user) domains -> FQDNs a SAN string will be added; (source: user's account & user's selection).
 # Jan's comments:
 The Subroot "Person" should be used for identifying real people. Certificates
 issued by that Subordinat CA can be used to digitaly sign emails and documents
 and for identifying as that person in Web applications (i.e. for our OpenID
 Connect implementation or other applications that support client certificates
 for user authentication).
 For Person certificates the CN (Common Name) of the Subject DN should contain
 the Name as assured by CAcert. The person certificates should contain a user
 selected list of email addresses as RFC822 Subject Alternative Name extensions.
 We might still include emailAdress parts in the Subject DN, but this is
 deprecated. There are still some applications that expect email addresses
 there.
 The Subroot "Client" should be used for client certificate authentication, but
 more for machine-to-machine communication scenarios. From my point of view the
 SubjectDN should have a Common Name identifying a machine name or some
 arbitrary application identifier. An example could be "CAcert Assurer Training
 System" for our CATS system. The Subject Alternative Name might contain DNS
 names from domains that are assigned to a user or organisation. It may also
 contain RFC822 Subject Alternative Names (in case of some functional address
 that corresponds to an application, like "cats@cacert.org").
 The Subroot "Server" should be used for TLS server certificates. The CN of the
 SubjectDN could contain a hostname. These certificates must contain DNS Name
 Subject Alternative Names (at least one for the primary hostname, could be
 more). The hostnames should be from a verified domain of a user or
 organisation.
 I think it would be a good idea to have separate Sub CA certificates for users
 that have not been assured yet, to make it visible that these have been issued
 according to different rules (currently we use "WoT user" in their Subject DNs
 CN field). I think this separation would make it much clearer and would allow
 relying parties to only accept certificates that correspond to assured users
 without making assumptions on specific attributes of certificates.
 That would mean that we have at least 1 root CA certificate (maybe 2 if we
 would like to provide EC in addition to RSA). And 6 Sub CA certificates (3 for
 assured users, 3 for non-assured users).
 # Jan's remarks to ver. 2:
 ad # 04
 *Remark:* OU does not make a lot of sense here. There is no specific
  "Organizational Unit". The Critical team might be such a unit, but I would not include that in the Subject DNs of CA certificates.
 *Remark:* we should use the terms Issuer Distinguished Name (Issuer DN),
  Subject Distinguished Name (Subject DN), Root CA certificate and Subordinate CA certificate consistently
 ad # 05
 *Remark:* I think the first set is not for assurers but for assured members, the other set is for unassured members. Assurers are special in that they have enough assurance points and passed the required CATS exam to assure other members
 *Remark:* It may be a good idea to have a separate third set of Subordinate CA certificates to be used for organization certificates. In addition to the properties defined for personal certificates they could contain Organization (O) and optional Organizational Unit (OU) fields in the Subject DN field. ***
 ad # 06
 * Public Key Algorithm: RSAEncryption *(implied by the public key)*
 * Fingerprint: 20 Bytes *(fingerprint is dependent on the used hash algorithm,
  a certificate's TBSCertificate structure can be hashed/fingerprinted using
  any hash algorithm. 20 Bytes is what a SHA1 hash produces, it can be longer
  or shorter for other algorithms and is not directly included in the
  certificate)*
 ad # 07
 Remark*: Is there any new information to part 05 above? I would suggest to
  avoid duplication
 ad # 08
 *See remarks for Root CA and for the differentiation between assured-members
 and unassured-members above. I suggest to use Person (assured) vs. Person
 (unassured) or something similar in the Subordinate CA's Subject DN Common
 Name (CN) field*
 ad # 09
 *Same remarks as for the Root CA certificate and the Person CA certificates*
 ad # 10
 *Same remarks as for the Root CA certificate and the Person CA certificates*
 ad # 11
 *Remarks* we should use the standard term end-entity certificate
 ad # 12
 *Remarks*:
  * same remarks as for Root CA certificate and Subordinate CA certificates
  * for unassured person certificates I suggest to add a "(unassured)"
    suffix to the CN part of the Subject DN to make this fact explicit
  * OCSP signing EKU MUST NOT be included in end-entity certificates for users
 ad # 13
 *Remarks:*
  * same remarks as for "Person-assured"
  * as an alternative to "CAcert WoT User" we might use the member's real name
    with a suffix just as "(unassured)"
 ad # 14
 *Remarks:*
  * same as for CA and Person end-entity certificates
  * client certificates MUST NOT contain the OCSP Signing EKU
  * there might be client certificates for email addresses that belong to
    organizations (i.e. functional mailboxes), that is one of the reasons I
    recommend to create a set of organization Subordinate CA certificates in
    addition to the 2 proposed sets, such client certificates may need
    digitalSignature and emailProtections EKU in addition to client
    authentication
 ad # 15
 Remarks:*
  * same remarks as for "Person unassured"
  * OCSP signing EKU MUST NOT be included
  * SANs can only be DNS names (FQDNs) from domains that have been verified to
    be under control of the member
 ad # 16
 *Remarks:*
  * same remarks as for "Person assured"
  * OCSP signing EKU MUST NOT be included in general. OCSP signing may only be
    included in certificates that are issued for CAcert critical-team members.
    The web application needs an option to issue such certificates for CAcert
    critical admin team personal
  * SANs can only be DNS names (FQDNs) from domains that have been verified to
    be under control of the member
  * issuing of OCSP certificates is a very special case. Critical team members
    must be able to create OCSP signing certificates for each Subordinate CA.
    The EKU MUST NOT be added to any end-entity certificate for regular members
 ad # 17
 *Remarks:*
  * same remarks as for "Person unassured"
  * SANs can only be DNS names (FQDNs) from domains that have been verified to
    be under control of the member
--- a/PrivacyPolicy.txt
+++ b/PrivacyPolicy.txt
@ -72,7 +72,13 @@ ensures that valid authority is given to whoever complies with the supoena or th
 </p>
-<p><?=_("If you need to contact us in writing, address your mail to to the postal address of CAcert Inc. The current postal address of Cacert Inc. can be found on CAcert's web site.")?></p>
+<p><?=_("If you need to contact us in writing, address your mail to:")?></p>
 <p>
 CAcert Inc.<br>
 PO Box 66<br>
 Oatley NSW 2223<br>
 Australia
 </p>
--- a/RSA-tree.jpg
+++ b/RSA-tree.jpg