💾 Archived View for bbs.geminispace.org › u › zzo38 › 21546 captured on 2024-12-17 at 15:10:18. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Superseding X.509 certificates

I had a idea of a X.509 extension for superseding self-signed X.509 certificates, so that it can be used with TOFU (including with Gemini). There are many reasons why you might want to change a certificate, including because the old one will expire soon, or because your name or country has changed, or if you wish to change an extension, or use a better type of key or signature than you had before.

Currently, the extension contains:

An optional public key which will be used to sign any certificates that supersede this one in the superseding extension of the new certificate. If not specified, the current certificate's key is used. (This is intended to allow the corresponding private key to be stored separately in a more secure way than the private key used with TLS.)
The list of excluded extensions. This may be necessary in case of future extensions that would interfere, in case those extensions also contain signatures. For the purpose of calculating the superseding signatures, the data of the excluded extensions, as well as the signatures within this extension, will have all of their bits cleared.
The hash algorithm to use. (One hash algorithm should be recommended, and then in future it can be changed if the existing one is considered to be no good.)
The sequence of Superseding Items, each of which has the hash of the old certificate and the signature of the new certificate with the old certificate's key. (The reason you might have more than one is in case the certificate changed twice without seeing all of the changes.)

However, there are some difficulty with it, such as that it must contain a signature of itself, which can sometimes be difficult to implement.

So, now I have a different idea of how to do it. The subject certificate will not be self-signed, but there will be a issuer certificate. Every time the subject certificate changes, there will be a new issuer certificate too. The superseding extension in the issuer certificate contains the signatures of the new subject certificate using the keys of the older issuer certificates. This makes the first two things I listed above in the existing format, to be unnecessary, since the issuer key is used and interference won't occur.

🦂 zzo38

Nov 05 · 6 weeks ago · 👍 LooseCannon

2 Comments ↓

🦋 CarloMonte · Nov 05 at 06:38:

Is your requirement the easy replacement of a TOFU certificate? Which one (client or server)?

Did you ask your favourite AI about "methods for replacing TOFU certificates" and "the dangers of home brew PKI schemes"? Then: did you evaluate existing methods?

It is of course doable (the Gemini protocol itself is an example), but the bar is quite high.

🦂 zzo38 [OP] · Nov 05 at 20:11:

This could be used with both server certificates and client certificates (it is also independent of the protocol). I did not ask any AI (I do not have access to them). I did look for existing methods, and they do not seem sufficient, to me.

There is another thing that I had also considered, which is separate and not a part of this (but can be used together), to implement something like "web of trust" using a separate file, to allow anyone to sign someone's certificates and include details (e.g. which extensions are understood, levels of trust, etc). I think this separate thing is a different issue, so is handled separately.