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 <[email protected]>
Date: Monday, 13 January 2025 at 10:57
To: Eric Vyncke (evyncke) <[email protected]>
Cc: Tomofumi Okubo <[email protected]>, The IESG <[email protected]>,
[email protected] <[email protected]>,
[email protected] <[email protected]>, [email protected] <[email protected]>,
[email protected] <[email protected]>
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)
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Date: Wednesday, 8 January 2025 at 20:01
To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>
Cc: The IESG <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:tomofumi.okubo%[email protected]>
<[email protected]<mailto:tomofumi.okubo%[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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 -- [email protected]
To unsubscribe send an email to [email protected]
