Deevnet Certificates Standard #

Purpose #

This standard defines what every Deevnet X.509 certificate looks like: who may issue it, what its subject and names say, which keys and lifetimes it uses, and where its key may live. The model it serves is in Trust and Identity, ADR-0031 and ADR-0037.

A certificate that does not meet this standard is a defect, whatever issued it.

1. Four tiers: Root CA, Site CA, issuing CA, end entity #

• 1.1 A Root CA MUST NOT sign an end-entity certificate, and a Site CA MUST NOT sign one.
• 1.2 The Substrate CA MUST issue only server certificates for the substrate. The Tenant Device CA MUST issue only client certificates for tenant devices. The Tenant Service CA MUST issue only server certificates for names in a tenant’s own zone.
• 1.3 Every client MUST trust the Root CA as its anchor. A client MUST NOT be configured to trust a Site CA or an issuing CA as an anchor in its place.

2. Every subject is exactly O, OU and CN #

Every subject MUST carry exactly O, OU and CN, encoded in that order, so that a certificate’s Issued To and Issued By each name the organization, the part of it, and the thing itself.

• 2.1 <Site> MUST be the site’s name in title case, as in the naming standard: Mobile, Home.
• 2.2 <tenant> and <device> MUST be the names the Deevnet API holds, exactly. <label> is one DNS label the tenant chose; the issuer, never the tenant, appends the zone.
• 2.3 Subjects MUST NOT carry C, ST, L or an email address.

3. A certificate is valid for the names and addresses its clients dial #

A client checks the name it dialled against the SANs, never the CN. The SANs are what a certificate is valid for.

• 3.1 A substrate server certificate MUST carry, as DNS SANs, the host’s A record and every CNAME of it, and, as IP SANs, every address it serves on. They MUST be derived from the inventory, the same data the site’s DNS is published from, never written by hand.
• 3.2 A server certificate MAY carry more where a client dials it so: localhost, 127.0.0.1, or a router’s gateway addresses on every segment.
• 3.3 A tenant device certificate MUST carry exactly one URI SAN: urn:deevnet:<site>:tenant:<tenant>:device:<device>, lower case. It is the identity a service authorizes. It MUST NOT carry a DNS or IP SAN.
• 3.4 A tenant service certificate MUST carry, as DNS SANs, its CN and any further names asked for, each of them one label inside the tenant’s own zone, <tenant>.<site>.deevnet.net. It MUST NOT carry a wildcard, an IP SAN, a URI SAN or a name outside that zone.

4. Each tier has a fixed key, lifetime and set of extensions #

• 4.1 RSA throughout the CA tiers keeps the chain verifiable by the oldest device TLS stacks on the site.
• 4.2 Signatures MUST use SHA-256 or stronger.
• 4.3 Every certificate below the root MUST carry authorityKeyIdentifier, and every CA subjectKeyIdentifier.
• 4.4 Serial numbers MUST be random, at least 64 bits.
• 4.5 A certificate MUST NOT carry both serverAuth and clientAuth. Server identity and device identity are different things, issued by different CAs. So are the substrate’s servers and tenants’ services.
• 4.6 Extensions MUST come from the issuer’s profile. An issuer MUST NOT copy extensions from a signing request. A tenant’s signing request is read for its public key alone: its subject and names are not used either.
• 4.7 An end-entity certificate MUST be reissued once fewer than 60 days remain.
• 4.8 A Site CA MUST carry nameConstraints permitting only DNS deevnet.net and localhost, and IP 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, fc00::/7 and ::1. It MUST NOT be marked critical: mbedTLS devices refuse to parse a certificate with a critical extension they do not implement, and name constraints are one.
• 4.9 Every name and address in a certificate below a Site CA, its CN included when the CN looks like a host name, MUST fall within those constraints.

5. Each key lives in exactly one allowed place #

• 5.1 The Root CA’s and every Site CA’s key MUST NOT be present on a networked machine, in any form.
• 5.2 An issuing CA’s key MUST be generated where it lives. Only its signing request travels to be signed.
• 5.3 A tenant device’s key MUST NOT enter the substrate. The device’s signing request does; the issued certificate goes back. This is Secure Identity 3.1 applied to devices. A tenant service’s key MUST NOT enter the substrate either: the tenant makes it, and sends a signing request.
• 5.4 The substrate’s certificates MUST NOT depend on the secret store. The Substrate CA is automation’s, so a substrate rebuilt from nothing can issue every certificate it needs before the secret store exists.

Only the transfer media crosses the offline boundary #

• 5.5 The media holding the Root CA’s and Site CAs’ keys (the key media) MUST be used only on the offline machine, and MUST NOT be the media that carries anything between the online and offline machines.
• 5.6 Only the transfer media crosses. It MUST carry only signing requests, certificates, the signing profile and the ceremony’s tools. It MUST NOT carry a private key.
• 5.7 What crosses MUST travel under a manifest of SHA-256 hashes, checked on arrival on each side. A request is signed only after its subject and signature are checked and the key holder confirms it. A returned certificate is installed only after it is checked against the original request’s key and chained to the Root CA through the online side’s own copies of the Root and Site CA certificates.
• 5.8 The ceremony’s tools (deevnet-pki-transfer.sh, deevnet-pki-sign.sh) enforce 5.5–5.7. Tooling MAY automate the mechanics and the checks, and MUST NOT automate the decision to sign.
• 5.9 The offline machine MUST have its radios disabled and no network service running, and MUST NOT carry an automation account or remote access. Its clock MUST be checked before any key or certificate is made. Its operating system SHOULD be the image factory’s ceremony image (pi-pki), checked against its published hash before use, so that the code that signs is pinned at build and never arrives on the transfer media.
• 5.10 Firmware that persists on the offline machine across boot media, such as a Raspberry Pi’s bootloader EEPROM, MUST be reset from known media at the start of every ceremony, and the reset confirmed before the ceremony’s system boots.

6. Files are named deevnet--.pem #

<site> is lower case: deevnet-mobile-site-ca.pem. A key file is named for its certificate with .key.

7. A certificate is correct only when all of these hold #

A Deevnet certificate is correct when:

• it chains to the Deevnet Root CA through its Site CA and exactly one issuing CA;
• its subject is exactly O, OU and CN, as in section 2;
• it is valid for every name and address its clients dial, and nothing it could not be dialled by;
• it is either a server certificate or a client certificate, never both;
• its key has never been anywhere this standard does not allow.