+++ /dev/null
-== 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
projects / gigi.git / blobdiff