bug-1131: CertificationPracticeStatement.html strong
authorMartin Gummi <martin.gummi@gmx.net>
Tue, 30 Apr 2013 20:15:20 +0000 (22:15 +0200)
committerMartin Gummi <martin.gummi@gmx.net>
Tue, 30 Apr 2013 20:15:20 +0000 (22:15 +0200)
www/policy/CertificationPracticeStatement.html

index f840200..ddbdc17 100644 (file)
@@ -426,7 +426,7 @@ makes a decision on the basis of that certificate.
 <h4><a id="p1.3.5">1.3.5. Other participants</a></h4>\r
 \r
 <p>\r
-<b>Member.</b>\r
+<strong>Member.</strong>\r
 Membership of the Community is as defined in the\r
 <a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>.\r
 Only Members may RELY or may become Subscribers.\r
@@ -434,7 +434,7 @@ Membership is free.
 </p>\r
 \r
 <p>\r
-<b>Arbitrator.</b>\r
+<strong>Arbitrator.</strong>\r
 A senior and experienced Member of the CAcert Community\r
 who resolves disputes between Members, including ones\r
 of certificate reliance, under\r
@@ -443,14 +443,14 @@ Dispute Resolution Policy
 </p>\r
 \r
 <p>\r
-<b>Vendor.</b>\r
+<strong>Vendor.</strong>\r
 Software suppliers who integrate the root certificates of CAcert\r
 into their software also assume a proxy role of Relying Parties,\r
 and are subject to another licence.\r
 </p>\r
 \r
 <p>\r
-<b>Non-Related Persons</b> (NRPs).\r
+<strong>Non-Related Persons</strong> (NRPs).\r
 These are users of browsers and similar software who are\r
 unaware of the CAcert certificates they may use, and\r
 are unaware of the ramifications of usage.\r
@@ -621,7 +621,7 @@ for these applications:
 </p>\r
 \r
 <ul><li>\r
-    <b>Signing within Protocols.</b>\r
+    <strong>Signing within Protocols.</strong>\r
     Digital signatures made by CAcert certificates carry\r
     <u>NO default legal or human meaning</u>.\r
     See <a href="#p9.15.1">&sect;9.15.1</a>.\r
@@ -634,13 +634,13 @@ for these applications:
     is in use, to enable encryption, and to ensure the integrity\r
     of the email in transit.\r
 </li><li>\r
-    <b>Non-repudiation applications.</b>\r
+    <strong>Non-repudiation applications.</strong>\r
     Non-repudiation is not to be implied from use of\r
     CAcert certificates.  Rather, certificates may\r
     provide support or evidence of actions, but that\r
     evidence is testable in any dispute.\r
 </li><li>\r
-    <b>Ecommerce applications.</b>\r
+    <strong>Ecommerce applications.</strong>\r
     Financial transactions or payments or valuable e-commerce.\r
 </li><li>\r
     Use of anonymous (Class 1 or Member SubRoot) certificates\r
@@ -662,7 +662,7 @@ any harm or liability caused by such usage.
 </p>\r
 \r
 <p>\r
-    <b>Digital signing applications.</b>\r
+    <strong>Digital signing applications.</strong>\r
     CAcert client certificates\r
     may be used by Assured Members in\r
     applications that provide or support the human signing of documents\r
@@ -676,7 +676,7 @@ any harm or liability caused by such usage.
 <h4><a id="p1.4.5">1.4.5. Roots and Names</a></h4>\r
 \r
 <p>\r
-<b>Named Certificates.</b>\r
+<strong>Named Certificates.</strong>\r
 Assured Members may be issued certificates\r
 with their verified names in the certificate.  In this role, CAcert\r
 operates and supports a network of Assurers who verify the\r
@@ -686,7 +686,7 @@ method under policy (c.f. Organisations).
 </p>\r
 \r
 <p>\r
-<b>Anonymous Certificates.</b>\r
+<strong>Anonymous Certificates.</strong>\r
 Members can be issued certificates that are anonymous,\r
 which is defined as the certificate with no Name included,\r
 or a shared name such as "Community Member".\r
@@ -700,14 +700,14 @@ and messy process in order to get manufactured certificates.
 </p>\r
 \r
 <p>\r
-<b>Psuedonymous Certificates.</b>\r
+<strong>Psuedonymous Certificates.</strong>\r
 Note that CAcert does not currently issue pseudonymous certificates,\r
 being those with a name chosen by the Member and not verifiable\r
 according to documents.\r
 </p>\r
 \r
 <p>\r
