[Acme] Re: Éric Vyncke's Discuss on draft-ietf-acme-onion-05: (with DISCUSS and COMMENT)

[Q Misell <[e-mail]>]

Indeed, I did not understand - thanks for clarifying. I will make an
appropriate amendment to make it clear that "onion-csr-01" is only for use
in the context of .onion domains.
------------------------------

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, 14 Ion 2025 am 15:47 Eric Vyncke (evyncke) <[e-mail]>
ysgrifennodd:

> Hello Q,
>
>
>
> Thanks for your reply and the updated version, which addresses all my
> non-blocking COMMENT.
>
>
>
> It seems that I was not clear in my DISCUSS point though, sorry about that.
>
>
>
> The DISCUSS is based on the text below that I find ambiguous whether
> “onion-csr-01” challenge can be used also for non “.onion” FQDN, and by
> ‘can be used’ I do not only mean technically but also whether the ACME WG
> has agreed on this extended non .onion use and whether it fits the ACME
> charter. All in all, adding a sentence like “This “onion-csr-01” challenge
> MAY (or MUST NOT) be used for non “.onion” Special-Use Domain Names.” Will
> clear the ambiguity and I will clear my DISCUSS ballot.
>
>
>
> ```
>
> Two methods already defined in ACME and allowed by the CA/BF ("http-01"
> and "tls-alpn-01") do not allow issuance of wildcard certificates. A
> ".onion" Special-Use Domain Name can have subdomains (just like any other
> domain in the DNS), and a site operator may find it useful to have one
> certificate for all virtual hosts on their site.
>
> ```
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Q Misell <q=[e-mail]>
> *Date: *Monday, 13 January 2025 at 10:57
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *Tomofumi Okubo <[e-mail]>, The IESG <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-acme-onion-05: (with
> DISCUSS and COMMENT)
>
>
>
> 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) <[e-mail]>
> 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 <[e-mail]>
> *Date: *Wednesday, 8 January 2025 at 20:01
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *The IESG <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *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 <
> [e-mail]> 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.
>
>