Also see the user workflows and components.


We would like to have an memorable and interactive demo on a fully-free system ready by October, 2015 or January, 2016.


The demo needs to showcase an interesting arrangement or combination of technologies that the FreedomBox supports.

The audience can participate with and operate on the running system.
The system will be created from fully-free components, at the software, firmware, and hardware level:
The system will use only the Debian-main archive.

The system will not include any binary blobs in any drivers, and none will be needed to use the fully functional system. See GNU linux-libre.


The system will use freely-designed hardware, that which the four fundamental software freedoms can be applied to.

Making it Memorable

To be memorable, the demo should do something that no demo has done before. Right now, in June 2015, the FreedomBox project is pretty close to accomplishing something completely new: making PGP-based client certificate authentication easy.

To do this, the server needs to be able to:

1. identify specific users in an HTTP-session based on PGP keys, 2. authorize or deny specific users in an HTTP-session based on a centralized service authorization system, and, 3. configure the available services and authorized users in a centralized service configuration system.

To do this, the client needs to be able to:

1. log in to the server with a client certificate.

If the server and client can do those things, we've made HTTP client certificates possible, but not easy. To make HTTP client certificates easy, (1) the server must be able to provide clients with SSL Client Certificates based on their PGP keys, and (2) the client must be able to import the SSL Client Certificate from the server.

Since the SSL client certificate is self-validating, the client can verify that the server isn't deceiving it (the client certificate must refer back to the client's original PGP key). Otherwise, this doesn't affect the standard PGP trust-model at all: in the standard PGP threat-model, anyone can already create a key for anybody, anyway.

Making it Interactive

To be interactive, users need to be able to log into the system and use the service. Users should be able to interact with one another, like in a chatroom.

If we were to make a presentation where Debian Developers, or anyone in the strongly trusted set of PGP keys, could automatically log into a service as themselves and communicate, that'd be pretty memorable. We could do that through a few services, like Jabber (ejabberd server and jwchat web UI), ownCloud, ikiwiki, or others.

To do this, each service on the box must use the client certificate's user identifier as the user's service id, and must defer to the box's centralized authorization layer to determine whether that user can access that service or not.

Getting from Here to There

To be ready for the demo, the system must import the keys of pre-authorized users, those users must download and install their PGP-SSL-client-certificate from the server, available over the demo's LAN. Users will then connect to the server, be automatically logged in through their client certificate, and access any of the available services.


At a high level, the server and client need to be able to perform these duties.


Client Certificate Identification (Authentication)

Client Authorization

Administrative Service Access Control Layer (ACL)

PGP Key Generation

PGP SSL Client Certificate Generation


Client Certificate Identification

The UI sucks, but any standard desktop browser can already import a client certificate and use it to authorize to a server, including:

- Firefox/Debian Ice Weasel/GNU Ice Cat - Chrome - Internet Explorer

Client Certificate Keyring Import

To make Client Certificate Identification easy, we should release an extension that handles importing and trusting the user's client certificate for the user.

Necessary Tools & Services

We need these items for the demo, but they do not yet exist.

Apache Client Certificate Identification

Apache will read the SSL client certificate id to supply the necessary Client Certificate Identification (Authentication).

LDAP Authorization

LDAP will manage client authorization to allow or deny the client access to the service. See the wiki's notes for further details.

Plinth Centralized Service ACL

Plinth will handle user-service access (authorization).

Plinth PGP-Key and PGP-SSL-Client-Certificate Creation

Plinth will manage PGP Key Generation and PGP SSL Client Certificate Generation. When a user without a client certificate connects to the server, they'll be directed to the key generation tools

The PGP key generation tools should be disabled during the demo because they could easily overwhelm the server.

Client Certificate Keyring Import Extension

A Firefox extension will manage Client Certificate Keyring Import.

Additional Interactive Services

To round out the demo, we should add more services that users can experiment with. Right now, we have Jabber (JWChat and ejabberd) and file hosting (ownCloud). Those are good, but more would be good.









Live Help

Where To Start







To Do









FreedomBox for Communities

FreedomBox Developer Manual

HELP & DISCUSSIONS: Discussion Forum - Mailing List - #freedombox | CONTACT Foundation | JOIN Project

Next call: Saturday, February 11 at 14:00 UTC

This page is copyright its contributors and is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.