What's the guidance on certificate renewal under TOFU? Let's say my certificate
is valid for 10 more days, naturally I would like to exchange it before it
expires. This will make the client distrust the new certificate.

What's the guidance there?

On 2022-05-30, danrl <d@x.gl> wrote:
> What's the guidance on certificate renewal under TOFU?

If you just want to extend the expiry date, I think the best thing to do
is to sign a new certificate with the *same* keypair. At least some
clients do TOFU based on the public key, rather than the certificate
itself, and probably all should. You can do this using appropriate
openssl commands -- if you can't find the right commands, I can find
them for you.

On Tue, 31 May 2022, mbays@sdf.org wrote:
> [...]
> On 2022-05-30, danrl <d@x.gl> wrote:
>> What's the guidance on certificate renewal under TOFU?
>
> If you just want to extend the expiry date, I think the best thing to do
> is to sign a new certificate with the *same* keypair. At least some
> clients do TOFU based on the public key, rather than the certificate
> itself, and probably all should. You can do this using appropriate
> openssl commands -- if you can't find the right commands, I can find
> them for you.

That sounds like something that should be part of a Gemini FAQ. I had no
idea you could do it and that some clients would check the public key!

I would also recommend to set the expiry date way into the future, like
say 100 years. Renewing the certificate is certainly one of the problems
of relying on TOFU.

On 2022-06-02, reidrac@sdf-eu.org <reidrac@sdf-eu.org> wrote:
> That sounds like something that should be part of a Gemini FAQ.

I can't edit the FAQ, but I did just write up my personal
recommendations and the corresponding openssl commands:
gemini://gemini.thegonz.net/certRecs.gmi

On 2022-06-02, mbays@sdf.org <mbays@sdf.org> wrote:
> gemini://gemini.thegonz.net/certRecs.gmi

This is very helpful. Thank you.

Although long validity times for certs make me uneasy when there is no
revocation lists, which brings us back to either PKI or DANE. Both seem better
suited for the job than TOFU to me. Luckily, we can combine them (somewhat).

On 18-Jun-22 20:24, danrl wrote:
> On 2022-06-02, mbays@sdf.org <mbays@sdf.org> wrote:
>> gemini://gemini.thegonz.net/certRecs.gmi
>
> This is very helpful. Thank you.
>
> Although long validity times for certs make me uneasy when there is no
> revocation lists, which brings us back to either PKI or DANE. Both seem better
> suited for the job than TOFU to me. Luckily, we can combine them (somewhat).

Hypothetically speaking, what would be the arguments against using DANE
for Gemini? On first glance it seems like a perfect thing for the job.

On Tue, 21 Jun 2022 09:44:53 +0200, tpt wrote:
> On 18-Jun-22 20:24, danrl wrote:
>> On 2022-06-02, mbays@sdf.org <mbays@sdf.org> wrote:
>>> gemini://gemini.thegonz.net/certRecs.gmi
>>
>> This is very helpful. Thank you.
>>
>> Although long validity times for certs make me uneasy when there is no
>> revocation lists, which brings us back to either PKI or DANE. Both seem
>> better suited for the job than TOFU to me. Luckily, we can combine them
>> (somewhat).
>
> 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.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

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.

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)...