-<b>Advanced Certificates.</b>\r
+<strong>Advanced Certificates.</strong>\r
 Members who are as yet unassured are not permitted to create\r
 advanced forms such as wildcard or subjectAltName\r
 certificates.\r
@@ -715,28 +715,28 @@ certificates.
 \r
 \r
 <p>\r
-<b> Roots.</b>\r
+<strong> Roots.</strong>\r
 The <span class="q"> (new) </span> CAcert root layout is as below.\r
 These roots are pending Audit,\r
 and will be submitted to vendors via the (Top-level) Root.\r
 </p>\r
 <ul><li>\r
-    <b>(Top-level) Root.</b>\r
+    <strong>(Top-level) Root.</strong>\r
     Used to sign on-line CAcert SubRoots only.\r
     This Root is kept offline.\r
   </li><li>\r
-    <b>Member SubRoot.</b>\r
+    <strong>Member SubRoot.</strong>\r
     For Community Members who are new and unassured (some restrictions exist).\r
     Reliance is undefined.\r
     (Replacement for the Class 1 root, matches "Domain Validation" type.)\r
   </li><li>\r
-    <b>Assured SubRoot.</b>\r
+    <strong>Assured SubRoot.</strong>\r
     Only available for Assured individual Members,\r
     intended to sign certificates with Names.\r
     Suitable for Reliance under this and other policies.\r
     Approximates the type known as Individual Validation.\r
   </li><li>\r
-    <b>Organisation SubRoot.</b>\r
+    <strong>Organisation SubRoot.</strong>\r
     Only available for Assured Organisation Members.\r
     Suitable for Reliance under this and other policies.\r
     Approximates the type known as Organisational Validation.\r
@@ -885,18 +885,18 @@ look at the CPS to figure it out.
 <div class="c figure">Table 1.4.5.  Certificates under Old Roots - <strong>Audit Fail</strong>  </div>\r
 \r
 <p>\r
-<b> Old Roots.</b>\r
+<strong> Old Roots.</strong>\r
 The old CAcert root layout is as below.  These roots are <strong>Audit Fail</strong>\r
 and will only be used where new roots do not serve:\r
 </p>\r
 <ul><li>\r
-    (old) <b>Class 1 root.</b>\r
+    (old) <strong>Class 1 root.</strong>\r
     Used primarily for certificates with no names and by\r
     unassured Members.\r
     For compatibility only,\r
     Assured Members may also use this root.\r
   </li><li>\r
-    (old) <b>Class 3 root.</b>\r
+    (old) <strong>Class 3 root.</strong>\r
     Used primarily for certificates including the names\r
     of Assured Members.\r
     Signed by Class 1 root.\r
@@ -968,20 +968,20 @@ As per above.
 <h3><a id="p1.6">1.6. Definitions and acronyms</a></h3>\r
 \r
 <p>\r
-<b><a id="d_cert">Certificate</a></b>.\r
+<strong><a id="d_cert">Certificate</a></strong>.\r
   A certificate is a piece of cryptographic data used\r
   to validate certain statements, especially those of\r
   identity and membership.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_cacert">CAcert</a></b>.\r
+<strong><a id="d_cacert">CAcert</a></strong>.\r
   CAcert is a Community certificate authority as defined under\r
   <a href="#p1.2">&sect;1.2 Identification</a>.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_member">Member</a></b>.\r
+<strong><a id="d_member">Member</a></strong>.\r
   Everyone who agrees to the\r
   CAcert Community Agreement\r
   (<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>).\r
@@ -992,7 +992,7 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="d_community">Community</a></b>.\r
+<strong><a id="d_community">Community</a></strong>.\r
   The group of Members who agree to the\r
   CAcert Community Agreement\r
   (<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>)\r
@@ -1000,37 +1000,37 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="d_unassured">Unassured Member</a></b>.\r
+<strong><a id="d_unassured">Unassured Member</a></strong>.\r
   A Member who has not yet been Assured.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_subscriber">Subscriber</a></b>.\r
+<strong><a id="d_subscriber">Subscriber</a></strong>.\r
   A Member who requests and receives a certificate.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_assured">Assured Member</a></b>.\r
+<strong><a id="d_assured">Assured Member</a></strong>.\r
   A Member whose identity has been sufficiently\r
   verified by Assurers or other\r
   approved methods under Assurance Policy.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_assurer">Assurer</a></b>.\r
