From b9e0dda112b86c2c7fa4af0a4455d221246b0d2d Mon Sep 17 00:00:00 2001 From: Benny Baumann Date: Wed, 22 Feb 2017 21:44:38 +0100 Subject: [PATCH] fix: Somewhat sensibly split the wishlist document This is initial work for cleaning up this document to become the spec Gigi is based on Change-Id: Ie73b567ad9df0de3bf89eeaebec5b229feb2cd4b --- doc/definitions.md | 57 ++++ doc/references.md | 112 +++++++ doc/{wishList.md => specification.md} | 445 ++++++-------------------- 3 files changed, 259 insertions(+), 355 deletions(-) create mode 100644 doc/definitions.md create mode 100644 doc/references.md rename doc/{wishList.md => specification.md} (51%) diff --git a/doc/definitions.md b/doc/definitions.md new file mode 100644 index 00000000..f048d04f --- /dev/null +++ b/doc/definitions.md @@ -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 index 00000000..c3dafe14 --- /dev/null +++ b/doc/references.md @@ -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 diff --git a/doc/wishList.md b/doc/specification.md similarity index 51% rename from doc/wishList.md rename to doc/specification.md index 20603140..d6713ab0 100644 --- 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) == @@ -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) -- 2.39.2