Brittleness of the expiry check.

[mikewest]

Should we try to leave flexibility in the spec for user agents to accept recently-expired signatures, similar conceptually to what some browsers' heuristics around TLS errors? I'm not sure it makes sense in this circumstance, but it's worth talking about.

[martinthomson]

Why even have an expiration utility? The content that includes a signature is updated frequently. If a key needs to go away, then it can be removed from content that refers to it pretty easily. Signatures, though, don't need those fields for this use case.

My experience with expiration is that it is a great way to end up breaking stuff more than it provides security value. Clocks are just awful and the less you depend on them, the better.

There are places where you might want time-based constraints, but I can't see why this would be one of those places.

[mikewest]

1. I agree that we should not require expiration (and the current draft doesn't).

2. We included support for expires as a potential defense against rollback attacks. You're correct that developers can create similar defenses by rotating their keys frequently, but that brings additional deployment and coordination challenges that seem reasonably well avoided by using the mechanism RFC9421 already defines.

I was planning on closing this out, BTW. If we have expiration, I don't think we need to be anything other than strict about its application.

[ddworken]

I'll just chime in to say that as someone interested in deploying this, expiry support does seem useful. Key rotation is likely to be pretty hard, but making sure we publish a new signature every N days is likely to be doable and offer a pretty good defense against rollback attacks.

And I agree with Mike: I don't see any reason to do anything other than be strict in how we enforce expiry.