+<strong><a id="d_assurer">Assurer</a></strong>.\r
   An Assured Member who is authorised under Assurance Policy\r
   to verify the identity of other Members.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_name">Name</a></b>.\r
+<strong><a id="d_name">Name</a></strong>.\r
     As defined in the\r
     Assurance Policy\r
     (<a href="https://www.cacert.org/policy/AssurancePolicy.html">COD13</a>),\r
     to describe a name of a Member\r
     that is verified by the Assurance process.\r
 <p>\r
-<b><a id="d_oadmin">Organisation Administrator</a></b>.\r
+<strong><a id="d_oadmin">Organisation Administrator</a></strong>.\r
   ("O-Admin")\r
   An Assurer who is authorised to act for an Organisation.\r
   The O-Admin is authorised by an organisation\r
@@ -1038,13 +1038,13 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="d_org_ass">Organisation Assurer</a></b>.\r
+<strong><a id="d_org_ass">Organisation Assurer</a></strong>.\r
   An Assurer who is authorised to conduct assurances on\r
   organisations.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_user">Non-Related Persons</a></b>.\r
+<strong><a id="d_user">Non-Related Persons</a></strong>.\r
   ("NRPs")\r
   are general users of browsers and similar software.\r
   The NRPs are generally unaware of\r
@@ -1055,7 +1055,7 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="d_reliance">Reliance</a></b>.\r
+<strong><a id="d_reliance">Reliance</a></strong>.\r
   An industry term referring to\r
   the act of making a decision, including taking a risk,\r
   which decision is in part or in whole\r
@@ -1063,14 +1063,14 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="d_relparty">Relying Party</a></b>.\r
+<strong><a id="d_relparty">Relying Party</a></strong>.\r
   An industry term refering to someone who relies\r
   (that is, makes decisions or takes risks)\r
   in part or in whole on a certificate.\r
 </p>\r
 \r
 <p>\r
-    <b>Subscriber Naming.</b>\r
+    <strong>Subscriber Naming.</strong>\r
     The term used in this CPS to\r
     describe all naming data within a certificate.\r
     Approximately similar terms from Industry such as\r
@@ -1079,21 +1079,21 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="d_verification">Verification</a></b>.\r
+<strong><a id="d_verification">Verification</a></strong>.\r
   An industry term referring to\r
   the act of checking and controlling\r
   the accuracy and utility of a single claim.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_validation">Validation</a></b>.\r
+<strong><a id="d_validation">Validation</a></strong>.\r
   An industry term referring to the process of\r
   inspecting and verifying the information and\r
   subsidiary claims behind a claim.\r
 </p>\r
 \r
 <p>\r
-<b><a id="usage">Usage</a></b>.\r
+<strong><a id="usage">Usage</a></strong>.\r
   The event of allowing a certificate to participate in\r
   a protocol, as decided and facilitated by a user's software.\r
   Generally, Usage does not require significant input, if any,\r
@@ -1104,7 +1104,7 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="drel">CAcert Relying Party</a></b>.\r
+<strong><a id="drel">CAcert Relying Party</a></strong>.\r
   CAcert Members who make decisions based in part or in whole\r
   on a certificate issued by CAcert.\r
   Only CAcert Members are permitted to Rely on CAcert certificates,\r
@@ -1112,7 +1112,7 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="ddst">Vendors</a></b>.\r
+<strong><a id="ddst">Vendors</a></strong>.\r
   Non-members who distribute CAcert's root or intermediate certificates\r
   in any way, including but not limited to delivering these\r
   certificates with their products, e.g. browsers, mailers or servers.\r
@@ -1121,13 +1121,13 @@ As per above.
 </p>\r
 \r
 <p>\r
-<b><a id="d_ccs">Configuration-Control Specification</a></b> "CCS".\r
+<strong><a id="d_ccs">Configuration-Control Specification</a></strong> "CCS".\r
   The audit criteria that controls this CPS.\r
   The CCS is documented in COD2, itself a controlled document under CCS.\r
 </p>\r
 \r
 <p>\r
-<b><a id="d_cod">CAcert Official Document</a></b> (COD).\r
+<strong><a id="d_cod">CAcert Official Document</a></strong> (COD).\r
   Controlled Documents that are part of the CCS.\r
 </p>\r
 \r
