> Well if CA is willing to run tor In house they can read caa record tor network (CA/B br forbids using external proxy to access tor website for verification purpose) and for onion challenge it already have the key to sign this on demand.
Good point, I evidently had not thought through things properly. > And it's kinda vague when acme server are running tor client and see caa in finalization object : it may process it or ignore it and even reject finalization because not implementing this extension as they think not needed Yeah that bit does need further clarification. My intent was a CA may process it if they want to, but are not required to do anything with it, giving the following outcomes: - CA with a Tor client and no CAA in finalize: fetch CAA over Tor - CA without a Tor client and no COO in finalize: error - CA with a Tor client and CAA in finalize: either fetch CAA over Tor or use provided CAA, up to CA preference, but do not error purely because the CAA is there - CA without a Tor client and CAA in finalize: use provided CAA I'll work on making that clearer in the next revision. ------------------------------ 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. On Tue, 17 Oct 2023 at 10:33, Seo Suchan <tjtn...@gmail.com> wrote: > well if CA is willing to run tor In house they can read caa record tor > network (CA/B br forbids using external proxy to access tor website for > verification perpose) and for onion challenge it already have the key to > sign this on demand > and it's kinda vague when acme server are running tor client and see caa > in finalization object : it may process it or ignore it and even reject > finalization because not implementing this extension as they think not > needed > > > On 2023년 10월 17일 오후 6시 23분 21초 GMT+09:00, Q Misell <q...@as207960.net> 작성함: > >> The rationale for expiry is that in the case of http-01 or tls-alpn-01 >> the ACME client need not have access to the Onion service's secret key. A >> long lived CAA signature could be generated with the key, provided to the >> ACME client to use, and the key could be kept away from the ACME client and >> only available on the machine running the Tor proxy. >> ------------------------------ >> >> 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. >> >> >> On Tue, 17 Oct 2023 at 04:15, Seo Suchan <tjtn...@gmail.com> wrote: >> >>> >>> not sure giving expiry by client side is meaningful: as we send this at >>> finalization step, and as something would be very wrong if one request >>> another certificate in 8 hours from last certificate so whatever value >>> client may put there will be expired by the time we request: in effect it'd >>> be act more like timestamp and if it is I kinda want it to be nonce for >>> that certificate finalization explicitly. >>> 2023-10-17 오전 3:10에 Q Misell 이(가) 쓴 글: >>> >>> Hi all, >>> >>> In-band CAA is now implemented on the reference CA at >>> https://acmeforonions.org and in the certbot-onion >>> <https://pypi.org/project/certbot-onion/> plugin. >>> draft-ietf-acme-onion-01 has also been published with the in-band CAA >>> spec (refined from my last email from issues that arose during >>> implementation). >>> >>> Cheers, >>> 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. >>> >>> >>> On Fri, 13 Oct 2023 at 17:19, Q Misell <q...@as207960.net> wrote: >>> >>>> I've found some time to specify in-band CAA, a quick first draft is in >>>> the working draft[1]. Looking forward to hearing people's thoughts. >>>> >>>> [1]: >>>> https://as207960.github.io/acme-onion/draft-ietf-acme-onion.html#name-alternative-in-band-present >>>> ------------------------------ >>>> >>>> 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. >>>> >>>> >>>> On Tue, 10 Oct 2023 at 21:22, Q Misell <q...@as207960.net> wrote: >>>> >>>>> Hi Silvio, >>>>> >>>>> Thanks for that info, that's quite helpful. >>>>> >>>>> I think the idea of allowing the client to just send the CAA lines >>>>> signed by its key would work well, and remove most if not all of the >>>>> problems I've been running into. >>>>> I'll work on implementing that in my draft, and see how difficult it'd >>>>> be to get that part only working in Boulder (as Let's Encrypt have already >>>>> indicated that they won't be implementing http-01 and tls-alpn-01 for >>>>> hidden services). >>>>> >>>>> Cheers, >>>>> 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. >>>>> >>>>> >>>>> On Tue, 10 Oct 2023 at 20:14, rhatto <rha...@torproject.org> wrote: >>>>> >>>>>> On Thu, Sep 07, 2023 at 04:55:51PM +0100, Q Misell wrote: >>>>>> > I've had some discussion recently with the Tor project on >>>>>> implementation >>>>>> > hurdles for draft-ietf-acme-onion. One concern that has been raised >>>>>> by a few is >>>>>> > the need to run a Tor client to validate requests, even with >>>>>> onion-csr-01, due >>>>>> > to the inclusion of CAA in the draft. >>>>>> >>>>>> Hi Q, and thanks for bringing this up. >>>>>> >>>>>> > One solution proposed to this is that the ACME client MAY[1] send >>>>>> the hidden >>>>>> > service descriptor to CA as part of the finalize request. The CA >>>>>> also MAY >>>>>> > require this, if they do not wish to run a Tor client. This, to my >>>>>> knowledge, >>>>>> > wouldn't reduce the security of the validation of CAA, as the >>>>>> descriptor >>>>>> > document is still cryptographically validated in the same way using >>>>>> the current >>>>>> > network consensus. Additionally the directory authorities that serve >>>>>> > descriptors are already non-trusted actors in Tor. >>>>>> > >>>>>> > The CA would still need a copy of the network consensus document to >>>>>> verify >>>>>> > the descriptor submitted by the client. Most directory authorities >>>>>> however >>>>>> > are reachable over standard HTTP over TCP, in addition to HTTP over >>>>>> Tor. >>>>>> > This would allow the CA to fetch the current consensus without any >>>>>> > connection to Tor. The consensus fetched this way would still be >>>>>> verified >>>>>> > against the trusted directory authorities of Tor[2]. >>>>>> >>>>>> Specifically, the "valid-after", "fresh-until", and "hsdir_interval" >>>>>> are >>>>>> the only consensus items needed to parse, decrypt and validate an >>>>>> Onion >>>>>> Service descriptor. >>>>>> >>>>>> > What are people's thoughts on this, and more importantly, what >>>>>> problems do >>>>>> > people see with this? >>>>>> >>>>>> After a lengthy discussion with Tor developers, we suggest the >>>>>> following >>>>>> options, prioritizing the least complex: >>>>>> >>>>>> 0. ACME clients MAY send "valid-after", "fresh-until" and >>>>>> "hs_interval" >>>>>> along with the descriptor, which would allow the ACME Server to >>>>>> verify >>>>>> CAA in a stateless way, without bootstrapping Tor to fetch the >>>>>> descriptor and without fetching the network consensus. >>>>>> >>>>>> 1. Only the descriptor is sent by the ACME client, so the ACME server >>>>>> would >>>>>> need to fetch and cache the network consensus. >>>>>> >>>>>> 2. The ACME client does not send the descriptor, leaving to the ACME >>>>>> server >>>>>> the job of fetching it, as stated on draft-ietf-acme-onion-00. >>>>>> >>>>>> For options 0 and 1 above, there are two ways that a consensus (or >>>>>> just the >>>>>> needed items) can be fetched either by ACME clients or servers: >>>>>> >>>>>> a. Through the Tor network, from one of many directory caches. >>>>>> >>>>>> As this involves bootstrapping Tor, it makes more sense for ACME >>>>>> clients to do this fetching, as clients are probably already >>>>>> connected >>>>>> to Tor in order to run an Onion Service or to make the ACME request >>>>>> through Tor. >>>>>> >>>>>> b. Doing HTTP over TCP, or HTTP over Tor to the directory authorities. >>>>>> >>>>>> While this is supported nowadays, it's not guaranteed to work in >>>>>> the >>>>>> long term, since this method is deprecated in favor of the approach >>>>>> above, and DirAuths may even stop serving the consensus directly >>>>>> by HTTP >>>>>> at some point. >>>>>> >>>>>> This also requires checking the DirAuths' signatures in the >>>>>> consensus >>>>>> document. >>>>>> >>>>>> > Should this be incorporated into the draft? >>>>>> >>>>>> Yes, we support this idea, but also note that, despite parsing and >>>>>> validating an .onion descriptor being relatively straightforward, it >>>>>> involves more code to be maintained. >>>>>> >>>>>> We understand that signed CAA parameters could be accepted directly in >>>>>> an ACME API request without reducing security and the need to process >>>>>> an >>>>>> entire descriptor. >>>>>> >>>>>> -- >>>>>> Silvio Rhatto >>>>>> pronouns he/him >>>>>> _______________________________________________ >>>>>> Acme mailing list >>>>>> Acme@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/acme >>>>>> >>>>> >>> _______________________________________________ >>> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >>
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
