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
