CALI: Cryptographic Abstraction Layer Interface

What is CALI?

CALI is independently developed, vendor-neutral research into a policy-directed Common Crypto API. An application asks for a defined operation such as signing, verification or certificate selection. It supplies typed input and minimum constraints. It does not select an HSM slot, a cloud key identifier or the next acceptable algorithm.

The Common Crypto API is the interface consumed by the application. CALI defines the wider model: the request contract, policy decision, broker enforcement, provider boundary, evidence and explicit failures.

Purpose

Cryptographic choices are often embedded in application code. One call can select the operation, algorithm, parameters, library, provider, key location and encoding. A policy change then becomes an application release. A provider migration becomes a code migration.

CALI tests whether these choices can move behind a stable interface without hiding incompatibility. The goal is not to swap any algorithm anywhere. The goal is to define when substitution preserves the required semantics and to fail clearly when it does not.

The research concentrates on four outcomes:

• applications depend on stable operation semantics
• policy owns the approved cryptographic choice
• the broker enforces one pinned decision
• providers keep their existing standards and custody boundaries

Two generations, kept separate

The website preserves two related but different artifacts. The initial Research Framework v1 states the original question, precedent, proposed contracts and falsifiable interoperability goal. The current executable research alpha tests a bounded version of that model with code, schemas, policy, examples, evidence and candidate conformance vectors. Implementation results do not retroactively turn the framework into an adopted standard.

Background and research position

CALI builds on established work rather than claiming to invent cryptographic abstraction.

• NIST CSWP 39 describes practices for cryptographic agility and migration planning.
• PKCS #11 defines a provider interface for cryptographic tokens.
• KMIP defines managed key objects and operations.

CALI focuses on the seam that applications need to test independently: a consumer contract, a policy decision boundary, broker enforcement, provider capability matching, portable failures and decision evidence. It sits above PKCS #11, KMIP, KMS interfaces and cryptographic libraries. It does not replace them. The framework page gives the fuller prior-art positioning and makes the novelty boundary explicit.

Proposed architecture

The architecture has two contracts and five responsibility planes. The policy authority owns the approved decision. The broker owns enforcement. The provider performs the primitive.

The current reference service reads a versioned policy file at startup. A production deployment could obtain signed policy through a separate control channel. In both cases the operation path receives one pinned policy version. It does not receive a preference that the broker can reinterpret.

Explore the architecture and traffic flow

Policy decides. The broker enforces.

Policy and broker are separate because they answer different questions.

The broker fails when policy is missing, inactive or ambiguous. It also fails when the required capability is unavailable, the key state is wrong or the provider cannot execute the exact decision. Failure never grants permission to select another algorithm.

See policy files, broker code and failure examples

Current implementation

The current implementation section contains the API specification, operation catalog, algorithm profiles, service runbook, Apache migration case study, alpha conformance evidence, roadmap, NIST alignment and security model.

Research status and claim boundary

CALI is independently developed research by Ganesh Mallaya. The checked-in implementation and test environment provide evidence for a bounded executable slice; they do not establish cross-implementation interoperability, production readiness, independent certification, standards status or product security assurance.