1 == Glossary / Definitions ==
3 ASN.1: A horrible way to encode data. Usually used together with X.509
5 BER: Basic Encoding Rules for ASN.1
7 CER: Canonical Encoding Rules for ASN.1
9 CSR: Certificate Signing Request, request to get some public key signed
11 CSRF: Cross Site Request Forgery, attach technique breaching causality
14 DER: Distinguished Encoding Rules for ASN.1
16 ECMA: European Computer Manufacturers Association
18 ETSI: European Telecommunications Standards Institute
20 GnuPG: GNU Privacy Guard, Some implementation using the OpenPGP standard
22 HSTS: Hypertext Strict Transport Security, Protection Mechanism against
23 casual MitM in networks and SSL Stripping, governed by RFC 6797
25 ITU: International Telecommunication Union, standards body responsible
26 for most standards with a dot in their names
28 JS: JavaScript, an ECMA-Standard
30 JSON: JavaScript Object Notation, standardized way to encode data for
33 MIME: Multipurpose Internet Mail Extensions, some way to stuff multiple
34 messages into one message
36 OAuth: OpenAuthentication standard for SSO
38 OpenPGP: Signature and Encryption format governed by RFC 4880 et. al.
40 OTP: One-Time-Password
42 PKI: Public Key Infrastructure
46 SPKAC: Signed Public Key and Challenge, interactive variant of a CSR
48 SSL: Secure Socket Layer, predecessor of TLS, cf. TLS
50 SSO: Single Sign On, mechanism for authentication accross different
51 domains/systems using a central identity
53 TLS: Transport Layer Security, Protocol for secure communication between
54 a client and a server, governed by various RFCs
56 X.509: An ITU standard describing contents of things (usually abused for
59 XSS: Cross-Site Scripting, attack technique breaching same-origin boundaries
62 == "Todo" (work in active code) ==
64 * Benchmarking (long time + load)
66 * review all date/time uses in order to watch over the timezone.
70 * add email/domain ping
71 * check for domains allowed in policy
72 * black list for special domains not be use by user but through org
73 admins (e.g. adobe.com, 3m.com)
74 * Maybe use Alexa Top 1M as one source
75 * Use copies of DNS zones to identify new domains
76 * Use DNSRBLs to identify young domains
77 * List of well-known top level domains and Second-level sub domains
78 (cf. Public Suffix List below in references)
80 * think about org - certificates
81 * think about names. What are names? how many names? assure names?
85 ** Extract menu from template
86 * Separate content and design
89 = Software requirements / wishes =
91 * Useable without Javascript enabled
92 * Features implemented in Javascript may only enhance features already
93 accessible without Javascript
94 * All pages presented to the user must be HTML5-compliant
95 * All stylesheets must be valid CSS3
96 * All used scripts should be JavaScript/ECMAScript 1.6 or compatible
97 * For security reasons enforced by HSTS/CSP, the following restrictions
98 for included content apply
99 * No inline Javascript
101 * Stylesheets, images, scripts are only allowed from a special
105 * Mail notifications from the system should use OpenPGP or S/MIME signatures
109 * set DoB (default: not set) (has to be before current date - not older
110 than 150 years, check for 29.2.?) (if underage: special ack?) INO: Why
111 not 120 year, which should be sufficent? (People are getting older, not
112 younger ... You know?)
113 * set email(s) - at least one has to be set, primary needs to be set (tbd)
114 * selection of allowed login methods (default: yes for PW and cert)
115 * if PW login is allowed: set PW (tbd) (always initially required as
116 it is hard to issue certificates directly on signup?) ES: If you could
117 do the email-check in the same session that is not mandatory. Even IF it
118 is, this could be done with a 1-time-PW from the mail. - Maybe the
119 complete step could be moved to AFTER the first email-check. It would
120 make more sense, and one could add more explanation and a link to
121 generate said certificate or whatever
122 * selection if pw-recovery per questions should be possible
124 * if yes: pw-recovery q&a have to be set
125 * confirmation that data was entered truthfully and recap of RLO at
129 == Login/authentication ==
130 * Separate Session scope for "www", "secure" and "api"
131 * Authenticate with email and password ("www" only)
132 * Authenticate with client certificate ("secure" + "api")
133 * Authenticate (temporary) with one-time access token (special
134 operations like revocation) (new feature)
135 * Option to switch off/on authentication methods (new feature)
136 * Option to selectively grant permissions to certain types of
137 credentials only (e.g. pw login may only assure someone, while cert XY
138 may do anything, SE interface with cert only) (new feature) ES: I think
139 Benny was speaking about a user setting, while INO was speaking about a
140 fixed global setting - this are two different things!
141 * Reset password by security questions and mail (?? probably not
142 [recommended in all situations])
143 * Option to switch off/on pw recovery per security questions (new feature)
144 * Reset password by assurance (how is this going to be implemented
145 automatically?) Cannot be done automatically at the moment, as this is
146 covered by a process clearly defined by an arbitration precedents-case.
147 - At least not with a new precedents ruling. - Only part is the pw-reset
149 * CCA acceptance at login, if current version of CCA was not accepted by
152 === Account Flags (tbd: collect further (new) flags) ===
153 most should contain dates when set/removed - needed for account log and
155 * Activated (Initial Account Activation Mail received)
156 * CATs passed (FD: virtual = live calculation)
157 * assurer (FD: virtual = live calculation)
159 * CCA accepted (virtual)
162 * PW login allowed (Global for Account)
163 * Cert login allowed (Global for Account, per Cert flags may set actual
165 * PW Recovery function disabled
167 * code signing allowed (Maybe better suited as a Permission for audit of
169 * official nick name allowed (maybe needed for another new feature)
170 * nick name allowed (maybe needed for another new feature)
171 * announcements (general, country, regional, 200km) set
172 * involved in arbitration case (probably virtual, as additional
173 information has to be stored for those entries)
175 === Special Account Permissions and Groups ===
176 TBL: Group [ID{AI/PK}, Name{S}]
177 TBL: GroupMembership [ID{AI/PK}, User{Ref(User)}, Group{Ref(Group)}]
178 TBL: Permission [ID{AI/PK}, Name{S}, ReportTo{S}]
179 TBL: UserPermissions [ID{AI/PK}, User{Ref(User)},
180 Permission{Ref(Permission)}, Action{E(Grant,Revoke)}, Date{Date}]
181 TBL: GroupPermissions [ID{AI/PK}, Group{Ref(Group)},
182 Permission{Ref(Permission)}, Action{E(Grant,Revoke)}, Date{Date}]
184 * Used for special permissions e.g. in support interface, mass mailings
185 * Additionally groups members with additional obligations (e.g. PP-CATS)
187 * manual setting of permissions has to appear in personal and admin-log
189 == personal details (names, DoB) ==
190 * Change personal details (names, DoB) (only if not assured)
191 * after each change, the user has to state, to have those names entered
192 in official documents
193 * maybe adding/removing of non-official nick-name allowed at any time
195 * Allow multiple names that can be assured independently (new) -
196 something like this should be clarified with the AO at least, better to
197 get it fixed clearly in an updated AP (in general AP does allow for this
198 at the moment, but people do not know about this)
200 * 1 name - with a confirmation that one only has exactly one name part
201 * Title? FN+ LN+ Suffix? marked as non-assurable Nick? (could be used
202 for internal processes) - with a confirmation that those are covered by
203 at least one official document owned by the member/potential member
204 * GUI should (until further notice) allow only exactly ONE name (with
205 multiple name-parts) to be entered for an account
206 * Names containing a Nickname component MUST NOT be primary names for an
207 account (BB: Who did the striking? and Why?)
208 * official nicknames may be used, if switched on based on an assurance
210 * else nicknames may only be displayed as an addition and MAY NOT be assured
211 TBL: Name: [ID{AI/PK}, UID{Ref(User}},
212 TBL: NameComponent [ID{AI/PK}, Name{Ref(Name)}, Order{I},
213 Type{E[One,Firstname,Lastname,Title,Suffix,Nick,OfficialNick]},
214 Assureable{B}, Value{S}, Context{S}, Points{I,Cached}]
217 === Domain/email pinging ===
218 * re-ping domains regularly
219 * Domains by automated variants like (see MoPad devDomainPing)
220 * text files at certain locations
222 * opening ssl connections
224 * configure types of pinging
225 * show previous pings with results. -> for support all, for member only
226 during their ownership (new feature)
227 * show status of the various pings and next scheduled events (new feature)
228 * Domain Pings record account ownership at time of ping (new feature)
229 * domain dispute (transfer of domains)
230 * New owner files "Domain Dispute"
231 * Old Owner receives mail with options to Accept, Decline or report
232 (to support) this claim
233 * If Accepted domain is transferred (and existing certificates
234 referencing this domain revoked) [New feature: Old owner may specify
235 which ones, confirmed by new owner]
236 * If any certificates should be kept, new owner is asked to confirm
237 (within certain amount of time) INO: There should be NO handover of cert
238 when moving domains (Needs discussion, new feature, maybe Policy Change
240 * Only after all certificates have either been revoked or been
241 confirmed by the new owner, the domain is finally transferred over.
242 * If the transfer is Declined, no transfer is performed.
243 * If the transfer is reported, information on both parties is sent to
244 support, including a description of the case (entered by the old owner
247 * For emails on a domain within the account
248 * Reachability of the mail accounts is tried within random intervals
250 * If an email by our system is sent and properly accepted by the
251 receiving system, next try for explicit ping is postponed. (maximum
252 postponing of explicit check for about 1 year using this method) ES: has
253 big issues with a) grace period as it removes a big part of security
254 that we want to provide and b) automated contend-less mails as we
255 declare to not address members without reason - a ping would not be
256 considered a reason by our members BB: Outside the grace period the
257 email is considered unconfirmed, and no explicit ping is triggered, but
258 an active operation using this email address will cause a ping mail to
259 be sent. The main reason for this is to reduce the number of ping mails
260 sent when multiple certificates are issued in a given time span (UNDER
262 * If any email address is failing for a certain time, schedule it to
263 be explicitly checked by a ping mail on next use in a certificate
264 * a member should be able to initiate a ping mail
265 * support should be able to initiate a ping (admin-log!)
266 * If this explicit ping mail (with its included token/link) is not
267 confirmed in a reasonable time, a revalidation of the accompanying
268 domain is triggered, including a note to explicitly revalidate the
270 * permanent failing pings should be reported to primary email
272 * permanent failing pings should be displayed after a login (as
273 recent notifications)
274 * For separate mail accounts (outside of domains that are part of an
276 * If regular mails from the system are properly received, postpone
277 automatic checking by at most one year (see ES's and BB's comments above)
278 * send information/ping email before each certificate creation to
280 * this mail may be repeated if unsuccessful, but
281 * HAS TO be successful eventually to complete the issuing of the
282 certificate for the affected email
283 * selection per general setting if such mails must be confirmed
284 before the completion of the certificate issuing
285 * failures have to be displayed directly and in logs
286 * permanent failures have to be reported to primary email address once
287 * permanent failures should be displayed after a login (as recent
289 * option to inform primary email, also (general setting + selectable
290 at certificate issue time)
292 == Certificate Management ==
293 * List all issued certificates per kind
294 * Revoke issued certificates
295 * renew certificates (re-issue a previous CSR) INO: what is if the old
296 CSR does not meet the requiremnts any more eg. weak keys -> Prefill of
297 the CreateCert-Dialog with the existing data for the cert/csr
298 * select md (sha2-512, sha2-384, sha2-256, sha3-512, whirlpool?, ...)
299 * select duration up to maximum allowed for member
300 * select (assured) name components / acronyms thereof
301 * select (ping-approved) domains / email-addresses
302 * select class (up to what is allowed for member)
303 * select if allowed for login as described above @ login
304 * change comment of certificate
306 MAYBE: * schedule to issue certificates for a day in the next two weeks.
307 (Should require someone who knows what he's doing, requires experienced
310 Notification Mail about new certificate may include link for revocation
313 Process for issuing a certificate:
314 1. Upload CSR / Generate key in Browser
315 (That's actually step 2)1a.for browser generation: selection for
316 names, emails, domains, certificate root
317 2. Confirm values and if necessary modify them
318 3. Select additional settings (login, comments, ...) and validity interval
319 4. confirm CCA + confirm the issuing of the certificate as shown
320 (do 1a to 4 in one form? - Could be done with JS enabled)
321 5. send information (ping) mail to affected address (& primary if
322 selected), display failures + potential abort
323 6. Show Progress Page with JS hinting when it is done / otherwise using
325 7. Display a page with the final Certificate and details about it.
327 Process of re-issuing certificate:
328 1. click certificate (this creates the form-process)
329 2. review all previous-entered settings. (inputs will be re-checked when
330 sent: is name still valid/etc. still have all rights.)
331 3. rest as above, formulations adapted to re-issuing
333 === Certificate types ===
334 * Email certificates (include email (+ real name if points>=50)
335 (+codesigning if enabled && Assurer)
336 * Domain certificates (include domain name + SANs (+real name if
338 * Organisation Email certificates
339 * Organisation Domain certificates
340 * Split more templates (e.g. Email from Code Signing)
342 === WoT management ===
344 * enter email address + DoB
346 * if member was assured before by this assurer:
347 * currently: abort process with according information - but:
348 this may be changed later
349 * if there was no previous assurance by the assurer over the member:
350 * names shown [has to be defined in more detail]
352 * primary email shown
353 * confirmation that names + DoB could be verified were official
355 * select if TTP [further details TBD]
356 * free-text-field: location of assurance - default: empty -
358 * date of assurance selection, default: non selected (not before
359 DoB, not after current date+13h) - needs to be set INO: Current Date UTC
360 + 12 h BB:(13h, cause of timezones with +13h)
361 * confirmation that assuree has accepted CCA
362 * confirmation box, that AP was followed
363 * CCA acceptance box for assurer
364 * display if member was underage at assurance date, when set
365 [TBD] and force a check-box-selection to confirm that PoJam process was
367 * if not correct independent of which was wrong:
368 * option to write an automated email to the member that the
369 assurer tried to assure the member
370 * View all assurances received/done
371 * points, locations, dates of assurance, dates of assurance entered,
372 name of assurer/assuree, revocations
373 * show how my points are calculated
374 * as assuree, as assurer
375 * search for assurers/etc (what exactly is this community-thing)
376 * Search for assurer is referred to Portal (cacert.eu) ES: I really
377 would like to have this feature again in the main software- in both
378 directions, with the option to enter multiple locations at least
379 temporary (permanent location, current location), we should make it easy
380 for travelling assurer and assurees to spread assurances around! BB: I
381 agree to ES: Having it in the software makes many things much more easy.
382 * What is about multiple assurances for the same assuree, only last
383 Assurance should count. (New Feature) - ES: currently this would need
384 more details in policies - we do not know how this would resolve, we may
385 only guess that it would be the last one
386 * Experience Points only for the last of such re-assurances (New
387 Features) - ES: again, this should wait for a policy decision
389 === Organisation management ===
391 rethink? what needs to be done? what needs to be possible? how much is
393 * The Org area can be shifted back for now.
397 * OrgAssurer: can create and administer the OrgAccounts, administer: add
398 and delete OrgAdmin, add and delete Org Domains, does not have access to
400 * OrgMaster: can see the Org account data; add/remove other OrgMasters
402 * OrgAdmin: can see the org account data; is able to administer the certs
403 * SE: is able to see account data, revoke certs (new feature)
406 * Client Cert with form
407 * Client Cert with CSR (New feature)
408 * Client Cert with multiple email addresses
409 * Multiple Client Certs via file upload and result download (create e.g.
410 10 certs with one upload) (New Feature)
411 * revoke cert via file upload, e.g. file with to email addresses all
412 certs to these addresses will be revoked. (New Feature)
414 * Filter on client cert page (new feature)
416 * Domain Cert with CSR
418 * Org Account History
419 * Org account full history visible by OrgAdmins, SE via Ticket Number
420 * Org Account history only account information without cert history by
423 * OrgAssurer should be able to perform an IsAssuer check.
427 === OpenPGP key signing ===
428 * if points >= 50 allow signing of OpenPGP key with real name, no
429 comment field, matching email in account.
430 * UserIDs on key to be signed user-selectable.
431 * Expiry date: selectable up to maximum allowed
432 * re-signing without need to uploade key again
433 * CCA acceptance needed for all signatures
434 * lookup of keys on keyserver (if present)
435 * Ensure key has basic cryptographic security:
436 * conformant to normal certificate's requirements
439 === Signer interface ===
441 * allow multiple signer instances
444 === SE management (not finished) ===
445 * nothing happens without support ticket id (that is verified?) <- ES:
446 currently the basic account can be seen without a ticket number
447 * Support Ticket, Arbitration; see existing software on this <- ES:
448 currently other tickets are allowed, too, but I see no need, as one of
449 both should be needed (there will always be a support ticket number, if
450 support is addressed as such - there should be no need for anybody to
451 neither go this way nor through arbitration (arbitration may have
452 reasons to go directly to a supporter but has the authority to do so)
453 * every action on a member will cause an email to be sent to him and the
454 action is being logged. <- the mail should be optional (to primary
455 address) and only once in a given time frame/login, as a supporter may
456 need to do more than one thing at a time
457 * View/edit users personal details (even if assured)
458 * set account flags (code signing, assurer status, block of account,
459 ttp, org-admin, support, team member)
460 * delete/invalidate assurances
461 * revoke certificates, pgp-key signatures, both should be possible for
462 single certificates/keys or for all certificates/keys
465 === Arbitration interface (new feature) ===
466 * everything requires: arbitration number, role in arbitration case
467 (iCM, CM, Arbitrator)
468 * everything has to be shown in admin log for support and in account log
469 * show CCA acceptance for user identified by email (does not have to be
470 primary) (only latest version of accepted CCA)
471 * show primary email for email address
472 * show arbitration case number of arbitration cases, a user identified
473 per email address is involved in
474 * mark/unmark user identified per email (does not have to be primary)
475 as involved in an arbitration case (by numbers)
476 * set CCA acceptance for user identified by email (date, "before
478 * running arbitration case should be visible to SE - ES: That is NOT
479 part of the arbitration interface! And currently it would be enough, if
480 delete account process would be stopped by the member being involved in
481 an arb case, telling that there is an arb case (not which and how many)
482 - currently this information is not needed in any other support case and
483 involvement in arbitration cases is anonymous.
485 === automated (outside of a current process) information mails to
487 * certificate(s)/signature expires within the next 14 days (combined or
490 === "mass mails" interface (new feature) ===
491 * access only for critical team (or other restricted personal
492 controlled by arbitration)
493 * arbitration case number needed (maybe announcement flags could be
494 allowed for support case numbers or motions, as well)
495 * requester has to be set (identified by email)
496 * text-field for subject
497 * text-field for mail-content
498 * one of the following three should be possible for selection of
501 * list of email addresses
502 * list of account-ids
503 * selection field if this should be noted in account-logs of recipients
504 * announcement flag (general, ...)
508 * running total for current year
513 * active assurers (at least one assurance according to the assurance
514 date of the current year)
515 * active assurees (who got the latest assurance in the current year)
517 * running total for last 12 months per month
524 * active assurer / assurees
530 * user >= 50 and <99 AP
533 * issued client certs
534 * active client certs
535 * issued server certs
536 * active server certs
537 * issued org client certs
538 * active org client certs
539 * issued org server certs
540 * active org server certs
551 * active assurers (at least one assurance according to the assurance
552 date of the current year)
555 access statistic data via API e.g. assurance per year is needed for
558 the active assurees may be relevant for any decision in the regard how
559 long assurances should be valid and if they need to be renewed. It also
562 === Premission Review mails (monthly?) ===
563 * Regular check and report of permissions for various groups of people
564 INO: currently quarterly
568 * + lookup OCSP/CRL status.
569 * OpenPGP key inspector (Yup, we need one)
570 * Database Editor CLI tool for crit to update records (and their
571 checksums/timestamping)
575 * CAcert Community Agreement (CCA)
576 * Dispute Resolution Policy (DRP)
577 * Certificate Policy on Signing (CPS) + Certification Policy (per
579 * Security Policy (SP) / Security Manual (SM)
580 * Assurance Handbook (AH) + Practice on Names (PoN)
581 * Policy on Junior Assurers and Members (PoJAM)
582 * Trusted Third Party (TTP) and Sub-Policies
583 * Organisation Assurance Policy (OAP)
584 * Policy on Policy (PoP)
585 * CAcert Website Data Privacy Policy (currently WIP) WDPP
589 * RFC 0791 (IPv4: Internet Protocol, 1981)
590 * RFC 2460 (IPv6: Internet Protocol, Version 6 (IPv6)
593 * RFC 1945 (HTTP/1.0, 1996)
594 * RFC 2616 (HTTP/1.1, 1999)
595 * RFC 7230 (HTTP/1.1: Message Syntax and Routing, 2014)
596 * RFC 7231 (HTTP/1.1: Semantics and Content, 2014)
597 * RFC 7232 (HTTP/1.1: Conditional Requests, 2014)
598 * RFC 7233 (HTTP/1.1: Range Requests, 2014)
599 * RFC 7234 (HTTP/1.1: Caching, 2014)
600 * RFC 7235 (HTTP/1.1: Authentication, 2014)
602 * RFC 3268 (TLS 1.0+: Advanced Encryption Standard (AES)
603 Ciphersuites for Transport Layer Security (TLS), 2002)
604 * RFC 4347 (DTLS 1.0: Datagram Transport Layer Security, 2006)
605 * RFC 4492 (TLS 1.0+: Elliptic Curve Cryptography (ECC) Cipher
606 Suites for Transport Layer Security (TLS), 2006)
607 * RFC 4346 (TLS 1.1: The Transport Layer Security (TLS) Protocol
609 * RFC 4366 (TLS 1.0+: Transport Layer Security (TLS) Extensions, 2006)
610 * RFC 5246 (TLS 1.2: The Transport Layer Security (TLS) Protocol
612 * RFC 5764 (TLS 1.0+: Transport Layer Security (TLS) Renegotiation
613 Indication Extension, 2010)
614 * RFC 5878 (TLS 1.0+: Transport Layer Security (TLS) Authorization
616 * RFC 6176 (SSL 2.0: Prohibiting Secure Sockets Layer (SSL)
618 * RFC 7027 (TLS 1.0+: Elliptic Curve Cryptography (ECC) Brainpool
619 Curves for Transport Layer Security (TLS), 2013)
621 * RFC 6797 (HSTS: HTTP Strict Transport Security, 2012)
623 * RFC 2459 (X.509: Internet X.509 Public Key Infrastructure
624 Certificate and CRL Profile, 1999)
625 * RFC 3280 (X.509: Internet X.509 Public Key Infrastructure
626 Certificate and Certificate Revocation List (CRL) Profile, 2002)
627 * RFC 4325 (X.509: Internet X.509 Public Key Infrastructure
628 Authority Information, Access Certificate Revocation List (CRL)
630 * RFC 4630 (X.509: Update to DirectoryString Processing in the
631 Internet X.509 Public Key Infrastructure Certificate and Certificate
632 Revocation List (CRL) Profile, 2006)
633 * RFC 5280 (X.509: Internet X.509 Public Key Infrastructure
634 Certificate and Certificate Revocation List (CRL) Profile, 2008)
636 * RFC 1991 (OpenPGP: PGP Message Exchange Formats, 1996)
637 * RFC 2440 (OpenPGP: OpenPGP Message Format, 1998)
638 * RFC 4880 (OpenPGP: OpenPGP Message Format, 2007)
639 * RFC 5581 (OpenPGP: The Camellia Cipher in OpenPGP, 2009)
640 * RFC 6637 (OpenPGP: Elliptic Curve Cryptography (ECC) in OpenPGP,
643 * RFC 4627 (JSON: The application/json Media Type for JavaScript
644 Object Notation (JSON), 2006)
645 * RFC 7158 (JSON: The JavaScript Object Notation (JSON) Data
646 Interchange Format, 2013)
647 * RFC 7159 (JSON: The JavaScript Object Notation (JSON) Data
648 Interchange Format, 2013)
649 * ECMA 404 (JSON: The JSON Data Interchange Format, 2013)
651 http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
653 * RFC 2045 (MIME: Multipurpose Internet Mail Extensions (MIME)
654 Part One: Format of Internet Message Bodies, 1996)
655 * RFC 2046 (MIME: Multipurpose Internet Mail Extensions (MIME)
656 Part Two: Media Types, 1996)
657 * RFC 2047 (MIME: MIME (Multipurpose Internet Mail Extensions)
658 Part Three: Message Header Extensions for Non-ASCII Text, 1996)
659 * RFC 2048 (MIME: Multipurpose Internet Mail Extensions (MIME)
660 Part Four: Registration Procedures, 1996)
661 * RFC 2049 (MIME: Multipurpose Internet Mail Extensions (MIME)
662 Part Five: Conformance Criteria and Examples, 1996)
663 * RFC 2183 (MIME: Communicating Presentation Information in
664 Internet Messages: The Content-Disposition Header Field, 1997)
665 * RFC 2184 (MIME: MIME Parameter Value and Encoded Word
666 Extensions: Character Sets, Languages, and Continuations, 1997)
667 * RFC 2231 (MIME: MIME Parameter Value and Encoded Word
668 Extensions: Character Sets, Languages, and Continuations, 1997)
669 * RFC 5335 (MIME: Internationalized Email Headers, 2008)
670 * RFC 6532 (MIME: Internationalized Email Headers, 2012)
672 * RFC 1847 (S/MIME: Security Multiparts for MIME: Multipart/Signed
673 and Multipart/Encrypted, 1995)
674 * RFC 2633 (S/MIME: S/MIME Version 3 Message Specification, 1999)
675 * RFC 3851 (S/MIME: Secure/Multipurpose Internet Mail Extensions
676 (S/MIME) Version 3.1 Message Specification, 2004)
677 * RFC 5751 (S/MIME: Secure/Multipurpose Internet Mail Extensions
678 (S/MIME) Version 3.2 Message Specification, 2010)
681 * http://www.w3.org/TR/html-markup/
682 * http://dev.w3.org/html5/html4-differences
684 * http://www.w3.org/Style/CSS/
685 * JavaScript / ECMAScript
687 http://standards.iso.org/ittf/PubliclyAvailableStandards/c055755_ISO_IEC_16262_2011(E).zip
688 * http://ecma-international.org/ecma-262/5.1/
690 * XML 1.0: http://www.w3.org/TR/2008/REC-xml-20081126/
691 * XML 1.1: http://www.w3.org/TR/2006/REC-xml11-20060816/
692 * Content Security Policy
693 * Version 1.0: http://www.w3.org/TR/CSP/
695 https://w3c.github.io/webappsec/specs/content-security-policy/
697 * Public Suffix List of
698 http://publicsuffix.org/
700 * Unicode Technical Report 39: http://www.unicode.org/reports/tr39/
703 * Information technology � ASN.1 encoding rules: Specification of
704 Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
705 Distinguished Encoding Rules (DER)
706 http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
709 * Baseline Requirements
710 https://cabforum.org/baseline-requirements-documents/
714 * Research on Password strength
715 Carnegie Mellon University: Guessing again (and again and again)
716 https://www.ece.cmu.edu/~lbauer/papers/2012/oakland2012-guessing.pdf
717 Presentation on the findings of the paper:
718 https://www.youtube.com/watch?v=USMd3swFZp4
719 * SCrypt Key Dervation Function
720 http://www.tarsnap.com/scrypt.html
721 Colin Percival, Stronger Key Derivation via Sequential Memory-Hard
722 Functions, presented at BSDCan'09, May 2009:
723 * http://www.tarsnap.com/scrypt/scrypt.pdf
724 * http://www.tarsnap.com/scrypt/scrypt-slides.pdf