Hi Roman, Thanks for the comments.
> Is there any versioning to the protocol or timestamp that can be provided for this bare URL. Unfortunately not. The Tor spec is a living standard, and doesn't use versioning. This annoys me as well. > Consider providing a reference to RFC2986 for PKCS#10. Will do. > The section name in [tor-spec] is “Client Behavior” – “American English” spelling. Good catch, thanks! > What is the basis for the nonce needing to contain at least 64- bits of entropy. It is defined as such by the CA/BF BRs, this document makes no attempt to question the BRs. > Should this read s/The reasons the author wishes to pursue/The reasons the WG pursued/ -- this is a consensus document. This will be fixed. > What does it mean to “SHOULD consider …” a topic? This is an optional adherence (“SHOULD”) to a non-binding review (“consider”). These will be updated to a MUST consider. > How would this warning be accomplished? Intentionally ambiguous. An ACME client could have any number of possible UIs, so this document does not attempt to define this further. > What does “SHOULD … if at all possible” mean? A CA may not allow this, i.e. a CA may require an email and an actual name to be provided. 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 Mer, 8 Ion 2025 am 04:46 Roman Danyliw via Datatracker <nore...@ietf.org> ysgrifennodd: > Roman Danyliw has entered the following ballot position for > draft-ietf-acme-onion-05: No Objection > > 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: > ---------------------------------------------------------------------- > > Thank you to Dale R. Worley for the GENART review. > > ** Per the normative Tor reference: > [tor-spec] The Tor Project, "Tor Specifications", > <https://spec.torproject.org/print.html>. > > Is there any versioning to the protocol or timestamp that can be provided > for > this bare URL > > ** Section 3.2. Consider providing a reference to RFC2986 for PKCS#10. > > ** Section 4. > instead the ACME server MUST attempt to > calculate its CLIENT-ID as per Part "Client Behaviour" of [tor-spec]. > > The section name in [tor-spec] is “Client Behavior” – “American English” > spelling. > > ** Section 3.2. What is the basis for the nonce needing to contain at > least > 64- bits of entropy > > ** Section 8.2. Editorial. > The reasons the author wishes to pursue this path in > the first place are detailed in Appendix A. > > Should this read s/The reasons the author wishes to pursue/The reasons the > WG > pursued/ -- this is a consensus document. > > ** Section 8.5, 8.9, 8.9.1 > > -- Section 8.5 “A site operator SHOULD consider the privacy implications > of > redirecting to a non-".onion" site” > > -- Section 8.9 “Hidden Service operators SHOULD consider the privacy > implications of this before requesting WebPKI certificates.” > > -- Section 8.9.1. “… for internal or non-public services, operators SHOULD > consider using > self-signed or privately-trusted certificates that aren't logged to > certificate transparency.” > > What does it mean to “SHOULD consider …” a topic? This is an optional > adherence (“SHOULD”) to a non-binding review (“consider”). > > ** Section 8.9 > ACME client developers SHOULD warn > users about the risks of CT logged certificates for hidden services. > > How would this warning be accomplished? > > ** Section 8.9.2 > When an ACME client is registering to an ACME server it SHOULD > provide minimal or obfuscated subscriber details to the CA such as a > pseudonymous email address, if at all possible. > > What does “SHOULD … if at all possible” mean? > > > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
