Day 7: Challenge — SPIFFE Spec Deep-Read + PKI Comparison

Phase 4 · August 11, 2026

Agenda (2–3 hours)

• Deep-read (60 min): Re-read the SPIFFE spec documents with fresh eyes
• Synthesize (60 min): Complete spiffe-analysis.md with a full PKI comparison
• Reflect (30 min): What does SPIFFE add? What does it not solve?

Week 1 Concepts Inventory

Rate each: ✓ solid / ~ partial / ✗ need review

• [ ] The workload identity bootstrapping problem
• [ ] SPIFFE ID structure and constraints (scheme, trust domain, path)
• [ ] X.509-SVID requirements (SAN, EKU, validity, CA flag)
• [ ] Trust domain and trust bundle semantics
• [ ] Workload API — what a workload receives, how the socket works
• [ ] JWT-SVID structure and validation (sub, aud, exp, alg)
• [ ] Federation — when needed, bundle exchange mechanism

The Big Picture: What SPIFFE Adds to Classical PKI

SPIFFE doesn't replace PKI. It uses PKI (X.509) with tighter operational constraints
and automated lifecycle management.

Completing spiffe-analysis.md

Your analysis document should now have four sections:

Section 1: Credential Inventory (Day 1 challenge)

• Every credential your provisioning service uses
• Risk rating for each
• How SPIFFE would change each

Section 2: SPIFFE ID Design (Day 2 challenge)

• SPIFFE IDs for each service component
• Trust domain choices
• mTLS peer relationships

Section 3: Federation Design (Day 6 challenge)

• Peer types (internal, partner, embedded hardware)
• Federation topology
• Limits of SPIFFE for satellite terminals

Section 4: SPIFFE vs. Classical PKI (today)

• The comparison table from this slide, filled in for your service
• One paragraph: "In my provisioning service, SPIFFE would help most with ___
  and would not help with ___ because ___."

Hard Questions to Sit With

1. Lambda and the Workload API: SPIRE agents run as persistent daemons.
   Lambda functions are ephemeral. How does a Lambda get a SVID?
   (You'll answer this in Week 3, Day 15 — but think about it now.)

2. HSM-stored CA keys: SPIRE's internal CA generates short-lived SVIDs.
   If that CA key isn't in an HSM, does SPIRE weaken your security posture vs.
   ACM PCA with CloudHSM?

3. SPIFFE vs. IAM: For AWS-internal service-to-service calls, IAM roles are
   already attestation-based and automatic. When does adding SPIFFE provide
   value over IAM? When is it redundant?

4. PQC intersection: SPIRE's internal CA will eventually need to sign SVIDs
   with ML-DSA. What's the migration story — can SPIRE's CA key be swapped
   without re-issuing all trust bundles?

Write brief answers (2–3 sentences each) in spiffe-analysis.md.

Challenge Assignment

Complete all four sections of spiffe-analysis.md.

Then write one more section:

Section 5: Recommendation (one page max)

• Should your team adopt SPIFFE/SPIRE for the provisioning service? Yes, no, partial?
• What would be the first concrete step if yes?
• What is the main blocker or risk?

Quality bar: good enough to send to a tech lead as a pre-read before
a design discussion. Not a final recommendation — a structured framing
of the tradeoffs.

Looking Ahead: Week 2

Week 2 makes SPIFFE concrete by deploying SPIRE locally.
You'll see the server, the agent, and a workload receiving real SVIDs.

The gap you need to bridge: until now everything has been abstract.
After Week 2 you'll know exactly what configs, binaries, and API calls
are involved in a real SPIRE deployment.

Resources

• SPIFFE spec index: github.com/spiffe/spiffe/tree/main/standards
• SPIRE architecture: spiffe.io/docs/latest/architecture
• "Solving the Bottom Turtle" (free SPIFFE/SPIRE book): spiffe.io/book