[Acme] [acme] RFC 9773 ARI: Gap in normative guidance on renewal window computation

[Brian Vicente <[e-mail]>]

Hi all,

I'm writing as an implementer of ACME-based certificate lifecycle
management in a multi-tenant PKI environment. I'd like to raise a
gap I've encountered in RFC 9773 (ACME Renewal Information) that
I think warrants either errata consideration or a companion
informational document.

RFC 9773 §4.1 specifies the on-the-wire format for an ACME server
to advertise a suggestedWindow (notBefore / notAfter) to a client.
The mechanism itself is well-defined. However, the RFC is explicitly
silent on how a server SHOULD compute that window. This leaves
implementers with no normative guidance on two operationally
significant factors:

1. Per-CA-mount throughput constraints.

   In a multi-tenant or high-volume PKI, multiple certificate
   populations may have overlapping ARI renewal windows. If all
   clients respond to simultaneously emitted windows, the issuing
   CA mount may receive a burst of signing requests that exceeds
   its processing capacity, causing issuance failures for relying
   systems during what is supposed to be a controlled renewal
   cycle. RFC 9773 does not address how a server should stagger
   emitted windows to respect per-CA throughput limits, nor does
   it recommend any backpressure or concurrency-awareness in
   window selection.

2. Dependency ordering between issuing CAs and the certificates
   they sign.

   In a CA topology with root → intermediate → end-entity
   relationships, an end-entity's ARI renewal window should not
   fire before its issuing intermediate CA has itself completed
   rotation. If an end-entity certificate is reissued under an
   intermediate CA that has not yet been rotated to the target
   algorithm, the resulting chain may be inconsistent with the
   deployment's migration goal. RFC 9773 provides no normative
   guidance on how a server should account for signing-chain
   dependency ordering when computing suggested windows.

Both of these gaps become particularly relevant in the context of
post-quantum algorithm migration, where large numbers of
certificates across a CA hierarchy must be rotated in a controlled
sequence and the cost of misordering is a broken or
cryptographically inconsistent trust chain.

I'm not proposing a specific computation method in this message.
I'd suggest the working group consider whether a companion
informational document or a section in a future revision could
provide:

  (a) SHOULD-level guidance that ARI window computation account
      for per-CA issuing capacity constraints, and

  (b) SHOULD-level guidance that window computation respect the
      topological ordering of the CA hierarchy from which the
      certificate descends.

Happy to discuss or contribute text if there is interest.

-Thank You


Brian Vicente
CEO  •  Sanctum SecOps LLC
Trust. Evidence. Identity.
✉  [e-mail]
🌐  sanctumsecops.com
📞 [phone]
📍 Pine City, New York, USA