Layer 4 (L4) - Applications and Middleware

Objective

Use validated cryptography correctly in business logic and middleware while keeping cryptographic decisions centralized and auditable.

Responsibilities

• Call the platform provider through stable interfaces
• Enforce mTLS, certificate validation, and token verification using approved algorithms
• Avoid non approved algorithms and insecure modes

Common components

• Frameworks, service meshes, message brokers, caches
• Identity and access middleware that verifies tokens or assertions
• Application code that encrypts, signs, hashes, and derives keys

Implementation guidance

• Centralize crypto access through a thin wrapper that binds to the validated provider
• Use secure defaults from the Security Policy. Disable insecure cipher suites and curves
• Log cryptographic operations at a summary level for evidence without leaking sensitive data

Validation and evidence

• Code references that show provider bindings and approved algorithms
• Configuration for TLS, token validation, and message integrity
• Unit and integration tests that verify algorithm choices and error handling

Common pitfalls

• Pulling in a convenience library that bundles an unvalidated crypto implementation
• Accepting any certificate chain without policy checks
• Re enabling deprecated cipher suites for compatibility

Relationship to other AFIPS Layers

AFIPS Layer 4 Call Map

From	To	Why this edge exists	Typical operations	Evidence
L4	L2	Apps must not embed their own crypto	AEAD, HMAC, ECDSA verify, HKDF.	Provider load logs and approved mode flag
L4	L7	Fetch verification keys or service certs	JWT or token verification, mTLS client certs.	Key ID match in logs