Hi Orie, Thanks for the very detailed comments!
> 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. Unfortunately, the CA/BF does not allow this, so we're stuck with DER encoding for the time being. > 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. Good catch! Will amend. > Is this really a MUST? given the "impossible" comment? Yes it probably is. Will amend. > The use of SHOULD here, implies there are alternatives which might be better choices, I wonder what those might be. On the contrary. There are alternative that are worse choices (that is connecting over the plain internet) - however the use of Tor to connect to an ACME server isn't always feasible, hence the should. > 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. A few people noticed this mistake, it will be fixed in the next revision. > The next section basically says this, so maybe its a no-op, but I'd prefer stronger warnings than SHOULD on this front. I will amend SHOULD to MUST in where appropriate. Q ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. Ar Maw, 7 Ion 2025 am 18:48 Orie Steele via Datatracker <nore...@ietf.org> ysgrifennodd: > Orie Steele has entered the following ballot position for > draft-ietf-acme-onion-05: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-acme-onion/ > > > > ---------------------------------------------------------------------- > 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( <<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:secur...@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. > > > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