@@ -1190,7 +1190,7 @@ made available on issuance.
 <h4><a id="p3.1.1">3.1.1. Types of names</a></h4>\r
 \r
 <p>\r
-<b>Client Certificates.</b>\r
+<strong>Client Certificates.</strong>\r
 The Subscriber Naming consists of:\r
 </p>\r
 \r
@@ -1225,7 +1225,7 @@ The Subscriber Naming consists of:
 \r
 \r
 <p>\r
-<b>Individual Server Certificates.</b>\r
+<strong>Individual Server Certificates.</strong>\r
 The Subscriber Naming consists of:\r
 </p>\r
 \r
@@ -1244,7 +1244,7 @@ The Subscriber Naming consists of:
 </li> </ul>\r
 \r
 <p>\r
-<b>Certificates for Organisations.</b>\r
+<strong>Certificates for Organisations.</strong>\r
 In addition to the above, the following applies:\r
 </p>\r
 \r
@@ -1606,7 +1606,7 @@ to check the private key dynamically.
 <h4><a id="p3.2.2">3.2.2. Authentication of Individual Identity</a></h4>\r
 \r
 <p>\r
-<b>Agreement.</b>\r
+<strong>Agreement.</strong>\r
 An Internet user becomes a Member by agreeing to the\r
 CAcert Community Agreement\r
 (<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>)\r
@@ -1629,7 +1629,7 @@ for all service requests such as certificates.
 </p>\r
 \r
 <p>\r
-<b>Assurance.</b>\r
+<strong>Assurance.</strong>\r
 Each Member is assured according to Assurance Policy\r
 (<a href="https://www.cacert.org/policy/AssurancePolicy.html">COD13</a>).\r
 </p>\r
@@ -1639,7 +1639,7 @@ Each Member is assured according to Assurance Policy
 \r
 \r
 <p>\r
-<b>Certificates.</b>\r
+<strong>Certificates.</strong>\r
 Based on the total number of Assurance Points\r
 that a Member (Name) has, the Member\r
 can get different levels of certificates.\r
@@ -1756,14 +1756,14 @@ The authorisation to obtain a certificate is established as follows:
 </p>\r
 \r
 <p>\r
-<b>Addresses.</b>\r
+<strong>Addresses.</strong>\r
 The member claims authority over a domain or email address\r
 when adding the address,  <a href="#p4.1.2">&sect;4.1.2</a>.\r
 (Control is tested by means described in <a href="#p4.2.2">&sect;4.2.2</a>.)\r
 </p>\r
 \r
 <p>\r
-<b>Individuals.</b>\r
+<strong>Individuals.</strong>\r
 The authority to participate as a Member is established\r
 by the CAcert Community Agreement\r
 (<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>).\r
@@ -1771,7 +1771,7 @@ Assurances are requested by means of the signed CAP form.
 </p>\r
 \r
 <p>\r
-<b>Organisations.</b>\r
+<strong>Organisations.</strong>\r
 The authority for Organisation Assurance is established\r
 in the COAP form, as signed by an authorised representative\r
 of the organisation.\r
@@ -1917,7 +1917,7 @@ In principle, at least two controls are placed on each address.
 </p>\r
 \r
 <p>\r
-<b><a id="ping">Email-Ping</a>.</b>\r
+<strong><a id="ping">Email-Ping</a>.</strong>\r
 Email addresses are verified by means of an\r
 <i><a id="pingtest">Email-Ping test</a></i>:\r
 </p>\r
@@ -1938,7 +1938,7 @@ Email addresses are verified by means of an
 </li></ul>\r
 \r
 <p>\r
-<b><a name="email">Email Control</a>.</b>\r
+<strong><a id="email">Email Control</a>.</strong>\r
 Email addresses for client certificates are verified by passing the\r
 following checks:\r
 </p>\r
@@ -1952,7 +1952,7 @@ following checks:
 </ol>\r
 \r
 <p>\r
-<b><a id="domain">Domain Control</a>.</b>\r
+<strong><a id="domain">Domain Control</a>.</strong>\r
 Domains addresses for server certificates are verified by passing two of the\r
 following checks:\r
 </p>\r
@@ -2069,13 +2069,13 @@ and the Organisation Handbook.
 <h4><a id="p4.3.1">4.3.1. CA actions during certificate issuance</a></h4>\r
 \r
 <p>\r
