Re: [Acme] Happy Birthday ACME!

[James Kasten <[e-mail]>]

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=
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>