diff --git a/CertificationPracticeStatement.html b/CertificationPracticeStatement.html index 4d0ea7e..a68c2e8 100755 --- a/CertificationPracticeStatement.html +++ b/CertificationPracticeStatement.html @@ -1,4 +1,6 @@ - + + @@ -83,7 +85,7 @@ a:hover { Suggested additions in BLUE, strikes in blue.
Michael Tänzer 20111113: CPS #7.1.2 "Certificate Extensions" adjustments
- Ulrich Schroeter 20130309: several minor fixes according to PoP 2.5 and Bug #1131 + Ulrich Schroeter 20130309: several minor fixes according to PoP 2.5 and Bug #1131


-

+
  • fix of ~65 html errors and ~14 html warnings
    • +
    @@ -126,7 +128,7 @@ Licence: +
    1. INTRODUCTION @@ -234,7 +236,7 @@ Licence: 1.2. Document name and identification @@ -330,8 +332,8 @@ for each class of certificate. - + Creative Commons license + from xkcd.com. 198 177 515
      2. --> @@ -470,8 +472,8 @@ and risks, liabilities and obligations in
      - - + @@ -728,7 +730,7 @@ and will be submitted to vendors via the (Top-level) Root.
      Type
      Appropriate Certificate uses
      +
      Type
      Appropriate Certificate uses
      General
      - + @@ -736,7 +738,7 @@ and will be submitted to vendors via the (Top-level) Root. - + @@ -745,12 +747,12 @@ and will be submitted to vendors via the (Top-level) Root. - + - + @@ -759,7 +761,7 @@ and will be submitted to vendors via the (Top-level) Root. - @@ -767,8 +769,8 @@ and will be submitted to vendors via the (Top-level) Root. - + @@ -776,8 +778,8 @@ and will be submitted to vendors via the (Top-level) Root. - + @@ -785,14 +787,14 @@ and will be submitted to vendors via the (Top-level) Root. - + - + +
      Level of Assurance
      Level of Assurance
      Members †
      Assured Members
      Assurers
       
      Class of RootAnon Name Name+Anon
      Remarks
      Remarks
      Top level
      Root
      •
      -
      •
      +
      •
      •
      •
      •
      •
      Member
      SubRoot
      ✔
      ✘
      +
      ✘
      ✔
      ✔
      ✔
      Assured
      SubRoot
      ✘
      -
      ✘
      +
      ✘
      ✘
      ✔
      ✔
      ✔
      Organisation
      SubRoot
      ✘
      -
      ✘
      +
      ✘
      ✘
      ✔
      ✔
      ✔
      Expiry of Certificates
      6 months
      -
      24 months
      +
      6 months
      24 months
      Types
      client, server
      -
      wildcard, subjectAltName
      -
      code-signing
      +
      client, server
      wildcard, subjectAltName
      code-signing
      		 (Inclusive to the left.)
      @@ -817,14 +819,14 @@ look at the CPS to figure it out. - + - + @@ -832,7 +834,7 @@ look at the CPS to figure it out. - + @@ -844,21 +846,21 @@ look at the CPS to figure it out. - + - + - + - +
      Level of Assurance
      Level of Assurance
      Members
      Assured Members
       
      Class of RootNamed Anonymous Named
      Remarks
      Remarks
      Class
      1
      Class
      3
      ✘
      -
      ✘
      +
      ✘
      ✘
      ✔
      ✔
      		Assured Members only.
      Intended for Reliance.
      Assured Members only.
      Intended for Reliance.
      Expiry of Certificates
      6 months
      -
      24 months
      +
      6 months
      24 months
      Types available
      simple only
      -
      wildcard, subjectAltName
      +
      simple only
      wildcard, subjectAltName
      @@ -992,7 +994,7 @@ As per above. Assured Member. A Member whose identity has been sufficiently verified by Assurers or other - approved methods under Assurance Policy.

      + approved methods under Assurance Policy.

      Assurer. @@ -1029,14 +1031,14 @@ As per above. Root Distribution License (COD14).

      -Reliance. +Reliance. An industry term referring to the act of making a decision, including taking a risk, which decision is in part or in whole informed or on the basis of the contents of a certificate.

      -Relying Party. +Relying Party. An industry term refering to someone who relies (that is, makes decisions or takes risks) in part or in whole on a certificate. @@ -1050,19 +1052,19 @@ As per above. are not used here.

      -Verification. +Verification. An industry term referring to the act of checking and controlling the accuracy and utility of a single claim.

      -Validation. +Validation. An industry term referring to the process of inspecting and verifying the information and subsidiary claims behind a claim.

      -Usage. +Usage. The event of allowing a certificate to participate in a protocol, as decided and facilitated by a user's software. Generally, Usage does not require significant input, if any, @@ -1091,7 +1093,7 @@ As per above. The audit criteria that controls this CPS. The CCS is documented in COD2, itself a controlled document under CCS.

      -

      +

      CAcert Official Document (COD). Controlled Documents that are part of the CCS. @@ -1316,7 +1318,7 @@ See Certificates containing International Domain Names, being those containing a ACE prefix (RFC3490 Section 5), will only be issued to domains satisfying one or more -of the following conditions: +of the following conditions:

      • The Top Level Domain (TLD) Registrar associated with the domain has a policy that has taken measures to prevent two homographic domains being registered to @@ -1327,14 +1329,14 @@ excluding the "Common" script, with the additionally allowed numberic characters [0-9], and an ACSII hyphen '-'.
      -

      +

      Email address containing International Domain Names in the domain portion of the email address will also be required to satisfy one of the above conditions.

      -The following is a list of accepted TLD Registrars: +The following is a list of accepted TLD Registrars:

      @@ -1465,8 +1467,8 @@ The following is a list of accepted TLD Registrars: - - + + @@ -1533,7 +1535,7 @@ The following is a list of accepted TLD Registrars:
      .ltRegistryPolicy (character list)RegistryPolicy (character list)
      Policy (character list)
      -

      +

      This criteria will apply to the email address and server host name fields for all certificate types. @@ -1784,7 +1786,7 @@ process or file a dispute.

      4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

      -The general life-cycle for a new certificate for an Individual Member is: +The general life-cycle for a new certificate for an Individual Member is:

      1. Member adds claim to an address (domain/email). @@ -1805,7 +1807,7 @@ The general life-cycle for a new certificate for an Individual Member is: Member accepts certificate.
      -

      +

      (Some steps are not applicable, such as anonymous certificates.) @@ -1827,7 +1829,7 @@ On issuance of certificates, Members become Subscribers. The Member can claim ownership or authorised control of a domain or email address on the online system. This is a necessary step towards issuing a certificate. -There are these controls: +There are these controls:

      • The claim of ownership or control is legally significant and may be referred to dispute resolution. @@ -1838,7 +1840,7 @@ There are these controls: the certificate application system automatically initiates the check of control, as below.
      -

      +

      4.1.3. Preparing CSR

      @@ -1889,7 +1891,7 @@ In principle, at least two controls are placed on each address.

      Email-Ping. Email addresses are verified by means of an -Email-Ping test: +Email-Ping test:

      • @@ -1948,7 +1950,7 @@ following checks:

    -Notes. +Notes.

    -

    +