Thanks for starting the discussion, Rob! One aspect of RFC 8555 that is quite clunky in practice is utilizing the notBefore/notAfter dates in the new-order request [1 <https://datatracker.ietf.org/doc/html/rfc8555#section-7.4>].
I believe there are a few problems with it. 1. "new-order" may be well before issuance - Most clients/servers use the new-order workflow, meaning that they request a new-order before attempting authorizations. If the client is slow to finish their authorizations, it is possible the server may not be willing to finalize the order with the agreed-upon timestamps by the time the client gets around to issuance. In particular, the notBefore timestamp may be too far in the past by finalization. Additionally, the server is forced to check the validity period multiple times. Google Trust Services recommends not setting the notBefore at all and allowing the server to set it upon issuance. 2. Precise timestamps - RFC 5280 notBefore/notAfter timestamps are difficult to get exactly right given that the notAfter timestamp is inclusive [2 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5>] and that there may be client/server differences in the interpretation of leap seconds [3 <https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods>]. Google Trust Services allows users to issue certificates with slightly higher bounds than the recommended to avoid problems with the client logic like notAfter = notBefore + X days from failing when the server attempts to validate the order. If the client uses the trick from #1 and doesn't specify the notBefore, the server may additionally default to backdating by a small amount to deal with clock skew and push the full order's validity period over the policy restrictions and ultimately reject the request. All of this has to be accounted for when calculating the hard policy on the ACME server. This is truly problematic for certificates with special requirements on the validity period or where the server may change functionality based upon the duration of the certificate. For instance, short-lived certificates as defined in the Baseline Requirements [4 <https://github.com/cabforum/servercert/blob/main/docs/BR.md#161-definitions>, 5 <https://github.com/cabforum/servercert/blob/main/docs/BR.md#4911-reasons-for-revoking-a-subscriber-certificate> ]. 3. Clock skew - I know several CAs will backdate their notBefore to avoid unnecessary issues with clock skew. I haven't analyzed the problem recently, but pushing this complexity onto the client seems unnecessary. ACME server implementations may be tempted to treat the notBefore and notAfter timestamps as a duration and modify them at issuance, but this is against the current specification. "The server MUST return an error if it cannot fulfill the request as specified, and it MUST NOT issue a certificate with contents other than those requested." [1 <https://datatracker.ietf.org/doc/html/rfc8555#section-7.4>] Ultimately, I believe clients would be better served if they were only required to specify a duration within the new-order request. The server should figure out the exact timestamps at issuance. Best, James [1] https://datatracker.ietf.org/doc/html/rfc8555#section-7.4 [2] https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5 [3] https://github.com/cabforum/servercert/blob/main/docs/BR.md#632-certificate-operational-periods-and-key-pair-usage-periods [4] https://github.com/cabforum/servercert/blob/main/docs/BR.md#161-definitions [5] https://github.com/cabforum/servercert/blob/main/docs/BR.md#4911-reasons-for-revoking-a-subscriber-certificate On Mon, Mar 11, 2024 at 2:08 PM Rob Stradling <rob= 40sectigo....@dmarc.ietf.org> wrote: > RFC8555 was published [1] 5 years ago today! > > Just thinking aloud, 'cos I'm curious what folks here think... > At what point might it make sense to start work on an 8555-bis? > > There's a fairly long list of Errata [2]: 10 Verified, 5 Reported, and 4 > Held for Document Update. > > Would it make sense for an 8555-bis document to incorporate and obsolete > any of the "add-on" RFCs / I-Ds, such as RFC8738, that have been published > since RFC8555? Or, conversely, would it be preferable to not do that? > > With 5 years of deployment experience behind us, have any "missing" > features in RFC8555 been identified that would be best addressed by > updating the core specification (i.e., in an 8555-bis document) rather than > by writing new "add-on" I-Ds? Or, conversely, are "add-on" I-Ds always the > preferred approach? (The "missing" feature that immediately springs to my > mind is "profiles" [3]). > > > [1] > https://mailarchive.ietf.org/arch/msg/rfc-dist/25pD6Za_dVkXMbJwyPhBJR6nIlo/ > [2] https://www.rfc-editor.org/errata_search.php?rfc=8555 > [3] > https://mailarchive.ietf.org/arch/msg/acme/BLVAayrTrUCegT4s2twci3Q2BY8/ > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
