Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names
draft-ietf-acme-onion-07

[Ballot comment]
Thanks for addressing the my DISCUSS point and the COMMENTs points kept below for archiving.

The original ballot was https://mailarchive.ietf.org/arch/msg/iesg/Yqgi7FDSiIra2cAhuFvJqAgtPas/

## COMMENTS (non-blocking)

### Section 1

s/These use the ".onion"/These services use the ".onion"/ (I had to re-read the whole sentence 3 times to understand it)

### Sections 3.1.2 and 3.1.3

As 3.1.1 uses 'MUST NOT', suggest to s/can be used/MAY be used/

### Section 3.2

What is the basis for selecting 30 days? I would assume that the ACME challenge/response is done within minutes if not seconds. Or is this challenge/response assumed to be executed multiple times ?

Only supporting Ed25519 seems to lack agility or am I missing something ?

It is also unclear to me whether authKey is the client public key (probably) or the server public key. Please add clarifying text. Some explanations could be given on when to use this field.

### Section 4

Is authKey the same field as in section 3.2 ? This would explain this field role but is confusing to the reader. Suggest adding something like "this field is specified in section 4' when introducing this field in section 3.2.

### Section 7.1

To avoid any ambiguity, please add a reference to the registry by its URI https://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods

The legend of table 1 should probably use singular and not plural.

[Ballot comment]
In Section 8.5, what does "SHOULD consider" mean?  I suggest lowercasing the "SHOULD".  This happens again in Sections 8.9 and 8.9.1.

I don't understand what "SHOULD wait some (indeterminate) amount of time" in Section 4 means either.  It seems peculiar to make an unspecified thing formally optional.

The instances of SHOULD and SHOULD NOT in Sections 3.1.2, 3.2, 5, 6.2, and 6.4, seem bare in the sense that I don't know when I might choose to contradict what they say.  If we're giving implementers a choice here, we should leave them with some idea under what conditions they might choose to do the opposite of what it says.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

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

It has been discussed in-person at several IETF’s, and there has been moderate
amount of email discussions.

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)?

There are two implementation in development.

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

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

N/A

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 document is clearly written and easy to understand.

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 Security Area (sec), list of 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.

This is an extension to RFC 8555 which is standards track.
There are also some implementations so “Proposed Standard” is the right status
for this document and would be 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 requested changes to the 3 registries ("ACME Validation Methods", "ACME Error Types" and "ACME Directory Metadata Fields") looks fine.

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 3 registries listed above require designated expert review.
The request is straight forward.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

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

It has been discussed in-person at several IETF’s, and there has been moderate
amount of email discussions.

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)?

There are two implementation in development.

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

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

N/A

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 document is clearly written and easy to understand.

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 Security Area (sec), list of 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.

This is an extension to RFC 8555 which is standards track.
There are also some implementations so “Proposed Standard” is the right status and
woult be 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 requested changes to the 3 registries ("ACME Validation Methods", "ACME Error Types" and "ACME Directory Metadata Fields") looks fine.

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 3 registries listed above require designated expert review.
The request is straight forward.

[Ballot comment]
Thank you to Dale R. Worley for the GENART review.

** Per the normative Tor reference:
  [tor-spec] The Tor Project, "Tor Specifications",
              .

Is there any versioning to the protocol or timestamp that can be provided for this bare URL

** Section 3.2.  Consider providing a reference to RFC2986 for PKCS#10.

** Section 4.
    instead the ACME server MUST attempt to
  calculate its CLIENT-ID as per Part "Client Behaviour" of [tor-spec].

The section name in [tor-spec] is “Client Behavior” – “American English” spelling.

** Section 3.2.  What is the basis for the nonce needing to contain at least 64- bits of entropy

** Section 8.2.  Editorial.
    The reasons the author wishes to pursue this path in
  the first place are detailed in Appendix A.

Should this read s/The reasons the author wishes to pursue/The reasons the WG pursued/ -- this is a consensus document.

** Section 8.5, 8.9, 8.9.1

-- Section 8.5  “A site operator SHOULD consider the privacy implications of redirecting to a non-".onion" site”

-- Section 8.9 “Hidden Service  operators SHOULD consider the privacy implications of this before requesting WebPKI certificates.”

-- Section 8.9.1. “… for internal or non-public services, operators SHOULD consider using
  self-signed or privately-trusted certificates that aren't logged to certificate transparency.”

What does it mean to “SHOULD consider …” a topic?  This is an optional adherence (“SHOULD”) to a non-binding review (“consider”).

** Section 8.9
  ACME client developers SHOULD warn
  users about the risks of CT logged certificates for hidden services.

How would this warning be accomplished?

