[tech] signing when rotating (Was: Re: Enhancing TOFU)
nfc at tilde.institute
Wed Mar 10 11:08:48 GMT 2021
On Wed, Mar 10, 2021 at 07:50:32AM +0100, nothien at uber.space wrote:
> 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.
OpenSSH has had host key rotation since March 2015. There's a LWN
article which describes the strategy, https://lwn.net/Articles/637156/
I believe OpenSSH solves the issue you raise here by sending all its
keys to the client. (I'm no expert here. I could be wrong.)
More information about the Gemini