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, LEI 875500FXNCJPAPF3PD10. ICO register №: 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.
Reviewer: Qin Wu
Review result: Has Nits
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
This draft extensions to the Automated Certificate Management Environment
(ACME) to allow for the automatic issuance of certificates to Tor hidden
services
This document is on the right track and ready for publication. I have the
following comments on v-05: Major issues: None
Minor issues
1. Section 2
s/ as defined in Part Special Hostnames/ as defined in Special Hostnames part
2. Section 3.2 said
“ The two methods already defined in ACME and allowed by the CA/BF do
not allow issuance of wildcard certificates.
”
Which section of ACME document two methods, can you provide method name or
referenced section in ACME? Can you provide references for ACME in this
paragraph. Also I believe “the” in “The two methods” are not needed. 3. Section
3.2 said: “ A response generated using this nonce MUST NOT be accepted by the
ACME server if the nonce used was generated by the server more
than 30 days ago.
”
How does the server know nonce was generated 30+ days ago?
4. Section 6 said:
“ "caa" SP flags SP tag SP value NL
[Any number of times]
”
Is NL standing for Newline or something else? There is no explanation in the
text. 5. Section 6.4.1 said: “the ACME client does not
provide an "onionCAA" object in its finalize request the ACME server
MUST respond with an "onionCAARequired" error to indicate this
”
Further, section 6.4.1 said:
“ Additionally, a new field is defined in the directory "meta" object
to signal this.
inBandOnionCAARequired (optional, boolean) If true, the ACME server
requires the client to provide the CAA record set in the finalize
request. If false or absent the ACME server does not require the
client to provide the CAA record set is this manner.
”
Would you like to clarify whether “onionCAARquired” error is also linked to
inBandOnionCAA required? If they are not the same thing, can you provide an
example for “onionCAARequired” Error Example? If they are the same thing, I
feel the word “Additional” introducing ambiguity. 6. I am not sure “standard”
is right term used in this draft? Should we replace “in this standard” with “in
this specification”
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx