fix: Somewhat sensibly split the wishlist document

[gigi.git] / doc / specification.md

diff --git a/doc/wishList.md b/doc/specification.md
similarity index 51%
rename from doc/wishList.md
rename to doc/specification.md
index 20603140e039ea77e0b69d05827568c4eef782b3..d6713ab00945491d459ba6d00385c311946df7de 100644 (file)
--- a/doc/wishList.md
+++ b/doc/specification.md
@@ -1,62 +1,4 @@
-== Glossary / Definitions ==
-
-ASN.1: A horrible way to encode data. Usually used together with X.509
-
-BER: Basic Encoding Rules for ASN.1
-
-CER: Canonical Encoding Rules for ASN.1
-
-CSR: Certificate Signing Request, request to get some public key signed
-
-CSRF: Cross Site Request Forgery, attach technique breaching causality
-of requests
-
-DER: Distinguished Encoding Rules for ASN.1
-
-ECMA: European Computer Manufacturers Association
-
-ETSI: European Telecommunications Standards Institute
-
-GnuPG: GNU Privacy Guard, Some implementation using the OpenPGP standard
-
-HSTS: Hypertext Strict Transport Security, Protection Mechanism against
-casual MitM in networks and SSL Stripping, governed by RFC 6797
-
-ITU: International Telecommunication Union, standards body responsible
-for most standards with a dot in their names
-
-JS: JavaScript, an ECMA-Standard
-
-JSON: JavaScript Object Notation, standardized way to encode data for
-easy parsing
-
-MIME: Multipurpose Internet Mail Extensions, some way to stuff multiple
-messages into one message
-
-OAuth: OpenAuthentication standard for SSO
-
-OpenPGP: Signature and Encryption format governed by RFC 4880 et. al.
-
-OTP: One-Time-Password
-
-PKI: Public Key Infrastructure
-
-PKIX: PKI using X.509
-
-SPKAC: Signed Public Key and Challenge, interactive variant of a CSR
-
-SSL: Secure Socket Layer, predecessor of TLS, cf. TLS
-
-SSO: Single Sign On, mechanism for authentication accross different
-domains/systems using a central identity
-
-TLS: Transport Layer Security, Protocol for secure communication between
-a client and a server, governed by various RFCs
-
-X.509: An ITU standard describing contents of things (usually abused for
-PKIX certificates)
-
-XSS: Cross-Site Scripting, attack technique breaching same-origin boundaries
+= THIS DOCUMENT IS STILL WORK IN PROGRESS =

 
 = Todo list =
 == "Todo" (work in active code) ==
 
 = Todo list =
 == "Todo" (work in active code) ==


@@ -78,7 +20,7 @@ admins (e.g. adobe.com, 3m.com)
 (cf. Public Suffix List below in references)
 * OpenPGP integration
 * think about org - certificates
 (cf. Public Suffix List below in references)
 * OpenPGP integration
 * think about org - certificates

-* think about names. What are names? how many names? assure names?
+* think about names. What are names? how many names? verify names?

 
 == Makeup ==
 
 
 == Makeup ==
 


@@ -124,7 +66,7 @@ generate said certificate or whatever
    * if yes: pw-recovery q&a have to be set
  * confirmation that data was entered truthfully and recap of RLO at
 this stage
    * if yes: pw-recovery q&a have to be set
  * confirmation that data was entered truthfully and recap of RLO at
 this stage

- * CCA acceptance
+ * Policy acceptance

 
 == Login/authentication ==
 * Separate Session scope for "www", "secure" and "api"
 
 == Login/authentication ==
 * Separate Session scope for "www", "secure" and "api"


@@ -134,29 +76,25 @@ this stage
 operations like revocation) (new feature)
 * Option to switch off/on authentication methods (new feature)
 * Option to selectively grant permissions to certain types of
 operations like revocation) (new feature)
 * Option to switch off/on authentication methods (new feature)
 * Option to selectively grant permissions to certain types of

