docs(spec): add key rotation security audit draft for Issue #3

[AmeyParle]

Summary

Adds a structured security audit draft for did:trail key rotation semantics.

Covers

• compromised active-key rotation
• stale DID Document replay / downgrade risk
• revocation propagation timing
• recovery path design
• federation consistency during rotation
• resolver freshness / cache considerations
• registry compromise considerations
• retired vs revoked key handling

Why

Issue #3 asks for a security review of key rotation, revocation timing, recovery scenarios, MITM during DID resolution, registry compromise, and replay attacks with stale DID Documents.

Related to #3

[chrishooooo-netizen]

Approving — thank you for the structured audit, this is exactly the level of rigor the spec needed. The P0/P1/P2 split is clean and implementable, and the suggested spec patch in §8 is a good starting point for v1.3 work.

Particularly valuable:

• The compromised-key vs routine-rotation distinction (§4)
• Explicit pending/active/retired/revoked lifecycle states (P0)
• Registry-signed checkpoint idea (P1) for federation consistency
• The freshness/version downgrade prevention (P1)

I will track the P0 items as candidates for v1.3 and the P1 federation/freshness items for the broader v1.3/v2.0 roadmap. The open questions in §7 are good agenda items for future community discussion.