Reviewer: Peter van Dijk Review result: Ready with Nits I am the assigned DNSDIR reviewer for this document. This review is for version -02, although I see that the working version on GitHub is slightly newer.
While writing this review, I filed a PR on GitHub with a few small editorial nits (https://github.com/AS207960/acme-onion/pull/3). Note that while I am well versed in DNS, I'm somewhat weaker when it comes to all of Tor, ACME, and X.509 in general, so it is possible I ask dumb questions :-) This document is in great shape and appears to be well thought out. I see nothing that prevents publication, but I do have a few questions/small notes. I have marked this review as "Ready with Nits". I cannot fully vet section 3.2, but it did raise a question for me: > nonce ... "It MUST NOT be valid for more than 30 days." what does it mean for a nonce to have a validity period? I also cannot fully judge section 4, but it seems coherent. Section 6 comes closer to DNS than any other part of the document, and this mapping of CAA into service data makes sense to me. The single bit "caa-critical" signal in 6.3 is clever. 6.4 makes me wonder if we could do the same trick in DNS land - using DNSSEC keys to sign a CAA sent in an ACME request, but I digress :) In 6.4, will it be clear to people more proficient in ACME that a null value for caa becomes a zero length string for signature calculation purposes? (Assuming that that is true.) I agree with the considerations in section 8.1, although I wonder what would happen if the CA's software was running under something like `torify`. Should 8.7 have a few words on Certificate Transparency? The rest of 8 makes sense to me. In Appendix A, the bit ".onion" s looks weird. Perhaps lose the space? (There's another spurious space, with different origins, before Iain's last name in the Acknowledgements.) _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
