Architecture

The goal of Redwax is to provide tools that allow people to integrate and deploy their own cryptography systems, but without requiring them to roll any cryptography themselves.

Redwax code is pre-rolled for the administrator, so that the administrator doesn't have to.

It must be possible for an administrator to integrate and deploy Redwax code in a reasonable amount of time, and without the need to read an encyclopaedia or understand every nuance of certificate deployment.

Redwax code must be as small in size as it is practically possible to be, with as few abstractions as possible. Linked libraries must be limited to those that need to be there.

While attempting to be flexible, many systems introduce gaps. Whitespace in parameters passed to scripts, incorrectly prepared SQL statements leading to injection risks. Redwax code must be hardened against all inputs, and must be safe to operate without the presence of an application firewall.

Redwax code may still call out to scripts or other code, but this must not be the only option for administrators.

When building up systems made of various layers of abstraction, it is possible that a component falls back onto alternative behaviour should the primary behaviour not be possible. Redwax code must attempt what the administrator configured the code to do, or fail with an error. At no point should Redwax code attempt to compensate by falling back to a less secure choice without the administrator's explicit configuration.

While Redwax code needs to link to cryptographic libraries in order to perform cryptographic functions, it must be technically feasible to swap out one library for another should the use of a particular library no longer be possible. This means that using library specific structures and interfaces within Redwax interfaces must be avoided.

Within Redwax code, all error paths must be handled, every error response must be unique, and the errors themselves must be sensible.