Request Notarization

Overview

Request notarization enables cryptographic proof of HTTP request/response pairs, linking them to specific workload identities. This provides tamper-proof audit trails, non-repudiation, and offline verification capabilities critical for compliance and AI/ML provenance tracking.

Key capabilities:

• Workload attestation - Prove which workload handled a request
• Request signing - Cryptographically sign request/response pairs
• Offline verification - Verify signed receipts without network access
• Audit logging - Immutable append-only log for compliance
• AI/ML provenance - Track model inference and training lineage

Target audience: Security engineers, compliance officers, ML engineers, auditors

Notarization Purpose

In the abstract, the notary converts short-lived, online-verifiable identities (SPIFFE X.509-SVIDs) to long-lived, offline-verifiable identities (signed JWT receipts) with logging and auditability.

Problem: SPIFFE certificates expire in 1 hour. How do you prove a request occurred months later?

Solution: Central Proxy signs a receipt containing:

• Request and response data
• Workload identity information
• Timestamp
• Signature from long-lived X.509-SVID

The receipt can be verified offline indefinitely, even after the original SVID expires.

Notarization Levels

QHx supports three levels of notarization with different performance/security trade-offs:

Level 1: Workload Identity Only

Description: Log workload identity statement, do not sign request/response.

Use case: Prove which workload handled a request without performance overhead.

HTTP Headers:

Request:
  Qhx-Notarization-Level: workload

Response:
  Qhx-Workload-ID: 6c1b4eee642972f867865849245203f9c8ed09c27c953d41d641b7a0cc9db57d

What’s logged:

• Workload SPIFFE ID
• Pod metadata (namespace, name, UID)
• Container images (with SHA256 digests)
• MLS labels
• Timestamp

What’s NOT logged:

• Request method, path, headers, body
• Response status, headers, body

Performance: < 1ms overhead

Example:

# Using qhx curl
qhx curl -n workload http://api-server:8080/health

# Using HTTP header (application code)
curl -H "Qhx-Notarization-Level: workload" http://localhost:8081/api

---

Level 2: Log Request

Description: Log workload identity AND request/response, but do not sign.

Use case: Audit trail without cryptographic signing overhead (trust QHx infrastructure).

HTTP Headers:

Request:
  Qhx-Notarization-Level: logRequest

Response:
  Qhx-Workload-ID: 6c1b4eee642972f867865849245203f9c8ed09c27c953d41d641b7a0cc9db57d
  Qhx-Request-ID: 29758415ea2234cec8a34a4469342df51eebbdc7316699f7c6892913316f9841

What’s logged:

• Everything from Level 1
• Request method, path, headers, body
• Response status code, headers, body

What’s NOT signed:

• Request/response data (logged but not cryptographically signed)

Performance: ~2ms overhead

Example:

qhx curl -n logRequest \
  -X POST -d '{"query":"hello"}' \
  http://api-server:8080/api/chat

---

Level 3: Sign Request

Description: Log AND cryptographically sign workload identity and request/response.

Use case: Offline verification, compliance, non-repudiation, air-gapped environments.

HTTP Headers:

Request:
  Qhx-Notarization-Level: signRequest

Response:
  Qhx-Workload-ID: 6c1b4eee642972f867865849245203f9c8ed09c27c953d41d641b7a0cc9db57d
  Qhx-Request-ID: 29758415ea2234cec8a34a4469342df51eebbdc7316699f7c6892913316f9841

What’s signed:

• Everything from Level 2
• JWT signature from Central Proxy’s X.509-SVID
• Signature can be verified offline

Performance: ~5-10ms overhead (includes JWS signing)

Example:

qhx curl -n signRequest --print-receipt \
  -X POST -d '{"model":"llama3.2:1b","messages":[...]}' \
  http://ollama-server:8080/v1/chat/completions

---

Use Cases

AI/ML Inference Audit Trail

Requirement: Prove which model generated a response, with tamper-proof evidence.

Solution:

# Make inference request with signed receipt
qhx curl -n signRequest --print-receipt \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.2:1b",
    "messages": [
      {"role": "system", "content": "You are a medical assistant."},
      {"role": "user", "content": "What is the recommended dosage of aspirin?"}
    ]
  }' \
  http://ollama-server:8080/v1/chat/completions \
  > medical-inference-receipt.json

Compliance evidence:

• Who: spiffe://qhx.dev/ns/medical/sa/llm-service/...
• What: Model image ollama/ollama@sha256:abc123...
• When: 2026-02-02T10:48:07Z
• Where: Namespace medical, pod ollama-server-786f9f59d-5djst
• Why: MLS level us:ts, compartment us:medical

---

Configuration

Enable Notarization in Central Proxy

central-proxy-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: central-proxy-config
  namespace: qhx-central
data:
  config.yaml: |
    mode: central

    # Notary configuration
    notary:
      enabled: true
      defaultLevel: workload
      logPath: /var/log/qhx/notary

      # Storage configuration
      storage:
        type: persistent
        retentionDays: 365
        maxSizeMB: 10240  # 10GB

---

Related Documentation

• Proxy Architecture - Central Proxy and notary architecture
• QHx CLI Reference - Using qhx curl command
• Telemetry and Monitoring - Notary metrics

Summary

Request notarization provides:

• Tamper-proof audit trails
• Offline verification (air-gapped environments)
• AI/ML provenance tracking
• Compliance evidence (NIST 800-53 AU-* controls)
• Non-repudiation for critical requests

Choose the right level for your needs:

• Workload: Lightweight identity verification
• Log Request: Audit trail with minimal overhead
• Sign Request: Maximum assurance with offline verification