Key Management

OCME Registry signs every DID document with platform-managed cryptographic keys. Keys are generated, stored, and used entirely server-side — private key material is never exposed through a public route.

Signing Keys

Generation

• RSA key pairs, 2048-bit by default, generated with WebCrypto
• Signature scheme: RSASSA-PKCS1-v1_5 with SHA-256
• Generated server-side in the Workers runtime; browser adapters exist for local tooling only

Publication

• DID documents publish the public key as a RsaVerificationKey2018 verification method with a PEM-encoded public key
• Documents are signed under the platform admin key with proof purpose assertionMethod
• Anyone can verify a document's signature using the published public key

Storage and Encryption

• Key storage — private keys live in a dedicated platform-managed KV namespace (KV-primary storage with a local cache layer). They are never returned by any public or partner API.
• Encryption — sensitive material is protected with AES-256-GCM symmetric encryption via WebCrypto.
• Content fingerprints — every media file is fingerprinted with SHA-256 (64-character hex). The fingerprint anchors content DIDs and enables duplicate detection (GET /service-binding/content/by-hash/{hash}).
• Deactivation — DID deactivation is an explicit signed command recorded against the document; deactivated documents stop resolving as active.

Keys and the Public Boundary

When a public (unauthenticated) DID resolution redacts payment or legal-identity material, the document's cryptographic proof is removed with it — the signature covers the pre-redaction payload and could never verify against the redacted view. The registry verifies the signature internally before redaction, so the verified result it reports is trustworthy. See Content Verification for the full redaction boundary.

Documentation

Reference

Content Verification