== 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 = Todo list = == "Todo" (work in active code) == * Benchmarking (long time + load) * review all date/time uses in order to watch over the timezone. == Missing == * add email/domain ping * check for domains allowed in policy * black list for special domains not be use by user but through org admins (e.g. adobe.com, 3m.com) * Maybe use Alexa Top 1M as one source * Use copies of DNS zones to identify new domains * Use DNSRBLs to identify young domains * List of well-known top level domains and Second-level sub domains (cf. Public Suffix List below in references) * OpenPGP integration * think about org - certificates * think about names. What are names? how many names? assure names? == Makeup == ** Extract menu from template * Separate content and design = Software requirements / wishes = == Generic == * Useable without Javascript enabled * Features implemented in Javascript may only enhance features already accessible without Javascript * All pages presented to the user must be HTML5-compliant * All stylesheets must be valid CSS3 * All used scripts should be JavaScript/ECMAScript 1.6 or compatible * For security reasons enforced by HSTS/CSP, the following restrictions for included content apply * No inline Javascript * No inline CSS * Stylesheets, images, scripts are only allowed from a special "static" subdomain == Notifications == * Mail notifications from the system should use OpenPGP or S/MIME signatures == Registration == * set names (tbd) * set DoB (default: not set) (has to be before current date - not older than 150 years, check for 29.2.?) (if underage: special ack?) INO: Why not 120 year, which should be sufficent? (People are getting older, not younger ... You know?) * set email(s) - at least one has to be set, primary needs to be set (tbd) * selection of allowed login methods (default: yes for PW and cert) * if PW login is allowed: set PW (tbd) (always initially required as it is hard to issue certificates directly on signup?) ES: If you could do the email-check in the same session that is not mandatory. Even IF it is, this could be done with a 1-time-PW from the mail. - Maybe the complete step could be moved to AFTER the first email-check. It would make more sense, and one could add more explanation and a link to generate said certificate or whatever * selection if pw-recovery per questions should be possible (explanatory text!) * 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 == Login/authentication == * Separate Session scope for "www", "secure" and "api" * Authenticate with email and password ("www" only) * Authenticate with client certificate ("secure" + "api") * Authenticate (temporary) with one-time access token (special 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 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 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) * blocked account * deleted account * PW login allowed (Global for Account) * Cert login allowed (Global for Account, per Cert flags may set actual permissions) * PW Recovery function disabled * PW Reset Required * code signing allowed (Maybe better suited as a Permission for audit of Dates) * official nick name allowed (maybe needed for another new feature) * nick name allowed (maybe needed for another new feature) * announcements (general, country, regional, 200km) set * involved in arbitration case (probably virtual, as additional information has to be stored for those entries) === Special Account Permissions and Groups === TBL: Group [ID{AI/PK}, Name{S}] TBL: GroupMembership [ID{AI/PK}, User{Ref(User)}, Group{Ref(Group)}] TBL: Permission [ID{AI/PK}, Name{S}, ReportTo{S}] TBL: UserPermissions [ID{AI/PK}, User{Ref(User)}, Permission{Ref(Permission)}, Action{E(Grant,Revoke)}, Date{Date}] 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) * 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) * 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 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 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 by support * else nicknames may only be displayed as an addition and MAY NOT be assured 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}] === Domain/email pinging === * re-ping domains regularly * Domains by automated variants like (see MoPad devDomainPing) * text files at certain locations * DNS TXT records * opening ssl connections * configure types of pinging * show previous pings with results. -> for support all, for member only during their ownership (new feature) * show status of the various pings and next scheduled events (new feature) * Domain Pings record account ownership at time of ping (new feature) * domain dispute (transfer of domains) * New owner files "Domain Dispute" * Old Owner receives mail with options to Accept, Decline or report (to support) this claim * If Accepted domain is transferred (and existing certificates referencing this domain revoked) [New feature: Old owner may specify which ones, confirmed by new owner] * If any certificates should be kept, new owner is asked to confirm (within certain amount of time) INO: There should be NO handover of cert when moving domains (Needs discussion, new feature, maybe Policy Change required) * Only after all certificates have either been revoked or been confirmed by the new owner, the domain is finally transferred over. * If the transfer is Declined, no transfer is performed. * If the transfer is reported, information on both parties is sent to support, including a description of the case (entered by the old owner when reporting) * email ping * For emails on a domain within the account * Reachability of the mail accounts is tried within random intervals (silent) * If an email by our system is sent and properly accepted by the receiving system, next try for explicit ping is postponed. (maximum postponing of explicit check for about 1 year using this method) ES: has big issues with a) grace period as it removes a big part of security that we want to provide and b) automated contend-less mails as we declare to not address members without reason - a ping would not be considered a reason by our members BB: Outside the grace period the email is considered unconfirmed, and no explicit ping is triggered, but an active operation using this email address will cause a ping mail to be sent. The main reason for this is to reduce the number of ping mails sent when multiple certificates are issued in a given time span (UNDER HEAVY DISCUSSION) * If any email address is failing for a certain time, schedule it to be explicitly checked by a ping mail on next use in a certificate * a member should be able to initiate a ping mail * support should be able to initiate a ping (admin-log!) * If this explicit ping mail (with its included token/link) is not confirmed in a reasonable time, a revalidation of the accompanying domain is triggered, including a note to explicitly revalidate the failing address) * permanent failing pings should be reported to primary email address once * permanent failing pings should be displayed after a login (as recent notifications) * For separate mail accounts (outside of domains that are part of an account): * If regular mails from the system are properly received, postpone automatic checking by at most one year (see ES's and BB's comments above) * send information/ping email before each certificate creation to affected email(s), * this mail may be repeated if unsuccessful, but * HAS TO be successful eventually to complete the issuing of the certificate for the affected email * selection per general setting if such mails must be confirmed before the completion of the certificate issuing * failures have to be displayed directly and in logs * permanent failures have to be reported to primary email address once * permanent failures should be displayed after a login (as recent notifications) * option to inform primary email, also (general setting + selectable at certificate issue time) == Certificate Management == * List all issued certificates per kind * Revoke issued certificates * renew certificates (re-issue a previous CSR) INO: what is if the old 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 (ping-approved) domains / email-addresses * select class (up to what is allowed for member) * select if allowed for login as described above @ login * change comment of certificate 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) Notification Mail about new certificate may include link for revocation (new feature) Process for issuing a certificate: 1. Upload CSR / Generate key in Browser (That's actually step 2)1a.for browser generation: selection for 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 (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 6. Show Progress Page with JS hinting when it is done / otherwise using redirects in HTML 7. Display a page with the final Certificate and details about it. Process of re-issuing certificate: 1. click certificate (this creates the form-process) 2. review all previous-entered settings. (inputs will be re-checked when sent: is name still valid/etc. still have all rights.) 3. rest as above, formulations adapted to re-issuing === Certificate types === * Email certificates (include email (+ real name if points>=50) (+codesigning if enabled && Assurer) * 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 * 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: * 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 * 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 * 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 === Organisation management === 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 * OrgAdmin: can see the org account data; is able to administer the certs * SE: is able to see account data, revoke certs (new feature) 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) * Filter on client cert page (new feature) * Domain Cert with CSR * 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 * OrgAssurer 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. * 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 * lookup of keys on keyserver (if present) * Ensure key has basic cryptographic security: * conformant to normal certificate's requirements * valid key material === Signer interface === * database based * allow multiple signer instances * job table === SE management (not finished) === * nothing happens without support ticket id (that is verified?) <- ES: currently the basic account can be seen without a ticket number * Support Ticket, Arbitration; see existing software on this <- ES: currently other tickets are allowed, too, but I see no need, as one of both should be needed (there will always be a support ticket number, if support is addressed as such - there should be no need for anybody to neither go this way nor through arbitration (arbitration may have reasons to go directly to a supporter but has the authority to do so) * every action on a member will cause an email to be sent to him and the 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 * "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) === "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) * 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: * sql-query * list of email addresses * list of account-ids * selection field if this should be noted in account-logs of recipients * announcement flag (general, ...) === Statisics === * running total for current year * assurances * new member * new assurers * 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) * running total for last 12 months per month * assurances * new member * new assurers * lost members * new certs * revoked certs * active assurer / assurees * Grand Total * members * assurances * granted AP * user >= 50 and <99 AP * assurer candidates * assurer * issued client certs * active client certs * issued server certs * active server certs * issued org client certs * active org client certs * issued org server certs * active org server certs * issued gpg certs * active gpg certs * yearly statistics * assurances * new member * new assuer * lost members * new certs * revoked certs * active assurers (at least one assurance according to the assurance date of the current year) * active assurees access statistic data via API e.g. assurance 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 === Premission Review mails (monthly?) === * Regular check and report of permissions for various groups of people 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