What a certificate authority does
A certificate authority (CA) signs certificates that bind a name to a public key. The verifier does not check each key on its own. It checks a chain: the certificate in front of it was signed by an intermediate CA, which was signed by another, back to a key the verifier already trusts.
RFC 5280, the profile for X.509 certificates on the internet, states the goal of path validation as verifying the binding between a subject name and a subject public key, based on the public key of the trust anchor. RFC 6024 defines a trust anchor as an authoritative entity represented by a public key and associated data, where the key verifies digital signatures and the data limits what the anchor is trusted for.
The important detail for offline use is where the anchor comes from. RFC 5280 says trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. A CA moves trust around; it does not create it.
Checking a chain with no network
Path validation is local computation: signatures, names, constraints and dates. A device can do it with no connection as long as three things are already in place.
- The trust anchor is installed. The root key must be on the device before it goes offline.
- The clock is right. RFC 5280’s algorithm validates a certificate with respect to the current date and time. A device with a wrong clock can accept an expired certificate or reject a valid one.
- Revocation data is recent. RFC 5280 notes that a certificate can become invalid before it expires, for example when a private key is compromised, and that revocation status is provided through certificate revocation lists (CRLs), the Online Certificate Status Protocol (OCSP) or another mechanism. OCSP needs a responder to reach. A cached CRL works offline but only knows about revocations up to when it was fetched, which is the core problem of revoking access when devices are offline.
Mobile driving licences are a working example. Google’s guide to in-person verification under ISO/IEC 18013-5 describes readers that verify credentials without an active internet connection at the time of presentation. The reader checks that the Document Signer certificate chains up to a trusted Issuing Authority CA root, held in a secure local trust store, and checks the validity dates against its own clock.
When a CA is worth having offline
A CA earns its place when issuers and verifiers do not know each other in advance: many issuers, many verifiers, and keys that change. RFC 4251, the SSH architecture, sets out the trade-off. With a CA, ideally only a single CA key needs to be securely stored on the client, which eases maintenance. On the other hand, each key must be certified by a central authority, and a lot of trust is placed on that central infrastructure.
If one organisation issues every key and controls every verifier, a full PKI may be more machinery than the problem needs.
Alternatives without a CA
| Approach | What the verifier stores | Main weakness |
|---|---|---|
| Local key database | Each peer’s name and key | Grows burdensome to maintain |
| Pinning | A hash of the expected public key | Key changes need a backup pin or an app update |
| Trust on first use | The first key seen for each peer | The first contact can be intercepted |
| Self-certifying identifier | The peer’s identifier, which is derived from its key | Proves the key matches the name, not who holds it |
A local key database. SSH’s first trust model associates each host name with its public key on the client. RFC 4251 says this requires no centrally administered infrastructure and no third-party coordination, and that the database may become burdensome to maintain.
Pinning. Android’s network security configuration pins certificates by a hash of the public key, and a chain is valid only if it contains at least one pinned key. The same page advises always including a backup key, because otherwise switching keys means pushing an app update to restore connectivity.
Trust on first use. RFC 4251 describes accepting a host key without checking the first time, saving it in a local database and comparing against it on all future connections. It protects against passive listening but is vulnerable to an active man-in-the-middle at first contact.
Self-certifying identifiers. The identifier is computed from the public key, so anyone can check a presented key against it. The keys are compact: RFC 8032 gives Ed25519 public keys of 32 bytes and signatures of 64 bytes. In Offline Protocol’s mesh SDK, each device’s off1 address is derived from its Ed25519 identity key, and its security documentation notes that verification binds the presented key to that address but does not establish a person’s role or permission.
What you still need either way
Removing the CA removes a service, not the decision it made. Every approach above still answers the same question: why should this verifier accept this key? The answer comes from enrolment, such as a QR code scanned in person, a key installed at the factory or a signed binding to an account. Revocation and key rotation also remain your problem, and without a CA there is no central list to publish them on, so plan how replacement keys and removals will reach devices that are only occasionally online.