-credentials only (e.g. pw login may only assure someone, while cert XY
+credentials only (e.g. pw login may only verify someone, while cert XY

 may do anything, SE interface with cert only) (new feature) ES: I think
 Benny was speaking about a user setting, while INO was speaking about a
 fixed global setting - this are two different things!
 * Reset password by security questions and mail (?? probably not
 [recommended in all situations])
 * Option to switch off/on pw recovery per security questions (new feature)
 may do anything, SE interface with cert only) (new feature) ES: I think
 Benny was speaking about a user setting, while INO was speaking about a
 fixed global setting - this are two different things!
 * Reset password by security questions and mail (?? probably not
 [recommended in all situations])
 * Option to switch off/on pw recovery per security questions (new feature)

-* Reset password by assurance (how is this going to be implemented
-automatically?) Cannot be done automatically at the moment, as this is
-covered by a process clearly defined by an arbitration precedents-case.
-- At least not with a new precedents ruling. - Only part is the pw-reset
-field on the SE side
-* CCA acceptance at login, if current version of CCA was not accepted by
+* Reset password by verification
+* Policy acceptance at login, if current version of Policies was not accepted by

 user before
 
 === Account Flags (tbd: collect further (new) flags) ===
 most should contain dates when set/removed - needed for account log and
 audit
 * Activated (Initial Account Activation Mail received)
 user before
 
 === Account Flags (tbd: collect further (new) flags) ===
 most should contain dates when set/removed - needed for account log and
 audit
 * Activated (Initial Account Activation Mail received)

-* CATs passed (FD: virtual = live calculation)
-* assurer (FD: virtual = live calculation)
-* blocked assurer
-* CCA accepted (virtual)
+* Agent Test passed (FD: virtual = live calculation)
+* Agent (FD: virtual = live calculation)
+* blocked Agent
+* Policies accepted (virtual)

 * blocked account
 * deleted account
 * PW login allowed (Global for Account)
 * blocked account
 * deleted account
 * PW login allowed (Global for Account)


@@ -182,36 +120,36 @@ TBL: GroupPermissions [ID{AI/PK}, Group{Ref(Group)},
 Permission{Ref(Permission)}, Action{E(Grant,Revoke)}, Date{Date}]
 
 * Used for special permissions e.g. in support interface, mass mailings
 Permission{Ref(Permission)}, Action{E(Grant,Revoke)}, Date{Date}]
 
 * Used for special permissions e.g. in support interface, mass mailings

-* Additionally groups members with additional obligations (e.g. PP-CATS)
+* Additionally groups members with additional obligations (e.g. PP-Test)

 
 * manual setting of permissions has to appear in personal and admin-log
 
 == personal details (names, DoB) ==
 
 * manual setting of permissions has to appear in personal and admin-log
 
 == personal details (names, DoB) ==

-* Change personal details (names, DoB) (only if not assured)
+* Change personal details (names, DoB) (only if not verified)

  * after each change, the user has to state, to have those names entered
 in official documents
 * maybe adding/removing of non-official nick-name allowed at any time
 (new feature)
  * after each change, the user has to state, to have those names entered
 in official documents
 * maybe adding/removing of non-official nick-name allowed at any time
 (new feature)

-* Allow multiple names that can be assured independently (new) -
-something like this should be clarified with the AO at least, better to
-get it fixed clearly in an updated AP (in general AP does allow for this
+* Allow multiple names that can be verified independently (new) -
+something like this should be clarified with the VO at least, better to
+get it fixed clearly in an updated VPol (in general VPol does allow for this

 at the moment, but people do not know about this)
 * Allow to enter
  * 1 name - with a confirmation that one only has exactly one name part
 at the moment, but people do not know about this)
 * Allow to enter
  * 1 name - with a confirmation that one only has exactly one name part

- * Title? FN+ LN+ Suffix? marked as non-assurable Nick? (could be used
+ * Title? FN+ LN+ Suffix? marked as non-verifiable Nick? (could be used

 for internal processes) - with a confirmation that those are covered by
 at least one official document owned by the member/potential member
 * GUI should (until further notice) allow only exactly ONE name (with
 multiple name-parts) to be entered for an account
 * Names containing a Nickname component MUST NOT be primary names for an
 account (BB: Who did the striking? and Why?)
 for internal processes) - with a confirmation that those are covered by
 at least one official document owned by the member/potential member
 * GUI should (until further notice) allow only exactly ONE name (with
 multiple name-parts) to be entered for an account
 * Names containing a Nickname component MUST NOT be primary names for an
 account (BB: Who did the striking? and Why?)