-<b>Key Sizes.</b>\r
+<strong>Key Sizes.</strong>\r
 Members may request keys of any size permitted by the key algorithm.\r
 Many older hardware devices require small keys.\r
 </p>\r
 \r
 <p>\r
-<b>Algorithms.</b>\r
+<strong>Algorithms.</strong>\r
 CAcert currently only supports the RSA algorithm for X.509 keys.\r
 X.509 signing uses the SHA-1 message digest algorithm.\r
 OpenPGP Signing uses RSA signing over RSA and DSA keys.\r
@@ -2083,7 +2083,7 @@ OpenPGP Signing uses RSA signing over RSA and DSA keys.
 </p>\r
 \r
 <p>\r
-<b>Process for Certificates:</b>\r
+<strong>Process for Certificates:</strong>\r
 All details in each certificate are verified\r
 by the website issuance system.\r
 Issuance is based on a 'template' system that selects\r
@@ -2112,7 +2112,7 @@ profiles for certificate lifetime, size, algorithm.
 \r
 \r
 <p>\r
-<b>Process for OpenPGP key signatures:</b>\r
+<strong>Process for OpenPGP key signatures:</strong>\r
 All details in each Sub-ID are verified\r
 by the website issuance system.\r
 Issuance is based on the configuration that selects\r
@@ -2263,7 +2263,7 @@ The term Verification as used in the Relying Party Statement means one of
 \r
 <h5>4.5.2.b Who may rely</h5>\r
 <p>\r
-<b>Members may rely.</b>\r
+<strong>Members may rely.</strong>\r
 Relying parties are Members,\r
 and as such are bound by this CPS and the\r
 CAcert Community Agreement\r
@@ -2272,7 +2272,7 @@ The licence and permission to rely is not assignable.
 </p>\r
 \r
 <p>\r
-<b>Suppliers of Software.</b>\r
+<strong>Suppliers of Software.</strong>\r
 CAcert roots may be distributed in software,\r
 and those providers may\r
 enter into agreement with CAcert by means of the\r
@@ -2287,7 +2287,7 @@ within CAcert's forum.
 \r
 \r
 <p>\r
-<b>NRPs may not rely.</b>\r
+<strong>NRPs may not rely.</strong>\r
 If not related to CAcert by means of an agreement\r
 that binds the parties to dispute resolution within CAcert's forum,\r
 a person is a Non-Related-Person (NRP).\r
