SPKI is a lightweight PKI framework that enables secure identity and key management, certificate issuance, and trust validation within an organization, with support for decentralized auditability.



SPKI and X509 PKI (Https) differences


OSI Level X509 (HTTPS) SPKI
7 - Application Provides identity verification (TLS client/server certs, email signing with S/MIME, code signing). Applications rely on CAs for trust. Provides identity & trust via Web-of-Trust (WoT), enabling signed credentials, certificates, and cross-verification. Focused on non-repudiation of cryptographic commitments anchored (e.g., Arweave).
6 – Presentation Supports secure data formats: certificates in ASN.1/DER/PEM. Ensures integrity and authenticity of exchanged keys. Uses SPKI formats (simpler, JSON-like, more human-readable) for certificates. Security logic focuses on binding keys to identities without ASN.1 complexity. By design, private keys are handled in a way that reduces exposure to memory disclosure attacks (e.g., through mutable types).
5 – Session Enables session security establishment (e.g., SSL/TLS handshake) by authenticating server (and optionally client). PKI ensures session peers are who they claim to be. Could support session initialization by verifying cryptographic commitments before session establishment. SPKI WoT allows distributed trust validation before sessions.
4 – Transport Indirectly secures transport protocols (e.g., TLS over TCP). PKI ensures the endpoints exchanging transport data are trusted. Same effect, but with decentralized trust anchoring. Instead of a global CA chain, trust is validated through mutual signatures and WoT relations.
3 – Network PKI doesn’t directly operate here but secures IPsec VPNs (via IKE certificates). Ensures network peers are authenticated. SPKI doesn't cover on VPN operations on network devices. However, implementing custom IPSec on software level for VPN is possible.
2 – Data Link Rare. PKI can be used in 802.1X (EAP-TLS) for Wi-Fi/Ethernet authentication. Similar to OSI Layer 3, SPKI does not natively handle data link authentication but could be implemented in custom firmware if needed.
1 – Physical PKI doesn’t reach here; assumes secure hardware/HSM for key storage particularly for existing public CAs while secure, though costly. SPKI includes software-emulated HSM (SHSM), giving it slight overlap with physical layer concerns (secure key handling & zero-trust enforcement).
Summary Primarily focuses on OSI Layers 3–7, with optional Layer 2 support via 802.1X. Primarily focuses on OSI Layers 4–7, with optional software-level support extending toward the physical layer via SHSM.


SPKI infrastructure mode differences


Potential Problems Private Mode Public Mode
MITM Attacks Enables mutual verification, ensuring trusted identities among internal participants. Susceptible to MITM attacks from ISPs or governments over the internet; difficult to fully prevent.
Phishing Attacks Internal and cross-domain communications (e.g., email, chat) can be strongly verified, reducing phishing risks. Authenticity can still be verified, but phishing prevention is weaker compared to private mode.
Chain of trust attacks Complete validation of the entire SPKI hierarchy, minimizing rogue or unauthorized access. Only end-user authenticity can be verified (via out-of-band methods), limiting full trust validation.
Summary / Best Use Case Ideal for internal organizational use where strong trust, mutual verification, and reduced attack surface are critical. Suitable for open, internet-facing deployments where decentralized verification is desired, but full MITM and phishing protection cannot be guaranteed.