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

[Sebastian Robin Nielsen <[e-mail]>]

Since its the CA that runs the ACME server, its up to the CA to ensure it doesn't issue ARI renewal information that in itself could cause an overload. It doesn't need to be specified in the standard.
-------- Originalmeddelande --------Från: Brian Vicente <[e-mail]> Datum: 2026-06-07  22:37  (GMT+01:00) Till: [e-mail] Ämne: [Acme] [acme] RFC 9773 ARI: Gap in normative guidance on renewal window computation 
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