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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-acme-ari and RFC 9773, changed IESG state to RFC Published)

[Ballot comment]
Thanks for fixing the IANA stuff.

== [previous comments] ==

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.

[Ballot comment]
Thanks for addressing my previous blocking DISCUSS points, see
https://mailarchive.ietf.org/arch/msg/acme/39amfomGbjKAMTDeAP_Q7mEpg54/

The points below were and are still non-blocking but I sincerely think that the document readability will be improved if addressed. The text sent by Aaron about these 2 points would be beneficial to the readers/implementers if included in a -09. The choice is really up to the author at this point.

## COMMENTS (non-blocking)

### Section 4.1

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 ?

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

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot comment]
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.

This is the shepherd write-up for draft-ietf-acme-ari

Current version is 06
Document author is Aaron Gable (aaron@letsencrypt.org)
Document shepherd is Yoav Nir (ynir.ietf@gmail.com)
Responsible AD is Deb Cooley (debcooley1@gmail.com)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG discussed this heavily in F2F meetings, with somewhat less discussion on
    the mailing list. For the WGLC more people did speak up in favor, with none
    objecting. For ACME, this is what consensus looks like.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Both Google and Let's Encrypt have server implementations in production.
The draft lists 4 client implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. The only formatted specification in the draft is a bit of json.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this draft is understandable, well-written. It's needed as evidenced by the
multiple existing implementations. I believe it's ready to be handed over.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

For the Security Area, common issues have been addressed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.
All the datatracker state attributes are correct.
ARI is an extension to RFC 8555 which is standards track.  There are also some implementations for it, so “Proposed Standard” is the right status. It’s too mature for “Experimental”.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The draft requests changes to four registries: "ACME Resource Types",
    "ACME Renewal Info Object Fields", "ACME Order Object Fields",
    and "ACME Error Types" - all four are ACME registries, and all
    assignments look OK.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

All four registries listed above require designated expert review.
The request is straight forward.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

[Ballot discuss]
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.

[Ballot comment]
        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)

[Ballot discuss]

# É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 ?

[Ballot comment]

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

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-acme-ari-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are four actions which we must complete.

First, in the ACME Resource Types registry in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

a single new registration will be made as follows:

Field Name: renewalInfo
Resource Type: Renewal Info object
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the ACME Renewal Info Object Fields registry. The new registry will be located in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

The new registry will be managed via Specification Required as defined in RFC8126. There are initial registrations in the new registry as follows:

Field Name Field type Reference
-----------+---------+-----------
suggestedWindow object [ RFC-to-be ]
explanationURL string [ RFC-to-be ]

Third, in the ACME Order Object Fields registry in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

a single new registration will be made as follows:

Field Name: replaces
Field Type: string
Configurable: true
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Fourth, in the ACME Error Types registry in the Automated Certificate Management Environment (ACME) Protocol registry group located at:

https://www.iana.org/assignments/acme/

a single new registration will be made as follows:

Type: alreadyReplaced
Description: The request specified a predecessor certificate which has already been marked as replaced
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: Geoff Huston. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2024-12-06):

From: The IESG
To: IETF-Announce
CC: acme-chairs@ietf.org, acme@ietf.org, debcooley1@gmail.com, draft-ietf-acme-ari@ietf.org, ynir.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Automated
Certificate Management Environment (ACME) Renewal
  Information (ARI) Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-12-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies how an ACME server may provide suggestions to
  ACME clients as to when they should attempt to renew their
  certificates.  This allows servers to mitigate load spikes, and
  ensures clients do not make false assumptions about appropriate
  certificate renewal periods.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-ari/



No IPR declarations have been submitted directly on this I-D.

This is the shepherd write-up for draft-ietf-acme-ari

Current version is 06
Document author is Aaron Gable (aaron@letsencrypt.org)
Document shepherd is Yoav Nir (ynir.ietf@gmail.com)
Responsible AD is Deb Cooley (debcooley1@gmail.com)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG discussed this heavily in F2F meetings, with somewhat less discussion on
    the mailing list. For the WGLC more people did speak up in favor, with none
    objecting. For ACME, this is what consensus looks like.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Both Google and Let's Encrypt have server implementations in production.
The draft lists 4 client implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. The only formatted specification in the draft is a bit of json.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this draft is understandable, well-written. It's needed as evidenced by the
multiple existing implementations. I believe it's ready to be handed over.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

For the Security Area, common issues have been addressed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.
All the datatracker state attributes are correct.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The draft requests changes to four registries: "ACME Resource Types",
    "ACME Renewal Info Object Fields", "ACME Order Object Fields",
    and "ACME Error Types" - all four are ACME registries, and all
    assignments look OK.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

All four registries listed above require designated expert review.
The request is straight forward.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

This is the shepherd write-up for draft-ietf-acme-ari

Current version is 06
Document author is Aaron Gable (aaron@letsencrypt.org)
Document shepherd is Yoav Nir (ynir.ietf@gmail.com)
Responsible AD is Deb Cooley (debcooley1@gmail.com)

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG discussed this heavily in F2F meetings, with somewhat less discussion on
    the mailing list. For the WGLC more people did speak up in favor, with none
    objecting. For ACME, this is what consensus looks like.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Both Google and Let's Encrypt have server implementations in production.
The draft lists 4 client implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. The only formatted specification in the draft is a bit of json.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this draft is understandable, well-written. It's needed as evidenced by the
multiple existing implementations. I believe it's ready to be handed over.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

For the Security Area, common issues have been addressed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.
All the datatracker state attributes are correct.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The draft requests changes to four registries: "ACME Resource Types",
    "ACME Renewal Info Object Fields", "ACME Order Object Fields",
    and "ACME Error Types" - all four are ACME registries, and all
    assignments look OK.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

All four registries listed above require designated expert review.
The request is straight forward.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/