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

# 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( <<bytes>> ),
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.