Hello Éric, My apologies for the delayed response. Thank you very much for the review and comments.
Onion is an extension to RFC8555 which is standards track and already has some implementations as well. Therefore, I do believe that the proposed standard would be the suitable status for this draft. I have also updated the shepherd's write-up accordingly. Thanks again! Tomofumi On Thu, Jan 2, 2025 at 8:33 PM Éric Vyncke via Datatracker <nore...@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-acme-onion-05: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > 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. > > > ---------------------------------------------------------------------- > 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. > > > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
