Table of Contents
1. Table of Contents
2. Purpose of this Document
3. Other Documents / Other Sections?
4. Requirements
1. R1. Authentication
1. R1.a Recovery
2. R1.b SSO
3. R1.c Existing methods
4. R1.d Add New Methods
5. R1.e Minimise Sign-in Torture
2. R2. Messaging Layer
3. R3. Logging
1. R3.a Simple Identification Scheme for debugging messages
2. R3.b Simple Debug Call
3. R3.c Auditable Logging
4. R4. i18n
5. R5. Features driven by Points and Binary flags
6. R6. URL Sanity
1. R6.a Redirects
2. R6.b RESTful and Cool URIs
7. R7. Signed Attest Statement
8. R8. Independence
1. R8.a Platform Independence
2. R8.b Package minimilisation
3. R8.c Language Flexibility
9. R9. Multiple Signers
1. R9.a Signing Profiles
10. R10. Secure (email) Messaging
11. R11. Backups and Recovery
12. R12. Modern Website
13. R13. Not Sure:
5. Architectural Principles
1. A1. Outsource
2. A2. Messaging
1. A2.a Idempotent
2. A2.b asynchronous operations
3. A3. Meta-Things
4. A4. File a dispute
5. A5. Centralised Crypto
This document is intended as a design document specifying the architecture of the proposed CAcert software. It is also to be used to specify the requirements guiding this design process. The first use of this document should be as a guideline during the development of new CAcert software. Later on, after development has achieved some form of completion (for any value of complete), this document could also become the documentation of the new software systems.
We possibly need a panopoly of documents. Something like:
Business Requirements => Architecture => Design => Module Specifications
Should we put this all in this one document for now? Or should we create many side-by-side documents?
Below is the way Iang does things, as a sort of starter. Anyone got a better way?
There should be a robust and scaleable way to handle the loss of Member authentication data.
Should support / rely / push / pull Single Sign On. E.g., CATS insists that the prospective Assurer get a certificate and install in the browser. Once that is there, certificate log-in is randomly easy :-) This is not a requirement to necessarily support SSO on the main site (security!?) but to align its actions with the community need to get SSO going elsewhere. For example, we could insist that people with 1 point get a certificate ... and use that in preference to password login (however consider this carefully in contrast to R1).
Support at least passphrase, client certificates and "net cafe" login methods.
we should have the ability to add new methods of authentication for example biglumber.com method. PGP encrypted mail with a generated password (login token) and then the option to see how long the cookie will last. old login tokens can be invalidated.
Incrementally enable features. E.g., it should be easier to see what certs are in existance than to see the lost-password questions.
We need a fairly good robust messaging layer, something that works for everything.
There should be a unified logging / event reporting / debugging approach. Some way to separate out the logs from all other data and send them through separate channels to somewhere safe.
E.g in Java, it might be that all logging is done as direct appends to open files, whereas all action data goes through IPC and is stored in databases.
Each debugging message should include some indication as to where it is. The scheme I like it to include a car numberplate in each debug line, like: debug("A-49165; i just saw a null pointer"). Then, the investigator does a global search for A-49165 and finds the string in seconds instead of having to trawl through indexes, ontologies, and what-not.
And, a call or framework that allows powerful messaging to be trapped. Of course this could be very old-world, maybe newer working practices dispense with debugging traces?
The logged messages should be robust and unchangeable. Easiest way to do this is hash chaining, but there may be other ideas.
Probably we need some form of multilingual support. How successful is the existing set of languages?not probably, absolutetly! I think we should continue using translingo (gettext) -Alejandro Mery 19/03/2009 16:10
A set of features that are configurable according to a number of points systems. Now we have Assurance Points and Experience Points. Also there are "support" flag, and likely others.
handle redirects on current URIs which could be bookmarked or linked from somewhere.
Like https://foo/noun/arg1/arg2 instead of https://foo/doh.cmd?id=deadbeef&yousuck=1x%x%...
In short been RESTful means the URI reference the resource, and POST the actions. each domain, each mail address, each user has his own URI. Obviously ACL have to be applied.
The system should be able to accept signed attest statements. E.g., an Assurance could be a signed statement from Alice with the tuple "Bob, 10 points, signature." However we would then have the issue that the attest would go into the system, and bounce, if the data in there could not be matched.
What is the situation on Assurers looking at user information? Are they trusted to do this or not, in the context of an Assurance?
Suggestions from AM: Member enables an Assurer to see his data (thawte's method). Assurer does not see the DoB, he has to enter it and the system compares.
As much as possible the software should do its own thing, and not be dependent on difficult issues.
To the extent possible it should run on all Unix platforms, including BSD (as latter have much better security profiles). Likely it is easier to develop on Linux, as they have better support.
The software should try not to drag in other packages. you mean dependencies minimisation? -Alejandro Mery 19/03/2009 17:29
It would be nice to integrate in different components based on distinct languages that are better for the immediate job. This basically means using a message or request/response API (sometimes called web-api).
There should be an ability to deal with multiple secure signing modules. E.g., we should be able to deal with a few of the current serial line module and also HSMs.
The current design has some form of "profiles" where the matched CSR directs the actions to follow.
There needs to be some way to facilitate sending a reliable/secure email to a Member. E.g., an Arbitration notification.
This may be an ability for some Members to type in a message to a user's account which is held there in an "message box", or it may just be a way to send out an email, possibly signed by CAcert, or a combination of features.
There should be a designed-in ability to export the entire data set and to incorporate the entire data set easily. It is not acceptable to throw the system over the wall and say "just back up the MySQL."
"modern" look & feel (simple, short texts, "large fonts", colourful, visual)
The website needs an ability to re-invent itself from time to time. This means 3-tier architecture?for a web application I think MVC fits better -Alejandro Mery 19/03/2009 18:27
5. Some sort of mobile-phone friendly basic interface. mobile use cases need to be identified -Alejandro Mery 19/03/2009 18:29
6. minimize exposing private data to assurers which could be attackers. (e.g. we show fully name and DoB to anyone claiming to be going to assure someone)
According to a recent decision, two checks are required for each email address and domain, in order to add a cert.
Where possible, the checks should be permanently repeatable.
A basic email probe and prove facility is needed. Current design is to take the registry email addresses and the added email addresses, offer them to the user, take a selection, send a URL, wait until the URL is clicked. Deliver the "proven" result back to caller. Log the time/type of check so that future checks can be conducted automatically.
A basic probe of some fact about DNS. Design is to offer some selection of records to set, and when done, initiate a DNS check to see if there. E.g., add alias cacertxyz123.example.com. The record should be left in place, and probed occasionally for continual check. Once checked this way, this forms one of the two required checks
Ask for some file or header on the website to be placed there, and left there.
Ask for some field to be set such as a DNS server (extreme) or adding CAcert-123xyz into the Technical contact as authority for CAcert to be a technical issuer of certs. This method is slightly superior in legal sense because it tests ownership as well as control.
A module that takes / provides the sum of all above and reveals a single decision on request.
Where some feature can be outsourced to a community site, it should be. A great example of this is CATS. These could also be considered for outsourcing:
Many of these rely on the certificate being used to ease the authentication into other websites. Basically, SSO.
The system should be fundamentally designed on the basis of messaging. Send a message, wait for a response. This should be at the highest level. No connection-oriented stuff at all. It should all be state machines. Send, wait. Resend or get or fail.
An implication of messaging (or is it the other way around?) is that all actions should be idempotent / atomic. That is, they happen either 0 or 1 times and they are repeatable. For example, Alice can add an assurance of Bob as many times as she likes, she always ends up with precisely 1 (or 0) assurances.
Everything built to be asynchronous: cert signing, pings, validation, ...
Things that don't need to be said?
Where possible, consider kicking things across to Arbitration.
Where Crypto is heavily used, it should generally be centralised in a single area, and all code should work with the features used there. This enables a crypto plumber to get a good oversight of the use and reliance on crypto, and to maintain the security. It also allows a complete replacement, which is a useful thing where some crypto libraries are poor quality.