[EPIC](crypto) Crypto Core & Edge Services Using KMIP 1.4

[nnicora]

Implement the OpenKCM Crypto Service using the KMIP 1.4 protocol to expose cryptographic operations (Creation, Retrieval, Wrapping, Unwrapping) to external systems. To ensure scalability and security isolation, the service must support two distinct operational modes: Core Crypto (L2/L3 management) and Edge Crypto (L4/DEK management).

The service will use mTLS (Mutual TLS) for authentication and a certificate-based authorization model to strictly enforce the boundary between tenant-level and data-level encryption.

---

💼 Business Context & Value

• Standards Compliance: Supports Client-Side Encryption (CSE) via the industry-standard KMIP 1.4 protocol.
• Security Isolation: - Core: Focuses on high-value tenant/application-level keys (L2/L3).
  • Edge: Focuses on high-volume Data Encryption Keys (L4/DEK).
• Scalability: Edge nodes can be deployed close to application workloads to minimize latency for DEK operations.
• Interoperability: Ensures OpenKCM is compatible with vendor-agnostic KMIP clients and tools.

---

🏗 Operational Modes

1. Core Crypto Mode (Upstream)

• Responsibility: Manages L2 and L3 key lifecycles.
• Allowed Operations: - Encrypt/Decrypt using identified L3 keys.
• Prohibitions: - MUST NOT allow creation, retrieval, or storage of L4 (DEK) keys.
  • MUST NOT accept KMIP operations targeting L4 objects.
• Protocol: Exposes KMIP over TCP and HTTP (mTLS enforced).

2. Edge Crypto Mode (Downstream)

• Responsibility: Manages L4 (DEK) lifecycles only.
• Capabilities: Supports Create, Get, Encrypt, and Decrypt for L4 keys.
• Keystore: Uses local keystore plugins for L4 persistence.
• Delegation: Acts as a "thin client" to Core Crypto. Encrypt/Decrypt operations using L3 keys are delegated upstream via KMIP over HTTPS.

---

🛠 Functional Requirements

1. KMIP 1.4 Protocol Implementation

Support the following KMIP operations over TCP:

• Create, Get, GetAttributes
• Encrypt, Decrypt
• Locate, Destroy

2. Upstream Delegation (Edge-to-Core)

• Edge nodes must communicate with Core nodes via KMIP over HTTPS.
• Header Propagation: Edge must propagate the original client certificate identity (received over TCP) to Core over the HTTP headers to maintain audit and authorization chains.
• Failures from Core must propagate transparently back to the Edge client.

3. mTLS Authentication & Authorization

• Authentication: Strict x509 Mutual TLS validation against a trusted CA.
• Identity Mapping: Certificate fields must map to tenant/service identities.
• Authorization: Access control must be derived exclusively from the client certificate identity to determine allowed KMIP operations.

---

🛡 Non-Functional Requirements

• Security: Strict separation of L3/L4 duties to prevent Edge nodes from accessing or creating L2/L3 materials directly.
• Interoperability: Protocol implementation must be validated against standard KMIP 1.4 compliance suites.
• Auditability: Every KMIP operation (whether local or delegated) must generate a signed audit log containing the certificate identity.

---

✅ Acceptance Criteria

• Core Crypto successfully rejects L4 creation/retrieval requests.
• Edge Crypto successfully delegates L3 Encrypt/Decrypt operations to Core via HTTPS.
• mTLS authentication is enforced; connections without valid certificates are dropped.
• The system correctly propagates identity headers from Edge to Core for authorized operations.
• Verified support for all required KMIP 1.4 operations (Create, Get, Encrypt, etc.).