** Section 8.9.2
  When an ACME client is registering to an ACME server it SHOULD
  provide minimal or obfuscated subscriber details to the CA such as a
  pseudonymous email address, if at all possible.

What does “SHOULD … if at all possible” mean?

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-acme-onion-05
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-acme-onion-05.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### Double encoding

```
270   csr (required, string)  The CSR in the base64url-encoded version of
271       the DER format.  (Note: Because this field uses base64url, and
272       does not include headers, it is different from PEM.)
```

Its a shame there is double encoding here, but I gather it is to support extensibility.

I'm sure its been considered, but I will state it it anyway, the csr can be transported as the payload without json object encapsulation.

For example:

```
278   {
279     "protected": base64url({
280       "alg": "ES256",
281       "kid": "https://example.com/acme/acct/evOfKhNU60wg",
282       "nonce": "UQI1PoRi5OuXzxuX7V7wL0",
283       "url": "https://example.com/acme/chall/bbc625c5",
          "cty": "application/pkcs10",
284     }),
285     "payload": base64url( <> ),
288     "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
289   }
```

I see that the extensibility to the payload is later used for "onionCAA" in an example, so feel free to ignore this comment, assuming that parameter is not natural to include in the CSR.

### indeterminate wait

```
341   In the case the Ed25519 public key is novel to the client it will
342   have to resign and republish its hidden service descriptor.  It
343   SHOULD wait some (indeterminate) amount of time for the new
344   descriptor to propagate the Tor hidden service directory servers,
345   before proceeding with responding to the challenge.  This should take
346   no more than a few minutes.  This specification does not set a fixed
```

It is sorta determined below...
Also, if the should is ignored or the window is too short, the check will fail, so this is really a MUST wait for the service to be published to the network, and the timing is simply unknown?


### acmeforonions.org

```
386   create2-formats 2
387   single-onion-service
388   caa 128 issue "test.acmeforonions.org;validationmethods=onion-csr-01"
389   caa 0 iodef "mailto:security@example.com"
390   introduction-point AwAGsAk5nSMpAhRqhMHbTFCTSlfhP8f5PqUhe6DatgMgk7kSL3
391           KHCZUZ3C6tXDeRfM9SyNY0DlgbF8q+QSaGKCs=
392   ...
```

Very cool site!
It is mentioned in the implementation report, but that will be removed on publication.
Consider an alternative citation for "acmeforonions.org", and although this is a style nit, I prefer to use examples that are not functional, and will therefore age consistently, such as acmeforonions.example.

Consider that "acmeforonions.org" may change ownership or content in the future.


### SHOULD wait?

```
426   If the hidden service has client authentication enabled then it will
427   be impossible for the ACME server to decrypt the second layer
428   descriptor to read the CAA records until the ACME server's public key
429   has been added to the first layer descriptor.  To this end an ACME
430   server SHOULD wait until the client responds to an authorization
431   before checking CAA, and treat this response as indication that their
432   public key has been added and that the ACME server will be able to
433   decrypt the second layer descriptor.
```

Is this really a MUST? given the "impossible" comment?

### Alternative channels for requesting certs

```
755   ACME clients SHOULD connect to ACME servers over the Tor network to
756   alleviate this, preferring a hidden service endpoint if the CA
757   provides such a service.
```

The use of SHOULD here, implies there are alternatives which might be better choices, I wonder what those might be.

## Nits

### Framing

```
652   suitability.  The reasons the author wishes to pursue this path in
653   the first place are detailed in Appendix A.  It is felt that there is
```

This is a proposed standard from a WG, hopefully the working group is supportive of this path as well : )

This comment also applies to Appendix A.


### MUST consider privacy

```
709   A site operator SHOULD consider the privacy implications of
710   redirecting to a non-".onion" site - namely that the ACME server
711   operator will then be able to learn information about the site
712   redirected to that they would not if accessed via a ".onion" Special-
713   Use Domain Name, such as its IP address.  If the site redirected to
```

I'm not sure why making it not a MUST is better guidance.
There are a few other SHOULD consider's in Sec Considerations, which seem like MUSTs to me.

Especially this section:

```
759   If an ACME client requests a publicly trusted WebPKI certificate it
760   will expose the existence of the Hidden Service publicly due to its
761   inclusion in Certificate Transparency logs [RFC9162].  Hidden Service
762   operators SHOULD consider the privacy implications of this before
763   requesting WebPKI certificates.  ACME client developers SHOULD warn
764   users about the risks of CT logged certificates for hidden services.
```

Especially risky for experimental / test / demographic specific sub environments, like high-value.target.....onion.

The next section basically says this, so maybe its a no-op, but I'd prefer stronger warnings than SHOULD on this front.

