Re: [Acme] Happy Birthday ACME!

[James Kasten]

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
].

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
   ] and
   that there may be client/server differences in the interpretation of leap
   seconds [3
   
].
   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
   
,
   5
   

   ].
   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
]

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  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/

Re: [Acme] Happy Birthday ACME!

[Yoav Nir]

Hi, Rob

The first question whenever someone proposes a bis document is, of course, “are 
you volunteering to edit?”

Jokes aside, it’s always a question of whether or not it is worth the effort. 
Not just for whoever is editing, but the usual effort associated with any 
document, such as WG participants, shepherd, AD, IESG, various directorates, 
RFC editor.

So before embarking on something like this, it’s not enough to just count the 
number of errata. You need to put yourself in the shoes of a naive implementer 
who doesn’t know about errata. Are the errors big enough that they might lead 
them to make a mistake in the implementation?  Text that uses “example.com 
” instead of “example.org ” probably 
isn’t. Text that says that a challenge object with an error cannot have the 
“processing” status when it can likely is.

As for adding other RFCs, that’s again a judgement call. We did merge some 
add-ons to IKEv2 in one of its revisions. It make sense to merge them if the 
add-on is so obvious and so necessary, that pretty much every implementation of 
8555 would also implement the other document. Is RFC8738 like that? Or are IP 
identifiers so rare and curious that many implementations exclude them?

As always, it’s up to the group whether making a significantly bigger document 
with some of the add-ons makes sense. In general, groups and ADs tend to prefer 
smaller documents, but that is decided on a case-by-case basis.

Yoav

> On 11 Mar 2024, at 23:08, Rob Stradling  
> 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

Re: [Acme] ACME leadership changes

[Sean Turner]

Congrats Tomofumi!

spt

> On Mar 7, 2024, at 16:48, Roman Danyliw  wrote:
> 
> Hi WG!
> 
> As Deb (Cooley) will be the new, incoming SEC AD at the Brisbane meeting, 
> there is a vacancy left in the co-chair team of ACME.  It is my pleasure to 
> announced that Tomofumi Okubo will be stepping in as the new-chair.  Tomofumi 
> brings a wealth of experience in PKI and as a contributor in PKI-related IETF 
> WGs.
> 
> Tomofumi: Thank you for your willingness to serve.
> 
> Deb: Congratulations on your new AD role!  Thank you for your leadership in 
> the WG.
> 
> Yoav (Nir): Despite these transitions, thank you for your continued service 
> as co-chair in the WG!
> 
> Deb isn't going too far from ACME.  After the AD transition in Brisbane, the 
> responsible AD for ACME will transition from me to her.
> 
> Regards,
> Roman
> 
> 
> ___
> 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