💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › t9htgt$s5q$1@gioia.aioe.or… captured on 2023-06-14 at 14:28:18. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-07-16)
-=-=-=-=-=-=-
From: tpt <Rajoduo@yahoo.com>
Subject: Re: Certificate renewal under TOFU?
Date: Wed, 29 Jun 2022 18:10:02 +0200
Message-ID: <t9htgt$s5q$1@gioia.aioe.org>
On 24-Jun-22 12:34, Gustaf Erikson wrote:
Matthew Ernisse <matt@going-flying.com> writes:
> On Tue, 21 Jun 2022 09:44:53 +0200, tpt wrote:
>> On 18-Jun-22 20:24, danrl wrote:
>> Hypothetically speaking, what would be the arguments against using DANE
>> for Gemini? On first glance it seems like a perfect thing for the job.
>
> I don't seem to have the discussion in my mailing list archive but I seem
> to recall that there were those who thought the complexity was too high.
>
> Similar to just getting a real SSL certificate (which I'd argue is trival
> these days), DANE can be complex to setup if you don't already have DNSSEC
> signing going for your zone. I don't believe DNSSEC zone signing is even
> univerally supported by DNS hosts.
I think Let's Encrypt has placed getting a valid SSL cert into a local
minimum. A similar effort would have to be made to simplify DANE.
Speaking as a not-at-all inexperienced amateur sysadmin, DNS is Dark
Magic to me. DANE would have to be at least as turn-key simple as LE to
get me to use it.
/g.
--
A chain is only as strong as its weakest certificate.
Reading more about DANE and DNSSEC it indeed appears to be to
complicated to even consider using in Gemini infrastructure.
But, just as a thought experiment, what about using some simplified form
of certificate validation using DNS that will complement TOFU? Maybe
even only leverage TXT records only. There was a discussion in the
mailing list some time ago about some 'off-connection' way to validate
certificates (that was not like the CA infrastructure we have now on Web)...
Parent:
Start of thread:
Certificate renewal under TOFU? (by danrl <d@x.gl> on Mon, 30 May 2022 03:31:15 -0000 (UTC))