]> WPIA git - gigi.git/commitdiff
fix: Somewhat sensibly split the wishlist document
authorBenny Baumann <BenBE1987@gmx.net>
Wed, 22 Feb 2017 20:44:38 +0000 (21:44 +0100)
committerBenny Baumann <BenBE1987@gmx.net>
Sun, 26 Feb 2017 19:47:02 +0000 (20:47 +0100)
This is initial work for cleaning up this document to become the spec Gigi is based on

Change-Id: Ie73b567ad9df0de3bf89eeaebec5b229feb2cd4b

doc/definitions.md [new file with mode: 0644]
doc/references.md [new file with mode: 0644]
doc/specification.md [moved from doc/wishList.md with 51% similarity]

diff --git a/doc/definitions.md b/doc/definitions.md
new file mode 100644 (file)
index 0000000..f048d04
--- /dev/null
@@ -0,0 +1,57 @@
+== 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
+
+HPKP: HTTP Public Key Pinning, a way to restrict the set of keys that may be used to secure a connection
+
+HSTS: Hypertext Strict Transport Security, Protection Mechanism against casual MitM in networks and SSL Stripping, governed by RFC 6797
+
+HTTP: Hypertext Transfer Protocol
+
+ITU: International Telecommunication Union, standards body responsible for most standards with a dot in their names
+
+JS: JavaScript, standard by ECMA
+
+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
+
+MitM: Man-in-the-Middle, common form of attack against encrpytion systems
+
+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 across 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
diff --git a/doc/references.md b/doc/references.md
new file mode 100644 (file)
index 0000000..c3dafe1
--- /dev/null
@@ -0,0 +1,112 @@
+==References==
+* Our Policies
+  * Terms of Service (ToS)
+  * Certificate Policy on Signing (CPS) + Certification Policy (per Root) (CP)
+  * Data Privacy Policy
+  * Verification Policy
+  * Security Policy
+* 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
+    * JWS
+      * RFC 7515 (JSON Web Signature (JWS), 2015)
+    * 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
similarity index 51%
rename from doc/wishList.md
rename to doc/specification.md
index 20603140e039ea77e0b69d05827568c4eef782b3..d6713ab00945491d459ba6d00385c311946df7de 100644 (file)
@@ -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) ==
@@ -78,7 +20,7 @@ admins (e.g. adobe.com, 3m.com)
 (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 ==
 
@@ -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
- * CCA acceptance
+ * Policy acceptance
 
 == 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
-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)
-* 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)
-* 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)
@@ -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
-* 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) ==
-* 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)
-* 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
- * 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?)
-* 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
-* 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]},
-Assureable{B}, Value{S}, Context{S}, Points{I,Cached}]
+Verifiable{B}, Value{S}, Context{S}, Points{I,Cached}]
 
 
 === 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
-* 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
@@ -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
-assurer)
+agent)
 
 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
-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
@@ -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)
-(+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)
 
-=== WoT management ===
-* Assure a member
+=== Verification management ===
+* Verify a member
   * 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]
-        * 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:
-      * 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
-  * 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 ===
 
-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.
 
-
 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)
 
@@ -406,10 +326,8 @@ Cert Creation:
 * 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)
 
@@ -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 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 ===
-* 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
-* 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
@@ -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
-* 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
 
-=== 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) ===
-  * 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
-  * 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
@@ -506,219 +395,65 @@ recipients:
 === Statisics ===
 
 * running total for current year
-  * assurances
-  * new member
-  * new assurers
+  * verifications
+  * new members
+  * new agents
   * 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
-  * assurances
+  * verifications
   * new member
-  * new assurers
+  * new agents
   * lost members
   * new certs
   * revoked certs
-  * active assurer / assurees
+  * active agents / 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
+  * revoked client certs
   * issued server certs
   * active server certs
+  * revoked server certs
   * issued org client certs
   * active org client certs
+  * revoked org client certs
   * issued org server certs
   * active org server certs
+  * revoked org server certs
   * issued gpg certs
   * active gpg certs
+  * revoked gpg certs
 
 * yearly statistics
-  * assurances
+  * verifications
   * new member
-  * new assuer
+  * new agents
   * 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
-INO: currently quarterly
+  INO: currently quarterly
 
 === 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)