Proposed architecture | Ganesh Mallaya

Two contracts

The north contract is the Common Crypto API. It carries an operation, intent, typed input and minimum constraints from an authenticated application to the broker.

The south contract is the provider interface. It carries the resolved operation, opaque key or certificate reference and exact algorithm profile from the broker to one provider adapter.

Neither contract replaces a cryptographic standard. The broker can dispatch through OpenSSL, JCA, PKCS #11, KMIP or a cloud KMS adapter.

Five responsibility planes

1 · Consumer
Application, gateway, service mesh, build system or PKI service.

2 · Interface
HTTP binding, local library, sidecar or compatibility adapter.

3 · Broker
Authentication, authorization, policy pinning, capability checks, routing and evidence.

4 · Provider
Software library, HSM, KMS, key store or platform module.

5 · Policy authority
Versioned rules, effective time, scope, transition choices and approval.

Network traffic flow

ApplicationBrokerPolicyProvider

1POST /v2/certificates:select →Authenticated TLS request

2Policy version and rule lookup →Local file in the reference service, protected control channel in a production design

3← One decision or rejectionExact profile, version, rule and effective time

4Resolved operation →Opaque reference and exact profile

5← Result or provider failureNo substitution by the adapter

6← Response and evidenceStable result or error category

Where policy enters the broker

The reference service accepts CALI_POLICY_FILE at startup. It parses the JSON document before opening the HTTP listener. Invalid status, a future effective time, an expired policy or malformed fields stop the process.

Each request includes expectedPolicy. The broker compares the caller’s expected profile and version with the active document. It finds the single rule for the operation and hostname then intersects the approved choices with current provider capability.

This makes policy observable. A reviewer can identify the file, version, rule, selected profile and evidence identifier used for each decision.

Failure paths

Request valid?No → `INVALID_REQUEST`

Policy active and pinned?No → `POLICY_NOT_FOUND` or `POLICY_INACTIVE`

Exactly one rule?No → `POLICY_AMBIGUOUS`

Approved capability available?No → `CAPABILITY_MISMATCH`

Provider executes exact profile?No → provider failure

SuccessReturn result and evidence

The broker records non secret failure evidence. It does not modify the active Apache certificate fragment when selection fails.

Current and proposed boundaries

The current implementation uses a local policy file and a local Apache deployment helper. The proposed architecture allows a separate policy authority and remote providers. That future topology must authenticate policy distribution, protect rollback, preserve policy pinning and keep the same failure categories.