Draft spec to establish a Courier PKI

[gnarea]

Executive summary

Courier apps have to use self-issued, server-side certificates because they aren't Internet hosts and are therefore ineligible to get TLS certificates issued by a widely-trusted CA. This forces private gateways to trust any TLS certificate. Here we consider a "Relaynet Courier Certification Programme" to solve this issue.

(Note that Relaynet still guarantees properties like authentication, integrity and confidentiality -- TLS is only used to achieve confidentiality from other devices on the WiFi network)

Description

The lack of courier authentication poses some (minor) threats:

• An unauthorised user might try to pass off as courier to track the addresses of the private gateway and its corresponding public gateway. See Prevent a compromised courier from tracking cargo to/from private gateways #54. The impact would be low, though: Even if the unauthorised user got hold of those addresses, the address of the private gateway is just a digest of its public key and the address of the public gateway will typically be widely used anyway.
• An attacker might try to damage the reputation of Relaynet amongst end users by passing off as couriers but never actually relay any cargo.

Potential solution

We could establish a "Relaynet Courier PKI" by creating a registry of root CAs that are allowed to certify individual and/or organisational couriers -- The latter would be essentially intermediate CAs. This registry would be analogous to the Mozilla CA Certificate Program's list.

In addition to the registry, we should define the policy around it, including the criteria to add or remove CAs from the registry. The policy should also require end certificates to be valid for at most a week, which means couriers would have to renew them frequently -- So we'd need to build a back office system to support this.

Once this is in place, private gateways will be able to tell end users when they connect to a certified courier. Over time, we could make it more prominent to the user when they connect to a non-certified courier.

The registry should be (eventually) managed by a non-profit consortium.