Hi Eric, > 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.
I do not quite follow what you mean here. This document defines extensions to ACME, and ACME may be carried over the plain Internet or over Tor. "onion-csr-01" only makes sense in the context of requesting certificates for .onion domains, however the medium over which these are requests are made is of no concern to ACME. > s/These use the ".onion"/These services use the ".onion"/ (I had to re-read the whole sentence 3 times to understand it) Will incorporate. > As 3.1.1 uses 'MUST NOT', suggest to s/can be used/MAY be used/ Agreed, will incorporate. > 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? This is copied from the CA/BF BRs, I will add a reference to them. It may be that some manual work is involved in accessing an offline identity key on a HSM or some air-gapped machine, hence the long time. > Only supporting Ed25519 seems to lack agility or am I missing something? Tor only supports Ed25519. > It is also unclear to me whether authKey is the client public key (probably) or the server public key. Please add clarifying text. Will do. > Is authKey the same field as in section 3.2? I will add a cross reference between section 3.2 and section 4. > To avoid any ambiguity, please add a reference to the registry by its URI Will do. 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 Iau, 9 Ion 2025 am 12:58 Eric Vyncke (evyncke) <evyn...@cisco.com> ysgrifennodd: > Hello Tomofumi, > > > > Thanks for your reply and for the shepherd’s write-up update: it makes > sense indeed to set the intended status to PS. > > > > Regards > > > > -éric > > > > *From: *Tomofumi Okubo <tomofumi.ok...@gmail.com> > *Date: *Wednesday, 8 January 2025 at 20:01 > *To: *Eric Vyncke (evyncke) <evyn...@cisco.com> > *Cc: *The IESG <i...@ietf.org>, draft-ietf-acme-on...@ietf.org < > draft-ietf-acme-on...@ietf.org>, acme-cha...@ietf.org < > acme-cha...@ietf.org>, acme@ietf.org <acme@ietf.org>, > tomofumi.okubo+i...@gmail.com <tomofumi.okubo+i...@gmail.com> > *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-acme-onion-05: (with > DISCUSS and COMMENT) > > 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