-* official nicknames may be used, if switched on based on an assurance
+* official nicknames may be used, if switched on based on an verification

 by support
 by support

-* else nicknames may only be displayed as an addition and MAY NOT be assured
+* else nicknames may only be displayed as an addition and MAY NOT be verified

 TBL: Name: [ID{AI/PK}, UID{Ref(User}},
 TBL: NameComponent [ID{AI/PK}, Name{Ref(Name)}, Order{I},
 Type{E[One,Firstname,Lastname,Title,Suffix,Nick,OfficialNick]},
 TBL: Name: [ID{AI/PK}, UID{Ref(User}},
 TBL: NameComponent [ID{AI/PK}, Name{Ref(Name)}, Order{I},
 Type{E[One,Firstname,Lastname,Title,Suffix,Nick,OfficialNick]},

-Assureable{B}, Value{S}, Context{S}, Points{I,Cached}]
+Verifiable{B}, Value{S}, Context{S}, Points{I,Cached}]

 
 
 === Domain/email pinging ===
 
 
 === Domain/email pinging ===


@@ -297,7 +235,7 @@ CSR does not meet the requiremnts any more eg. weak keys -> Prefill of
 the CreateCert-Dialog with the existing data for the cert/csr
 * select md (sha2-512, sha2-384, sha2-256, sha3-512, whirlpool?, ...)
 * select duration up to maximum allowed for member
 the CreateCert-Dialog with the existing data for the cert/csr
 * select md (sha2-512, sha2-384, sha2-256, sha3-512, whirlpool?, ...)
 * select duration up to maximum allowed for member

-* select (assured) name components / acronyms thereof
+* select (verified) name components / acronyms thereof

 * select (ping-approved) domains / email-addresses
 * select class (up to what is allowed for member)
 * select if allowed for login as described above @ login
 * select (ping-approved) domains / email-addresses
 * select class (up to what is allowed for member)
 * select if allowed for login as described above @ login


@@ -305,7 +243,7 @@ the CreateCert-Dialog with the existing data for the cert/csr
 
 MAYBE: * schedule to issue certificates for a day in the next two weeks.
 (Should require someone who knows what he's doing, requires experienced
 
 MAYBE: * schedule to issue certificates for a day in the next two weeks.
 (Should require someone who knows what he's doing, requires experienced

-assurer)
+agent)

 
 Notification Mail about new certificate may include link for revocation
 (new feature)
 
 Notification Mail about new certificate may include link for revocation
 (new feature)


@@ -316,7 +254,7 @@ Process for issuing a certificate:
 names, emails, domains, certificate root
 2. Confirm values and if necessary modify them
 3. Select additional settings (login, comments, ...) and validity interval
 names, emails, domains, certificate root
 2. Confirm values and if necessary modify them
 3. Select additional settings (login, comments, ...) and validity interval

-4. confirm CCA + confirm the issuing of the certificate as shown
+4. confirm policies + confirm the issuing of the certificate as shown

 (do 1a to 4 in one form? - Could be done with JS enabled)
 5. send information (ping) mail to affected address (& primary if
 selected), display failures + potential abort
 (do 1a to 4 in one form? - Could be done with JS enabled)
 5. send information (ping) mail to affected address (& primary if
 selected), display failures + potential abort


@@ -332,73 +270,55 @@ sent: is name still valid/etc. still have all rights.)
 
 === Certificate types ===
 * Email certificates (include email (+ real name if points>=50)
 
 === Certificate types ===
 * Email certificates (include email (+ real name if points>=50)

-(+codesigning if enabled && Assurer)
+(+codesigning if enabled && Agent)

 * Domain certificates (include domain name + SANs (+real name if
 points>=50))
 * Organisation Email certificates
 * Organisation Domain certificates
 * Split more templates (e.g. Email from Code Signing)
 
 * Domain certificates (include domain name + SANs (+real name if
 points>=50))
 * Organisation Email certificates
 * Organisation Domain certificates
 * Split more templates (e.g. Email from Code Signing)
 

-=== WoT management ===
-* Assure a member
+=== Verification management ===
+* Verify a member

   * enter email address + DoB
     * if correct:
   * enter email address + DoB
     * if correct:

-      * if member was assured before by this assurer:
-        * currently: abort process with according information - but:
-this may be changed later
-      * if there was no previous assurance by the assurer over the member:
+      * if member was verified before by this agent:
+        * most recent verification overrides previous ones
+      * if there was no previous verification by the agent over the member:

         * names shown [has to be defined in more detail]
         * DoB shown
         * primary email shown
         * confirmation that names + DoB could be verified were official
 documents
         * select if TTP [further details TBD]
         * names shown [has to be defined in more detail]
         * DoB shown
         * primary email shown
         * confirmation that names + DoB could be verified were official
 documents
         * select if TTP [further details TBD]

-        * free-text-field: location of assurance - default: empty -
-needs to be filled
-        * date of assurance selection, default: non selected (not before
-DoB, not after current date+13h) - needs to be set INO: Current Date UTC
-+ 12 h BB:(13h, cause of timezones with +13h)
-        * confirmation that assuree has accepted CCA
-        * confirmation box, that AP was followed
-        * CCA acceptance box for assurer
-        * display if member was underage at assurance date, when set
-[TBD] and force a check-box-selection to confirm that PoJam process was
-followed
+        * free-text-field: location of verification meeting - default: empty - needs to be filled
+        * date of verification selection, default: non selected (not before DoB, not after current date+13h) - needs to be set
+          INO: Current Date UTC + 12 h
+          BB: (13h, cause of timezones with +13h)
+        * confirmation that member has accepted the policies
+        * confirmation box, that VPol was followed
+        * Policy acceptance box for agent

     * if not correct independent of which was wrong:
     * if not correct independent of which was wrong:

-      * option to write an automated email to the member that the
-assurer tried to assure the member
-* View all assurances received/done
-  * points, locations, dates of assurance, dates of assurance entered,
-name of assurer/assuree, revocations
+      * option to write an automated email to the member that the agent tried to verify the member
+* View all verifications received/done
+  * points, locations, dates of verification, dates of verification entered, name of agent/member, revocations

 * show how my points are calculated
 * show how my points are calculated

-  * as assuree, as assurer
-* search for assurers/etc (what exactly is this community-thing)
-  * Search for assurer is referred to Portal (cacert.eu) ES: I really
-would like to have this feature again in the main software- in both
-directions, with the option to enter multiple locations at least
-temporary (permanent location, current location), we should make it easy
-for travelling assurer and assurees to spread assurances around! BB: I
-agree to ES: Having it in the software makes many things much more easy.
-* What is about multiple assurances for the same assuree, only last
-Assurance should count. (New Feature) - ES: currently this would need
-more details in policies - we do not know how this would resolve, we may
-only guess that it would be the last one
-* Experience Points only for the last of such re-assurances (New
-Features) - ES: again, this should wait for a policy decision
+  * as member, as agent
+* search for agents/etc (what exactly is this community-thing)
+  * Search for agent is referred to seperate site
+* What is about multiple verifications for the same member -> only last verification should count. (New Feature)
+* Experience Points only for the last of such re-verifications (New Features)

 
 === Organisation management ===
 
 
 === Organisation management ===
 

-rethink? what needs to be done? what needs to be possible? how much is
-this used?
+* rethink!
+  * what needs to be done?
+  * what needs to be possible?
+  * how much is this used?

 * The Org area can be shifted back for now.
 
 * The Org area can be shifted back for now.
 

-

 Roles:
 Roles:

-* OrgAssurer: can create and administer the OrgAccounts, administer: add
-and delete OrgAdmin, add and delete Org Domains, does not have access to
-the certs
-* OrgMaster: can see the Org account data; add/remove other OrgMasters
-and OrgAdmins
+* OrgAgent: can create and administer the OrgAccounts, administer: add and delete OrgAdmin, add and delete Org Domains, does not have access to the certs
+* OrgMaster: can see the Org account data; add/remove other OrgMasters and OrgAdmins

 * OrgAdmin: can see the org account data; is able to administer the certs
 * SE: is able to see account data, revoke certs (new feature)
 
 * OrgAdmin: can see the org account data; is able to administer the certs
 * SE: is able to see account data, revoke certs (new feature)
 


@@ -406,10 +326,8 @@ Cert Creation:
 * Client Cert with form
 * Client Cert with CSR (New feature)
 * Client Cert with multiple email addresses
 * Client Cert with form
 * Client Cert with CSR (New feature)
 * Client Cert with multiple email addresses

-* Multiple Client Certs via file upload and result download (create e.g.
-10 certs with one upload) (New Feature)
-* revoke cert via file upload, e.g. file with to email addresses all
-certs to these addresses will be revoked. (New Feature)
+* Multiple Client Certs via file upload and result download (create e.g. 10 certs with one upload) (New Feature)
+* revoke cert via file upload, e.g. file with to email addresses all certs to these addresses will be revoked. (New Feature)

 
 * Filter on client cert page (new feature)
 
 
 * Filter on client cert page (new feature)
 


@@ -417,20 +335,18 @@ certs to these addresses will be revoked. (New Feature)
 
 * Org Account History
   * Org account full history visible by OrgAdmins, SE via Ticket Number
 
 * Org Account History
   * Org account full history visible by OrgAdmins, SE via Ticket Number

-  * Org Account history only account information without cert history by
-OrgAssurer
+  * Org Account history only account information without cert history by OrgAgent

 
 

-* OrgAssurer should be able to perform an IsAssuer check.
+* OrgAgent should be able to perform an IsAssuer check.

 
 
 
 === OpenPGP key signing ===
 
 
 
 === OpenPGP key signing ===

-* if points >= 50 allow signing of OpenPGP key with real name, no
-comment field, matching email in account.
+* if points >= 50 allow signing of OpenPGP key with real name, no comment field, matching email in account.

 * UserIDs on key to be signed user-selectable.
 * Expiry date: selectable up to maximum allowed
 * re-signing without need to uploade key again
 * UserIDs on key to be signed user-selectable.
 * Expiry date: selectable up to maximum allowed
 * re-signing without need to uploade key again

-* CCA acceptance needed for all signatures
+* Policy acceptance needed for all signatures

 * lookup of keys on keyserver (if present)
 * Ensure key has basic cryptographic security:
   * conformant to normal certificate's requirements
 * lookup of keys on keyserver (if present)
 * Ensure key has basic cryptographic security:
   * conformant to normal certificate's requirements


@@ -454,49 +370,22 @@ reasons to go directly to a supporter but has the authority to do so)
 action is being logged. <- the mail should be optional (to primary
 address) and only once in a given time frame/login, as a supporter may
 need to do more than one thing at a time
 action is being logged. <- the mail should be optional (to primary
 address) and only once in a given time frame/login, as a supporter may
 need to do more than one thing at a time

-* View/edit users personal details (even if assured)
-* set account flags (code signing, assurer status, block of account,
-ttp, org-admin, support, team member)
-* delete/invalidate assurances
-* revoke certificates, pgp-key signatures, both should be possible for
-single certificates/keys or for all certificates/keys
+* View/edit users personal details (even if verified)
+* set account flags (code signing, Agent status, block of account, org-admin, support, team memberships)
+* delete/invalidate verifications
+* revoke certificates, pgp-key signatures, both should be possible for single certificates/keys or for all certificates/keys

 * "delete" account
 
 * "delete" account
 

-=== Arbitration interface (new feature) ===
- * everything requires: arbitration number, role in arbitration case
-(iCM, CM, Arbitrator)
- * everything has to be shown in admin log for support and in account log
- * show CCA acceptance for user identified by email (does not have to be
-primary) (only latest version of accepted CCA)
- * show primary email for email address
- * show arbitration case number of arbitration cases, a user identified
-per email address is involved in
- * mark/unmark user identified per email (does not have to be primary)
-as involved in an arbitration case (by numbers)
- * set CCA acceptance for user identified by email (date, "before
-arbitrator")
- * running arbitration case should be visible to SE - ES: That is NOT
-part of the arbitration interface! And currently it would be enough, if
-delete account process would be stopped by the member being involved in
-an arb case, telling that there is an arb case (not which and how many)
-- currently this information is not needed in any other support case and
-involvement in arbitration cases is anonymous.
-
-=== automated (outside of a current process) information mails to
-members ===
- * certificate(s)/signature expires within the next 14 days (combined or
-separate)
+=== automated (outside of a current process) information mails to members ===
+ * certificate(s)/signature expires within the next 14 days (combined or separate)

 
 === "mass mails" interface (new feature) ===
 
 === "mass mails" interface (new feature) ===

-  * access only for critical team (or other restricted personal
-controlled by arbitration)
-  * arbitration case number needed (maybe announcement flags could be
-allowed for support case numbers or motions, as well)
+  * access only for critical team (or other restricted personal controlled by arbitration)
+  * arbitration case number needed (maybe announcement flags could be allowed for support case numbers or motions, as well)

   * requester has to be set (identified by email)
   * text-field for subject
   * text-field for mail-content
   * requester has to be set (identified by email)
   * text-field for subject
   * text-field for mail-content

-  * one of the following three should be possible for selection of
-recipients:
+  * one of the following three should be possible for selection of recipients:

     * sql-query
     * list of email addresses
     * list of account-ids
     * sql-query
     * list of email addresses
     * list of account-ids


@@ -506,219 +395,65 @@ recipients:
 === Statisics ===
 
 * running total for current year
 === Statisics ===
 
 * running total for current year

-  * assurances
-  * new member
-  * new assurers
+  * verifications
+  * new members
+  * new agents

   * lost members
   * lost members

-  * active assurers (at least one assurance according to the assurance
-date of the current year)
-  * active assurees (who got the latest assurance in the current year)
+  * active agents (at least one verification according to the verification date of the current year)
+  * active members (who got their latest verification in the current year)

 
 * running total for last 12 months per month
 
 * running total for last 12 months per month

-  * assurances
+  * verifications

   * new member
   * new member

-  * new assurers
+  * new agents

   * lost members
   * new certs
   * revoked certs
   * lost members
   * new certs
   * revoked certs

-  * active assurer / assurees
+  * active agents / members

 
 * Grand Total
   * members
 
 * Grand Total
   * members

-  * assurances
-  * granted AP
-  * user >= 50 and <99 AP
-  * assurer candidates
-  * assurer
+  * verifications
+  * granted VP
+  * user >= 50 and <99 VP
+  * agent candidates
+  * agents

   * issued client certs
   * active client certs
   * issued client certs
   * active client certs

+  * revoked client certs

   * issued server certs
   * active server certs
   * issued server certs
   * active server certs

+  * revoked server certs

   * issued org client certs
   * active org client certs
   * issued org client certs
   * active org client certs

+  * revoked org client certs

   * issued org server certs
   * active org server certs
   * issued org server certs
   * active org server certs

+  * revoked org server certs

   * issued gpg certs
   * active gpg certs
   * issued gpg certs
   * active gpg certs

+  * revoked gpg certs

 
 * yearly statistics
 
 * yearly statistics

-  * assurances
+  * verifications

   * new member
   * new member

-  * new assuer
+  * new agents

   * lost members
   * new certs
   * revoked certs
   * lost members
   * new certs
   * revoked certs

-  * active assurers (at least one assurance according to the assurance
-date of the current year)
-  * active assurees
+  * active agents (at least one verification according to the verification date of the current year)
+  * active members

 
 

-access statistic data via API e.g. assurance per year is needed for
-coaudit database
+access statistic data via API e.g. verifications per year is needed for coaudit database

 
 

-the active assurees may be relevant for any decision in the regard how
-long assurances should be valid and if they need to be renewed. It also
-gives
+the active members may be relevant for any decision in the regard how long verifications need be valid and if they need to be renewed.

 
 === Premission Review mails (monthly?) ===
 * Regular check and report of permissions for various groups of people
 
 === Premission Review mails (monthly?) ===
 * Regular check and report of permissions for various groups of people

-INO: currently quarterly
+  INO: currently quarterly

 
 === Tools ===
 * csr/crt inspector
 * + lookup OCSP/CRL status.
 * OpenPGP key inspector (Yup, we need one)
 
 === Tools ===
 * csr/crt inspector
 * + lookup OCSP/CRL status.
 * OpenPGP key inspector (Yup, we need one)

-* Database Editor CLI tool for crit to update records (and their
-checksums/timestamping)
-
-==References==
-* Our Policies
-  * CAcert Community Agreement (CCA)
-  * Dispute Resolution Policy (DRP)
-  * Certificate Policy on Signing (CPS) + Certification Policy (per
-Root) (CP)
-  * Security Policy (SP) / Security Manual (SM)
-  * Assurance Handbook (AH) + Practice on Names (PoN)
-    * Policy on Junior Assurers and Members (PoJAM)
-    * Trusted Third Party (TTP) and Sub-Policies
-    * Organisation Assurance Policy (OAP)
-  * Policy on Policy (PoP)
-  * CAcert Website Data Privacy Policy (currently WIP) WDPP
-* Internet Standards
-  * RFC documents
-    * IPv4/IPv6
-      * RFC 0791 (IPv4: Internet Protocol, 1981)
-      * RFC 2460 (IPv6: Internet Protocol, Version 6 (IPv6)
-Specification, 1998)
-    * HTTP
-      * RFC 1945 (HTTP/1.0, 1996)
-      * RFC 2616 (HTTP/1.1, 1999)
-      * RFC 7230 (HTTP/1.1: Message Syntax and Routing, 2014)
-      * RFC 7231 (HTTP/1.1: Semantics and Content, 2014)
-      * RFC 7232 (HTTP/1.1: Conditional Requests, 2014)
-      * RFC 7233 (HTTP/1.1: Range Requests, 2014)
-      * RFC 7234 (HTTP/1.1: Caching, 2014)
-      * RFC 7235 (HTTP/1.1: Authentication, 2014)
-    * SSL/TLS
-      * RFC 3268 (TLS 1.0+: Advanced Encryption Standard (AES)
-Ciphersuites for Transport Layer Security (TLS), 2002)
-      * RFC 4347 (DTLS 1.0: Datagram Transport Layer Security, 2006)
-      * RFC 4492 (TLS 1.0+: Elliptic Curve Cryptography (ECC) Cipher
-Suites for Transport Layer Security (TLS), 2006)
-      * RFC 4346 (TLS 1.1: The Transport Layer Security (TLS) Protocol
-Version 1.1, 2006)
-      * RFC 4366 (TLS 1.0+: Transport Layer Security (TLS) Extensions, 2006)
-      * RFC 5246 (TLS 1.2: The Transport Layer Security (TLS) Protocol
-Version 1.2, 2008)
-      * RFC 5764 (TLS 1.0+: Transport Layer Security (TLS) Renegotiation
-Indication Extension, 2010)
-      * RFC 5878 (TLS 1.0+: Transport Layer Security (TLS) Authorization
-Extensions, 2010)
-      * RFC 6176 (SSL 2.0: Prohibiting Secure Sockets Layer (SSL)
-Version 2.0, 2011)
-      * RFC 7027 (TLS 1.0+: Elliptic Curve Cryptography (ECC) Brainpool
-Curves for Transport Layer Security (TLS), 2013)
-    * Web Security
-      * RFC 6797 (HSTS: HTTP Strict Transport Security, 2012)
-    * PKIX
-      * RFC 2459 (X.509: Internet X.509 Public Key Infrastructure
-Certificate and CRL Profile, 1999)
-      * RFC 3280 (X.509: Internet X.509 Public Key Infrastructure
-Certificate and Certificate Revocation List (CRL) Profile, 2002)
-      * RFC 4325 (X.509: Internet X.509 Public Key Infrastructure
-Authority Information, Access Certificate Revocation List (CRL)
-Extension, 2005)
-      * RFC 4630 (X.509: Update to DirectoryString Processing in the
-Internet X.509 Public Key Infrastructure Certificate and Certificate
-Revocation List (CRL) Profile, 2006)
-      * RFC 5280 (X.509: Internet X.509 Public Key Infrastructure
-Certificate and Certificate Revocation List (CRL) Profile, 2008)
-    * OpenPGP
-      * RFC 1991 (OpenPGP: PGP Message Exchange Formats, 1996)
-      * RFC 2440 (OpenPGP: OpenPGP Message Format, 1998)
-      * RFC 4880 (OpenPGP: OpenPGP Message Format, 2007)
-      * RFC 5581 (OpenPGP: The Camellia Cipher in OpenPGP, 2009)
-      * RFC 6637 (OpenPGP: Elliptic Curve Cryptography (ECC) in OpenPGP,
-2012)
-    * JSON
-      * RFC 4627 (JSON: The application/json Media Type for JavaScript
-Object Notation (JSON), 2006)
-      * RFC 7158 (JSON: The JavaScript Object Notation (JSON) Data
-Interchange Format, 2013)
-      * RFC 7159 (JSON: The JavaScript Object Notation (JSON) Data
-Interchange Format, 2013)
-      * ECMA 404 (JSON: The JSON Data Interchange Format, 2013)
-
-http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
-    * MIME
-      * RFC 2045 (MIME: Multipurpose Internet Mail Extensions (MIME)
-Part One: Format of Internet Message Bodies, 1996)
-      * RFC 2046 (MIME: Multipurpose Internet Mail Extensions (MIME)
-Part Two: Media Types, 1996)
-      * RFC 2047 (MIME: MIME (Multipurpose Internet Mail Extensions)
-Part Three: Message Header Extensions for Non-ASCII Text, 1996)
-      * RFC 2048 (MIME: Multipurpose Internet Mail Extensions (MIME)
-Part Four: Registration Procedures, 1996)
-      * RFC 2049 (MIME: Multipurpose Internet Mail Extensions (MIME)
-Part Five: Conformance Criteria and Examples, 1996)
-      * RFC 2183 (MIME: Communicating Presentation Information in
-Internet Messages: The Content-Disposition Header Field, 1997)
-      * RFC 2184 (MIME: MIME Parameter Value and Encoded Word
-Extensions: Character Sets, Languages, and Continuations, 1997)
-      * RFC 2231 (MIME: MIME Parameter Value and Encoded Word
-Extensions: Character Sets, Languages, and Continuations, 1997)
-      * RFC 5335 (MIME: Internationalized Email Headers, 2008)
-      * RFC 6532 (MIME: Internationalized Email Headers, 2012)
-    * S/MIME
-      * RFC 1847 (S/MIME: Security Multiparts for MIME: Multipart/Signed
-and Multipart/Encrypted, 1995)
-      * RFC 2633 (S/MIME: S/MIME Version 3 Message Specification, 1999)
-      * RFC 3851 (S/MIME: Secure/Multipurpose Internet Mail Extensions
-(S/MIME) Version 3.1 Message Specification, 2004)
-      * RFC 5751 (S/MIME: Secure/Multipurpose Internet Mail Extensions
-(S/MIME) Version 3.2 Message Specification, 2010)
-  * W3C documents
-    * HTML 5
-      * http://www.w3.org/TR/html-markup/
-      * http://dev.w3.org/html5/html4-differences
-    * CSS 3
-      * http://www.w3.org/Style/CSS/
-    * JavaScript / ECMAScript
-      *
-http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip
-      * http://ecma-international.org/ecma-262/5.1/
-    * XML
-      * XML 1.0: http://www.w3.org/TR/2008/REC-xml-20081126/
-      * XML 1.1: http://www.w3.org/TR/2006/REC-xml11-20060816/
-    * Content Security Policy
-      * Version 1.0: http://www.w3.org/TR/CSP/
-      * Version 1.1 (WIP):
-https://w3c.github.io/webappsec/specs/content-security-policy/
-  * Miscellaneous
-    * Public Suffix List of
-      http://publicsuffix.org/
-  * Unicode Standard
-    * Unicode Technical Report 39: http://www.unicode.org/reports/tr39/
-* ITU Standards
-  * X.690 / ASN.1
-    * Information technology � ASN.1 encoding rules: Specification of
-Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
-Distinguished Encoding Rules (DER)
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
-  * X.509
-* CA/Browser Forum
-  * Baseline Requirements
-    https://cabforum.org/baseline-requirements-documents/
-
-* Miscellanious
-  * Passwords
-    * Research on Password strength
-      Carnegie Mellon University: Guessing again (and again and again)
-      https://www.ece.cmu.edu/~lbauer/papers/2012/oakland2012-guessing.pdf
-      Presentation on the findings of the paper:
-      https://www.youtube.com/watch?v=USMd3swFZp4
-    * SCrypt Key Dervation Function
-      http://www.tarsnap.com/scrypt.html
-      Colin Percival, Stronger Key Derivation via Sequential Memory-Hard
-Functions, presented at BSDCan'09, May 2009:
-      * http://www.tarsnap.com/scrypt/scrypt.pdf
-      * http://www.tarsnap.com/scrypt/scrypt-slides.pdf
+* Database Editor CLI tool for crit to update records (and their checksums/timestamping)