@@ -2299,7 +2299,7 @@ Root Distribution License (<a href="https://www.cacert.org/policy/RootDistributi
 <h5>4.5.2.c The Act of Reliance </h5>\r
 \r
 <p>\r
-<b>Decision making.</b>\r
+<strong>Decision making.</strong>\r
 Reliance means taking a decision that is in part or in whole\r
 based on the information in the certificate.\r
 \r
@@ -2325,10 +2325,10 @@ a Relying Party should also:
 </li></ul>\r
 \r
 <p>\r
-<b>Examining the Certificate.</b>\r
+<strong>Examining the Certificate.</strong>\r
 A Relying Party must make her own decision in using\r
 each certificate.  She must examine the certificate,\r
-a process called <i>validation</i>.\r
+a process called <em>validation</em>.\r
 Certificate-related information includes,\r
 but is not limited to:\r
 </p>\r
@@ -2350,7 +2350,7 @@ but is not limited to:
 </li></ul>\r
 \r
 <p>\r
-<b>Keeping Records.</b>\r
+<strong>Keeping Records.</strong>\r
 Records should be kept, appropriate to the import of the decision.\r
 The certificate should be preserved.\r
 This should include sufficient\r
@@ -2362,7 +2362,7 @@ defines the act.
 </p>\r
 \r
 <p>\r
-<b>Wider Protocol.</b>\r
+<strong>Wider Protocol.</strong>\r
 In principle, reliance will be part of a wider protocol\r
 (customary method in reaching and preserving agreement)\r
 that presents and preserves sufficient of the evidence\r
@@ -2375,7 +2375,7 @@ a dispute without sufficient evidence may be dismissed by an Arbitrator.
 </p>\r
 \r
 <p>\r
-<b>As Compared to Usage</b>.\r
+<strong>As Compared to Usage</strong>.\r
 Reliance goes beyond Usage.  The latter is limited to\r
 letting the software act as the total and only Validation\r
 Authority.  When relying, the Member also augments\r
@@ -2385,7 +2385,7 @@ checks of the business, technical and certificate aspect.
 \r
 <h5>4.5.2.d Risks and Limitations of Reliance </h5>\r
 <p>\r
-<b>Roots and Naming.</b>\r
+<strong>Roots and Naming.</strong>\r
 Where the Class 1 root is used,\r
 this Subscriber may be a new Member\r
 including one with zero points.\r
@@ -2410,7 +2410,7 @@ See Table 4.5.2.
  <tr>\r
   <td class="c">Class<br><span class="size1"><strong>1</strong></span></td>\r
   <td rowspan="2" class="bgClrRed">\r
-       <b>Do not rely.</b><br>\r
+       <strong>Do not rely.</strong><br>\r
        Relying party must use other methods to check. </td>\r
   <td rowspan="2" class="bgClrOrange">\r
        Do not rely.\r
@@ -2438,7 +2438,7 @@ See Table 4.5.2.
 <div class="c figure">Table 4.5.2.  Statements of Reliance</div>\r
 \r
 <p>\r
-<b>Software Agent.</b>\r
+<strong>Software Agent.</strong>\r
 When relying on a certificate, relying parties should\r
 note that your software is responsible for the way it\r
 shows you the information in a certificate.\r
@@ -2447,7 +2447,7 @@ your sole remedy may be to choose another software agent.
 </p>\r
 \r
 <p>\r
-<b>Malware.</b>\r
+<strong>Malware.</strong>\r
 When relying on a certificate, relying parties should\r
 note that platforms that are vulnerable to viruses or\r
 trojans or other weaknesses may not process any certificates\r
@@ -2459,14 +2459,14 @@ that is secured according to the needs of the application.
 <h5>4.5.2.e When something goes wrong </h5>\r
 <p>\r
 In the event that an issue arises out of the Member's reliance,\r
-her sole avenue is <b>to file dispute under DRP</b>.\r
+her sole avenue is <strong>to file dispute under DRP</strong>.\r
 See <a href="#p9.13">&sect;9.13</a>.\r
 <!-- DRC_A&sect;A.4.d -->\r
 For this purpose, the certificate (and other evidence) should be preserved.\r
 </p>\r
 \r
 <p>\r
-<b>Which person?</b>\r
+<strong>Which person?</strong>\r
 Members may install certificates for other individuals or in servers,\r
 but the Member to whom the certificate is issued\r
 remains the responsible person.\r
@@ -2478,7 +2478,7 @@ but the Organisation is the responsible person.
 \r
 <!-- <a href="http://xkcd.com/424/"> <img align="right" src="http://imgs.xkcd.com/comics/security_holes.png"> </a>  -->\r
 <p>\r
-<b>Software Agent.</b>\r
+<strong>Software Agent.</strong>\r
 If a Member is relying on a CAcert root embedded in\r
 the software as supplied by a vendor,\r
 the risks, liabilities and obligations of the Member\r
@@ -2723,7 +2723,7 @@ Refer to Security Policy 4.3 (<a href="https://svn.cacert.org/CAcert/Policies/Se
 <a id="p5.2.1"></a><h4>5.2.1. Trusted roles</h4>\r
 \r
 <ul>\r
-   <li><b> Technical teams:</b>\r
+   <li><strong> Technical teams:</strong>\r
    <ul>\r
        <li>User support personnel</li>\r
        <li>Systems Administrators -- critical and non-critical</li>\r
@@ -2734,7 +2734,7 @@ Refer to Security Policy 4.3 (<a href="https://svn.cacert.org/CAcert/Policies/Se
 \r
    </li>\r
 \r
-   <li><b>Assurance:</b>\r
+   <li><strong>Assurance:</strong>\r
    <ul>\r
        <li>Assurers</li>\r
        <li> Any others authorised under COD13  </li>\r
@@ -2742,7 +2742,7 @@ Refer to Security Policy 4.3 (<a href="https://svn.cacert.org/CAcert/Policies/Se
    Refer to Assurance Policy (<a href="https://www.cacert.org/policy/AssurancePolicy.html">COD13</a>)\r
    </li>\r
 \r
-   <li><b>Governance:</b>\r
+   <li><strong>Governance:</strong>\r
    <ul>\r
        <li>Directors (members of the CAcert Inc. committee, or "Board") </li>\r
        <li>Internal Auditor</li>\r
@@ -2770,7 +2770,7 @@ Refer to Assurance Policy (<a href="https://www.cacert.org/policy/AssurancePolic
 </p>\r
 \r
 <p>\r
-<b>Technical.</b>\r
+<strong>Technical.</strong>\r
 Refer to Security Policy 9.1 (<a href="https://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).\r
 </p>\r
 \r
@@ -2788,7 +2788,7 @@ Roles strive in general for separation of duties, either along the lines of
 \r
 <table border="1" class="parentC padding5">\r
  <tr>\r
-  <td><b>Role</b></td> <td><b>Policy</b></td> <td><b>Comments</b></td>\r
+  <td><strong>Role</strong></td> <td><strong>Policy</strong></td> <td><strong>Comments</strong></td>\r
  </tr><tr>\r
   <td>Assurer</td>\r
   <td><a href="https://www.cacert.org/policy/AssurancePolicy.html"> COD13</a></td>\r
@@ -2865,10 +2865,10 @@ Following types of records are archived:
 \r
 <table border="1" class="parentC padding5">\r
  <tr>\r
-  <td><b>Record</b></td>\r
-  <td><b>Nature</b></td>\r
-  <td><b>Exceptions</b></td>\r
-  <td><b>Documentation</b></td>\r
+  <td><strong>Record</strong></td>\r
+  <td><strong>Nature</strong></td>\r
+  <td><strong>Exceptions</strong></td>\r
+  <td><strong>Documentation</strong></td>\r
  </tr>\r
  <tr>\r
   <td>Member</td>\r
@@ -3384,12 +3384,12 @@ There are two major threads of assessment:
 </p>\r
 \r
 <ul><li>\r
-  <b>Systems Audit</b>.\r
+  <strong>Systems Audit</strong>.\r
   Analyses the CA for business and operations security.\r
   This is conducted in two phases:  documents for compliance\r
   with criteria, and operations for compliance with documentation.\r
   </li><li>\r
-  <b>Code Audit</b>.\r
+  <strong>Code Audit</strong>.\r
   Analyses the source code.\r
   This is conducted at two levels:\r
   Security concepts at the web applications level,\r
@@ -3413,15 +3413,15 @@ be permanent features.
 </p>\r
 \r
 <ul><li>\r
-  <b>Systems Audit</b>.\r
+  <strong>Systems Audit</strong>.\r
   </li><li>\r
-  <b>Code Audit</b>.\r
+  <strong>Code Audit</strong>.\r
 </li></ul>\r
 \r
 <a id="p8.2"></a><h3>8.2. Identity/qualifications of assessor</h3>\r
 \r
 <p>\r
-<b>Systems Auditors.</b>\r
+<strong>Systems Auditors.</strong>\r
 CAcert uses business systems auditors with broad experience\r
 across the full range of business, information systems\r
 and security fields.\r
@@ -3437,7 +3437,7 @@ identity systems, fraud, IT management.
 <!-- <center><a href="http://xkcd.com/511/"> <img src="http://imgs.xkcd.com/comics/sleet.png"> </a> </center> -->\r
 \r
 <p>\r
-<b>Code Auditors.</b>\r
+<strong>Code Auditors.</strong>\r
 See Security Policy, sections 7, 9.1.\r
 </p>\r
 \r
@@ -3798,7 +3798,7 @@ Root Distribution License (<a href="https://www.cacert.org/policy/RootDistributi
 \r
 \r
 <p>\r
-<b>Members.</b>\r
+<strong>Members.</strong>\r
 All Members of the Community agree to the\r
 CAcert Community Agreement\r
 (<a href="https://www.cacert.org/policy/CAcertCommunityAgreement.html">COD9</a>),\r
@@ -3809,19 +3809,19 @@ Registration Agents and the CA itself.
 </p>\r
 \r
 <p>\r
-<b>RAs.</b>\r
+<strong>RAs.</strong>\r
 Registration Agents are obliged additionally by Assurance Policy,\r
 especially 3.1, 4.1\r
 (<a href="https://www.cacert.org/policy/AssurancePolicy.html">COD13</a>).\r
 </p>\r
 \r
 <p>\r
-<b>CA.</b>\r
+<strong>CA.</strong>\r
 The CA is obliged additionally by the CCS.\r
 </p>\r
 \r
 <p>\r
-<b>Third Party Vendors.</b>\r
+<strong>Third Party Vendors.</strong>\r
 Distributors of the roots are offered the\r
 <span class="q">wip</span>\r
 3rd-Party Vendors - Disclaimer and Licence\r