add: ignored line breaks to template syntax

[gigi.git] / doc / wishList.md

== 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