--- title: "Certificates & Trust" description: "Understanding the XI Objects certificate hierarchy, trust chains, and identity management." published: 2026-02-18T18:06:39.929509+00:00 updated: 2026-02-18T18:06:39.929509+00:00 tags: ["certificates", "security", "trust"] url: https://xiobjects.com/docs/xio/concepts/certificates source: XI Objects --- # Certificates & Trust XI Objects uses a hierarchical certificate system to establish and verify identity. Every piece of signed content is traceable back to a verified creator through a chain of trust anchored by the **Institute of Provenance Root CA**. ## Certificate Hierarchy ```mermaid graph TB subgraph Root R[Institute of Provenance Root CA] end subgraph Intermediates I1[XI Objects Inc Control Intermediate] I2[Certified Orbital Intermediate] I3[Certified Orbital Intermediate] end subgraph Leaves C1["service-a (leaf)"] C2["service-b (leaf)"] C3["creator (leaf)"] C4["ci-pipeline (leaf)"] end R --> I1 R --> I2 R --> I3 I1 --> C1 I1 --> C2 I2 --> C3 I3 --> C4 style R fill:#582c7e,stroke:#7a4a9e,color:#fff style I1 fill:#1a1a2e,stroke:#7a4a9e,color:#e1d5b9 style I2 fill:#1a1a2e,stroke:#7a4a9e,color:#e1d5b9 style I3 fill:#1a1a2e,stroke:#7a4a9e,color:#e1d5b9 ``` ### Institute of Provenance Root CA The root certificate authority is the ultimate trust anchor for the ecosystem. It is: - A self-signed Ed25519 certificate with long-lived validity (currently 2025–2035) - Used exclusively to sign Intermediate CA certificates for certified Orbital operators - Managed with strict key ceremony procedures - Never exposed to online systems or network operations ### Control Intermediate Certificates Certified Orbital operators receive intermediate certificates signed by the Root CA. These intermediates allow the operator's **Xio.Control** module to issue leaf certificates: - Ed25519 certificates signed by the Root CA - Multi-year validity (currently 2025–2030) - Scoped to certificate issuance and record authority functions - Each certified Orbital operator holds its own intermediate ### Leaf Certificates Leaf certificates are **short-lived**, typically valid for hours to a single day. They are issued by the Control module running on a certified Orbital and used for content signing: - Ed25519 public keys with certificates signed by the intermediate CA - Short validity periods to limit exposure from key compromise - Include a custom Extended Key Usage OID for XI Objects signing - Issued on-demand through the Xio.Control PKI API ## Certificate Lifecycle ```mermaid stateDiagram-v2 [*] --> Requested Requested --> Active : Issued by Control Requested --> Rejected : Denied Active --> Expired : Validity period elapsed Active --> Revoked : Key compromise / policy Expired --> [*] Revoked --> [*] Rejected --> [*] ``` ### Issuance Leaf certificates are issued through the Control module. The Control module must be activated with valid root and intermediate certificate material before it can issue certificates. The Control module validates the request, generates the leaf certificate signed by its intermediate CA, and returns the certificate with the full chain. ### Revocation If a private key is compromised, certificates can be revoked immediately through the Control module. Revocation state is maintained in a **Sparse Merkle Tree**, enabling cryptographic proofs of both inclusion and exclusion. A verifier can prove that a certificate *has* been revoked, or prove that it has *not* been revoked, without trusting the server. ## Verification When verifying signed content, XI Objects checks the full certificate chain embedded in the trust block: 1. **Signature validity**: Is the Ed25519 signature mathematically valid against the content hash? 2. **Chain integrity**: Does the certificate chain trace from leaf → intermediate → Institute of Provenance Root CA? 3. **Revocation status**: Has any certificate in the chain been revoked? (verified via Sparse Merkle proofs) 4. **Temporal validity**: Was the leaf certificate valid at the time the content was signed? The trust block carries the complete X.509 certificate chain (PEM-encoded, leaf-first), so verification can be performed independently. ## Key Storage Private keys for Ed25519 signing should never be stored in plaintext. The signing architecture uses a **delegate pattern**: the private key is held externally and a `SignDataAsyncDelegate` is provided to the trust signer, allowing integration with various secure backends: | Backend | Security Level | Use Case | |---------|:---:|----------| | File system (encrypted) | Medium | Development and testing | | OS keychain | High | Desktop applications | | Azure Key Vault / HSM | Very High | Production deployments | | Hardware Security Module | Highest | Root CA and intermediate CA operations | ## Sparse Merkle Tree Proofs XI Objects uses Sparse Merkle Trees (SMTs) as the verifiable data structure backing certificate state. This enables: - **Inclusion proofs**: Cryptographic proof that a certificate or record exists in the current state - **Exclusion proofs**: Cryptographic proof that a certificate has *not* been revoked - **State roots**: A single hash (the SMT root) that commits to the entire certificate registry state - **Epoch advancement**: State roots are signed and advanced at regular intervals by the Control module