Certificates and renewal
Two X.509 certificates, one rule about which leaf is newest, and one answer for a caller holding an old key.
The profile is exact
Both certificates are X.509 v3. Keys are Ed25519 or ECDSA P-256; signatures are the issuer key’s own algorithm, and an ECDSA signature on a certificate is the low-S twin, so one leaf has one byte string. A key identifier is the SHA-256 of the SubjectPublicKeyInfo, so the leaf’s issuer key identifier is the root’s fingerprint. The root is self-signed, cA true, keyCertSign only, with RFC 5280’s “no well-defined expiration”. The leaf is cA false, digitalSignature, with exactly one subjectAltName URI — the endpoint, an https URL in normal form — and a validity of at most 398 days. A certificate that carries an extension not listed, a duplicated one, a non-minimal length or a byte after its end is not a PACT certificate: an exact profile closes the whole class of things one parser sees and another does not (§ 14.1).
Six rules, in order
A verifier handed a chain refuses at the first failure: the chain is exactly two certificates, each matching the profile; the second is a root whose fingerprint, computed from its key, equals the one the verifier holds; the first is a leaf signed by that root, naming it as issuer; the clock is within the leaf’s dates and the leaf is no longer than 398 days; the leaf’s one URI equals the address in question byte for byte, and passes the address guard; and then the leaf’s key is the proven key. A root’s own validity is deliberately not checked — what identifies the person is the fingerprint of the key, not a date the same key wrote — which is a stated departure from RFC 5280 path validation (§ 14.2). The 398 days are the receiver’s rule, not the issuer’s setting: a longer certificate is not a longer-lived identity but one every conforming contact refuses.
The newest leaf wins
For each pinned identity a verifier keeps the endpoint and the latest leaf it accepted. A leaf whose notBefore is earlier than the pinned leaf’s is superseded: a caller presenting it resolves to no pin and gets the guest tier, and nothing is sealed to it. A leaf with a later notBefore at the pinned endpoint replaces the pinned one as it passes; at another endpoint it is a new address (§ 5.3). The rule is absolute, with no dampener and no grace, because any delay would be time a compromised leaf keeps speaking; only the root can produce a leaf with a later notBefore, so no host can outrank the person. A newer leaf arrives on use and needs no poll: a host carries its chain in its first envelope to each contact after a renewal, and a contact that talks to an identity learns its current leaf by talking to it (§ 14.3).
A caller holding an old key
An endpoint keeps the key identifiers of every leaf it has held for an identity it still serves. An envelope whose kid names one of them and no key it still holds is answered, in plaintext, with certificate_renewed and the identity’s current chain; the caller validates it against the root it holds and the address it dialed, updates its pin, and re-seals — at most once per call, and only when the chain is newer than or equal to its pin. A kid the endpoint never held is envelope_invalid with nothing attached, which is also what an identity that has left gets at its old address (§ 14.4).
Renewal, in practice
A leaf is renewed by the wallet issuing a new one for the same endpoint with a fresh key before the old expires; a host should ask thirty days ahead, at a moment the person is already present. A host keeps a superseded leaf’s private key until that leaf’s notAfter, so an envelope sealed to it by a contact that has not yet heard still opens, and destroys it then. An expired leaf is refused everywhere, not demoted to guest, until the wallet renews it (§ 2, § 9).