ADR-0011: Boundary Identity Uses Mutual TLS

Context

BSFG connects zones that are deliberately separated by trust, network, and operational boundaries. The boundary protocol therefore requires strong peer identity, encrypted transport, and an authorization basis that is independent of network location alone.

Because BSFG is a compliance-oriented boundary appliance, identity must be:

• cryptographically bound to the connection
• auditable
• suitable for zone-to-zone authorization
• independent of application payload contents

Options Considered

• simple client integration
• easy to start with

|

• identity is not bound to transport peer
• weaker operational posture for inter-zone trust
• secret distribution becomes central risk

| | Network trust only | Rely on firewalls, routing, and source networks without strong cryptographic peer identity. |

• minimal application complexity
• low certificate management burden

|

• weakest assurance model
• not suitable for explicit cross-zone identity
• difficult to audit safely

| | mTLS plus application JWT | Use mutual TLS for transport authentication and add JWT claims for higher-level service identity. |

• high flexibility
• supports richer delegated auth models

|

• more moving parts
• extra token issuance and validation complexity
• not needed for the current narrow boundary protocol

| | Mutual TLS with zone-issued certificates (Selected) | Use mTLS for all BSFG peer connections, with zone identity derived from certificate subject or SAN. |

• cryptographic peer identity
• transport encryption and authentication together
• clean fit for zone-based authorization
• strong auditability

|

• certificate issuance and rotation must be managed
• PKI operations become part of the platform lifecycle

|

Decision

BSFG will use mutual TLS for all boundary RPC connections.

Each BSFG peer presents a certificate whose identity maps to a zone. Zone authorization is derived from certificate identity rather than network location alone.

transport security = mTLS
peer identity      = certificate subject or SAN
authorization      = zone-aware policy

The envelope fields from_zone and to_zone are therefore declarative metadata, not unauthenticated claims. Implementations must validate that the authenticated peer is permitted to assert the declared origin.

Consequences

Benefits:

• strong cryptographic authentication between zones
• clear security boundary aligned with the architecture’s zone model
• good fit for compliance-by-design and auditable transport identity
• reduced dependence on shared secrets in application payloads

Tradeoffs:

• certificate lifecycle management becomes mandatory
• operational tooling must support issuance, renewal, and revocation
• misconfigured PKI can interrupt boundary traffic