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] Happy Birthday ACME!

[Michael Richardson]

I think when doing a bis document you need to ask yourself:
1) am I trying to move it to Internet Standard?
-or-
2) am I trying to do ACME v2.0.

(1) involves ripping out everything that wasn't implemented/used.
(2) involves adding everything you forgot last time.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Happy Birthday ACME!

[Aaron Gable]

Happy birthday, RFC8555!

I've thought frequently about the idea of an ACME-bis over the last few
years. I have a note going since at least 2022 which I occasionally add new
ideas to, and I've had a few offline conversations with others about
their wishlists. At the end of the day, I think only two of the changes I'd
like to make are backwards-incompatible:

1. All URLs (new-order, authorizations, challenges, finalize, etc) should
be constructable just from the ACME server's root path and an ID, rather
than requiring the Directory to list all the top-level endpoints, and for
order objects to list all the authorization and certificate URLs. To the
best of my understanding, the ACME API URLs are completely unspecified due
to an overly-strict reading of an older IETF best-practice which said that
RFCs should not mandate path structure on servers. But it turns out that,
as long as the server gets to pick the root path however it wants, it's
totally fine to mandate structure below that root path. We should do so.

2. I think it is unfortunate that the finalize request includes a CSR. This
requires ACME client implementations to have x509/ASN.1/DER encoding
capabilities, and incentivizes server implementations to take the lazy
route (copying values straight from the CSR to the issued certificate)
instead of being very careful and intentional with the values in the issued
cert. The only advantages of the CSR are that it acts as a container for
the pubkey, and that it can carry additional information (such as requests
for extensions) that the server might honor. Both of these can be replaced
by, in my opinion, cleaner mechanisms.

Everything else that I'd love to include in an ACME-bis could be done as
add-on documents without obsoleting 8555 itself:

3. Profile advertisement in the Directory, and profile selection in the
new-order request. (Unless we wanted to replace the current
notBefore/notAfter fields, in which case this also becomes a
backwards-incompatible change.)
4. Presenting the desired pubkey at new-order time, and implementing true
proof-of-control via the same authorization/challenge system as ACME
provides for other information (identifiers) to be included in the
certificate. (Notably, using the challenge system for this also allows for
demonstrating proof of control over KEM pubkeys which cannot produce
traditional signatures, which may be important in the post-quantum
cryptography era.)

As for incorporating other existing documents (such as TLS-ALPN-01,
ACME-IP, ACME CAA, etc), I'm truly not sure what the best practice is. I
think they should probably be left as-is as long as they're compatible with
a hypothetical ACME-bis, and incorporated directly into ACME-bis if they
would become incompatible with it. (For example, ACME-IP could be left
untouched, as it simply registers a new identifier type, while RFC 9115
ACME Delegated Certificates would likely need to be updated due to its
heavy reliance on the CSR.)

Thanks for starting this discussion!
Aaron

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

[Acme] Happy Birthday ACME!

[Rob Stradling]

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