[tech] signing when rotating (Was: Re: Enhancing TOFU)

nothien at uber.space nothien at uber.space
Wed Mar 10 06:50:32 GMT 2021

mbays <mbays at sdf.org> wrote:
> But there's a much simpler version which avoids chains.
> If your server is currently using certificate A and you want to switch 
> to a new certificate:
> * create a new self-signed certificate C with key K,
> * sign it with A to produce a signed certificate S,
>      (e.g. using openssl x509 -CA A.crt ...)
> * tell your server to use S and K.
> So why don't we make this a convention? Any subtleties I'm missing?

The big issue with this is, what if a client misses a certificate
update?  If the server's first cert is A (self-signed because it has no
previous certs), second cert is B (signed with A) and third cert is C
(signed with B).  If a client connects to the server when it is using A,
they will save A, which works fine.  But if they then don't connect to
the server for a while, and the server now uses C, then there is no
direct trust from A to C (unless you provide the entire B cert during
the verification, which is just cert chains all over again), and the
client cannot verify the server.

One solution to this is what I had originally proposed on this thread:
get 'trust servers' to periodically check in on servers (either using my
original /.pubkey based idea or checking if the server cert is signed
with the previous one), and to share lists of verified servers with
clients.  This /still/ doesn't solve the issue where a server's cert is

~aravk | ~nothien

More information about the Gemini mailing list