[Ballot comment]
I find the use of "example.com" confusing. Does this mean a valid DNS identifier in the real DNS accessed over the regular internet?
If not, should it not be better to use "example.onion" ? Maybe also using something like "acme-server.example.com" could be a bit clearer?

Maybe explaining (for non tor experts) the relationship between key identifiers and the XXXX.onion site name?

Section 8.2:
The use of "the author wishes" is a left over from when this was an individual document. As this is now a WG document it should be generalized, eg "it is desired" ?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-acme-onion-05
CC @evyncke

Thank you for the work put into this document.

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

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

You may also expect a DNS directorate review as it has been requested.

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:

### onion-csr-01 and global Internet ACME

It is easy to clear this DISCUSS by replying to the next paragraph.

May the onion-csr-01 challenge be used over the plain global Internet ? As it allows for wildcard certificates and plain ACME does not, it would seem necessary to specify whether it is supported or forbidden.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 1

s/These use the ".onion"/These services use the ".onion"/ (I had to re-read the whole sentence 3 times to understand it)

### Sections 3.1.2 and 3.1.3

As 3.1.1 uses 'MUST NOT', suggest to s/can be used/MAY be used/

### Section 3.2

What is the basis for selecting 30 days? I would assume that the ACME challenge/response is done within minutes if not seconds. Or is this challenge/response assumed to be executed multiple times ?

Only supporting Ed25519 seems to lack agility or am I missing something ?

It is also unclear to me whether authKey is the client public key (probably) or the server public key. Please add clarifying text. Some explanations could be given on when to use this field.

### Section 4

Is authKey the same field as in section 3.2 ? This would explain this field role but is confusing to the reader. Suggest adding something like "this field is specified in section 4' when introducing this field in section 3.2.

### Section 7.1

To avoid any ambiguity, please add a reference to the registry by its URI https://www.iana.org/assignments/acme/acme.xhtml#acme-validation-methods

The legend of table 1 should probably use singular and not plural.

IESG/Authors/WG Chairs:

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

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

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

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

the early registration for:

Label: onion-csr-01

will have its reference changed to [ RFC-to-be ].

Second, in the ACME Error Types registry also in the Automated Certificate Management Environment (ACME) Protocol registry group, the early registration for:

Type: onionCAARequired

will have its reference changed to [ RFC-to-be ].

Third, in the ACME Directory Metadata Fields registry also in the Automated Certificate Management Environment (ACME) Protocol registry group, the early registration for:

Field name: onionCAARequired

will have its reference changed to [ RFC-to-be ].

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 GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2024-11-26):

From: The IESG
To: IETF-Announce
CC: acme-chairs@ietf.org, acme@ietf.org, debcooley1@gmail.com, draft-ietf-acme-onion@ietf.org, tomofumi.okubo+ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names) 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) Extensions for
  ".onion" Special-Use Domain Names'
  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-11-26. 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


  The document defines extensions to the Automated Certificate
  Management Environment (ACME) to allow for the automatic issuance of
  certificates to Tor hidden services (".onion" Special-Use Domain
  Names).

Discussion

  This note is to be removed before publishing as an RFC.

  Source for this draft and an issue tracker can be found at
  https://github.com/AS207960/acme-onion.

  The project website and a reference implementation can be found at
  https://acmeforonions.org.




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



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

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

It has been discussed in-person at several IETF’s, and there has been moderate
amount of email discussions.

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)?

There are two implementation in development.

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

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

N/A

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 document is clearly written and easy to understand.

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 Security Area (sec), list of 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 requested changes to the 3 registries ("ACME Validation Methods", "ACME Error Types" and "ACME Directory Metadata Fields") looks fine.

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 3 registries listed above require designated expert review.
The request is straight forward.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

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

It has been discussed in-person at several IETF’s, and there has been moderate
amount of email discussions.

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)?

There are two implementation in development.

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

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

N/A

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 document is clearly written and easy to understand.

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 Security Area (sec), list of 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 requested changes to the 3 registries ("ACME Validation Methods", "ACME Error Types" and "ACME Directory Metadata Fields") looks fine.

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 3 registries listed above require designated expert review.
The request is straight forward.

Changed document external resources from: None to:

github_repo https://github.com/AS207960/acme-onion
related_implementations https://acme.api.acmeforonions.org (Reference ACME CA)
related_implementations https://crates.io/crates/torrosion (Rust Tor library)
related_implementations https://github.com/AS207960/tor (Tor fork with CAA)
related_implementations https://github.com/as207960/bjorn (Rust CA implementation)
related_implementations https://pypi.org/project/certbot-onion/ (Certbot plugin)
webpage https://acmeforonions.org (Project webpage)