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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
