Skip to main content

Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension
draft-ietf-acme-ari-07

Discuss


Yes

Deb Cooley

No Objection

Erik Kline
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Orie Steele

No Record

Francesca Palombini
Warren Kumari

Summary: Has 3 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.

Murray Kucherawy
Discuss
Discuss (2025-01-08) Sent for earlier
Section 7.2 declares a new "Specification Required" registry.  However, it doesn't provide any advice to the Designated Experts, which is strongly recommended by RFC 8126, Section 4.6.
Comment (2025-01-09) Sent for earlier
I support Eric's DISCUSS.

Why is the SHOULD in Section 4.3 only a SHOULD?  When would you legitimately do something other than what it says?

I have the same question about the SHOULDs in Sections 4.3.2, 4.3.3, and 5.
Paul Wouters
Discuss
Discuss (2025-01-06) Sent
Thanks for this document. It can be a useful extension but I do have some issues I would like to discuss / clarify


        Query the renewalInfo resource to get a suggested renewal window.
        Select a uniform random time within the suggested window.
        If the selected time is in the past, attempt renewal immediately.

This seems to skew to "now" which would only cause the ACME server more load than without
this extension (one GET and one actual renewal). Why not let the client select a uniform
random time between "now" and "end" if "now" > "start" ?


        it indicates both the earliest time and a target time.

It is really not the "earliest time" because an ACME server isn't going to refuse it? I would
rewrite this to just say "it indicates the desired target time".

This does bring up a point of concern. Clients who do not implement this
have an advantage on an overloaded server compared to clients who do
implement this. For example, let's say some new industry certification
license says "certifiates MUST always be valid for at least two
more weeks".  Wouldn't it make more sense for the server to check the
"urgency" of the client request and when (too) busy, start rejecting to
renew those with plenty of lifetime left?

I am also not sure about the argument of revocation for timing. Either
the owner of the cert to be revoked knows this and is already in the
process of replacing the cert/private key, and it wants to get a new
cert issued "now", or it is completely unaware, and most likely whatever
caused the leak of the current cert/private key, would also leak this
renewed one. I don't think an ACME server can help with either cases by
issuing shorter calls to renew. These would also be certificate specific
and I understood this unauthenticated extension to be generic and based
on load, and not on specific individual certificate issues.

        Clients SHOULD set reasonable limits on the their checking interval. For
        example, values under one minute could be treated as if they were one
        minute, and values over one day could be treated as if they were one day.

This really does violate the "compliant clients MUST" clause :)


Security Considerations:

        This document specifies that renewalInfo resources MUST be exposed
        and accessed via unauthenticated GET requests, a departure from
        RFC8555's requirement

Where does it specify this, other then right here? This specification should be
outside the Security Considerations section. What I can find is:

        To request the suggested renewal information for a certificate,
        the client sends a GET request to a path under the server's
        renewalInfo URL.

Maybe a sentence can be added there that this GET request is unauthenticated, so
that an implementer does not accidentally send credentials of any kind? Maybe
even say that a server MUST reject any attempted authorized connections for renewalInfo
to ensure such badly implemented clients cannot prosper ?


Perhaps also a clarifying sentence can be added along the lines of:

        If an on-path attacker would force ACME clients to postpone renewal indefinately,
        a properly implemented client would ignore these when the lifetime of its certificate
        becomes critically low (eg 7 days ?).

I also feel this belongs more in Section 4.3.2 with some concrete advise to implementers.

As for the last paragraph in the Security Considerations, it seems to specify specific server
behaviour that belongs in the formal specification instead of as security example. If we look
at the protocol requirement of the server to tell the client "renew now", why not define this
by either using a timestamp of unix time 0 (eg 1970) or by introducing a third keyword along
the "start" and "end" in the suggestedWindow property, eg "fetch-now": "recommended" ? Using
some kind of fake time seems like a poor hack for a protocol, as the text in the security
considerations already admits to (but then tries to band-aid the client)

Again, I feel this belongs in the base document specification and not in the Security Consideration section.
Comment (2025-01-06) Sent
        Conforming clients MUST attempt renewal

I find this a bit weasel wording. How about:

        Clients SHOULD attempet renewal

Clearly, a client can have some overriding local policy concern that trumps the ACME
servers

        The keyIdentifier field of the certificate's AKI extension has the hexadecimal bytes
        69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4 as
        its ASN.1 Octet String value. The base64url encoding of those bytes is
        aYhba4dGQEHhs3uEe6CuLN4ByNQ=

There seems to be an endian swap in here? Perhaps this text should be clarified?
The same for the the certificate's Serial Number field in the next paragraph.



Maybe instead of:

        GET https://example.com/....

Use:

        GET https://acme-server.example.com/.....

Similar for the explanationURL value.



        Clients MUST stop checking RenewalInfo after a certificate is expired.

I would stay "MUST skip checking RenewalInfo after a certificate is expired and immediately request a renewal."

        Clients MUST stop checking RenewalInfo after they consider a
        certificate to be replaced (for instance, after a new certificate
        for the same identifiers has been received and configured).

I would also avoid the "MUST stop" construct here. Perhaps:

        RenewalInfo MUST NOT be attempted for any certificate that has been
        replaced (for instance, after a new certificate for the same identifiers
        has been received and configured)
Éric Vyncke
Discuss
Discuss (2025-01-02) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-acme-ari-07
CC @evyncke

Thank you for the work put into this document. I can easily imagine that it is really useful.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Yoav Nir for the shepherd's detailed write-up including the WG consensus ***but it lacks*** the justification of the intended status.

Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), thanks for having considered his int-dir review:
https://datatracker.ietf.org/doc/review-ietf-acme-ari-07-dnsdir-telechat-huston-2024-12-15/
https://datatracker.ietf.org/doc/review-ietf-acme-ari-06-dnsdir-lc-huston-2024-11-23/

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 4.1

I think that the example is wrong for HTTP request, rather than
```
GET https://example.com/acme/renewal-info/
      aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE
```
it should probably be
"
GET /acme/renewal-info/
      aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE
Host: example.com
"

Also in this section, should the note about prefixing a "00" when the serial number is a negative number be more than a simple note but normative ? Or if this is per default in ACME, adding a reference ?
Comment (2025-01-02) Sent
## COMMENTS (non-blocking)

### Lack of HTTP-dir reviews

I can only regret that there was no HTTP directorate review for this document as one of my DISCUSS and one of my COMMENT are related to HTTP.

### url should be in uppercase

I have detected some "url" that should be "URL" as it is an acronym.

### Section 4.2

Is the first `Conforming clients SHOULD provide this URL to their operator` correct ? I would assume that this JSON reply is sent by the ACME server and not by the client.

Is the `Retry-After` the most suitable HTTP header ? I.e., while RFC 9110 section 10.2.3 is not really specific, [Mozilla spec](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) seems to indicate that it is not appropriate for a 200 response code. As I am not an HTTP expert, I am ready to be corrected of course but I would think that using a new key in the returned object would be neater.

## NITS (non-blocking / cosmetic)

### Appendix A

It seems that the year of this certificate is 0000, was it the intent ?

### Section 4.2
Suggest to use a more recent date (rather than 2021) in the example.
Deb Cooley
Yes
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Mahesh Jethanandani
No Objection
Orie Steele
No Objection
Roman Danyliw
No Objection
Comment (2025-01-08) Not sent
Thank you to Susan Hares for the GENART review.
Zaheduzzaman Sarker
No Objection
Comment (2025-01-07) Not sent
Thanks for working on this specification. Thanks to Michael Tüxen for the TSVART review.
Francesca Palombini
No Record
Warren Kumari
No Record