# Andy Newton, ART AD, comments for draft-ietf-stir-certificates-shortlived-06
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-stir-certificates-shortlived-06.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks for this very well-written document.

## Discuss

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/,
a DISCUSS ballot is just a request to have a discussion on the following topics.

### SHOULD or MUST

Nothing major... just a simple question.

303        ...  Operators SHOULD renew
304        certificates in advance of expiry with enough lead time to absorb CA
305        latency and transient failures, recognizing that the shorter the
306        certificate lifetime, the tighter that renewal margin becomes.

Wouldn't failing to renew the certificates before they expire cause an interoperability issue?
If so, would it be reasonable that this is a MUST instead of a SHOULD?

Section 3 explicitly contemplates a design point where a single
short-lived certificate carries authority over a very large TN
Authorization List but is deliberately kept valid for only hours:

160 > spectrum, a large enterprise service provider could acquire a
161 > certificate valid for millions of numbers, but expire the certificate
162 > after a very short duration - on the order of hours - to reduce the
163 > risk that the certificate would be compromised.

The document's stated rationale for treating a short lifetime as an
adequate substitute for revocation is:

131 > Short-lived certificates offer an alternative
132 > where, if compromised, certificates will shortly expire anyway, so
133 > CRLs and OCSP are less meaningful.  Such certificates cannot be
134 > cached for a long term by relying parties, minimizing their value to
135 > attackers.

That reasoning holds well for a certificate scoped to one or a handful of
numbers, where the blast radius of compromise is small regardless of
lifetime. It doesn't obviously hold for the millions-of-numbers case the
same section offers as a legitimate deployment option: if the private key
of such a certificate is compromised near the start of an hours-long
validity window, the attacker can sign for the entire TN Authorization
List until its expiry, and by the document's own logic there is no
CRL or OCSP recourse in the interim. Section 9 doesn't analyze this
trade-off; it only points elsewhere:

346 > For further information on certificate security and practices, see
347 > [RFC5280], in particular its Security Considerations.
348 > Implementations should note the Security Considerations of [RFC8226]
349 > for guidance on STIR certificate usage.  The Security Considerations
350 > of [RFC8555] are relevant to the use of ACME to acquire short-lived
351 > certificates, as are those of [RFC8739].

None of those referenced Security Considerations sections analyze the
specific interaction this document introduces. RFC 8226's Security
Considerations flag TNAuthList disclosure as a privacy risk and suggest
short-lived, narrowly-scoped certificates as one mitigation, but don't
address the compromise-window question for the broad-scope case Section 3
describes. I'd like Section 9 to say something about the scope/lifetime
trade-off directly — at minimum, a recommendation that certificate
lifetime scale inversely with the breadth of the TN Authorization List it
carries, since the document itself is what introduces that combination as
an option.