Tree identity
So I had a random idea, and hopefully, someone more knowledgeable in the internals of x509 and related technologies can chime in.
When, say, Lagrange encounters a page requesting a client certificate, it offers you an option to generate a certificate explicitly for this particular server. The certificate remains entirely disconnected from any other certificate you might be using. Which is both a good thing, as it ensures privacy, and a not so good thing, as it prevents you, yourself, from later proving to anyone else that these two certificates are one and the same, if it should so suit you. Or rather, the option is sort of there, but requires complicated dances.
There might be other advantages to using per-site certificates as a general practice, but all those hypotherical complicated dances make it unwieldy.
But if you could embed a signature into the certificate structure somewhere, that would allow someone to verify that you, the owner of certificate X, have also issued this certificate Y, without also revealing the identity of certificate X until such a verification is needed, wouldn't that be useful?
I'm not sure just how can this be done, however. Something in an extension field? Been a while since I messed with x509 myself and I obviously forgot everything I could about it.
Moreover, I can imagine situations where multi-level chains or entire trees of such identity structures will make sense... And potentially it could be something simple enough to hack into existing Gemini servers.
2025-10-20 · 7 months ago · 👍 LucasMW
8 Comments ↓
🚀 LucasMW · 2025-10-20 at 13:25:
Someone could in thesis setup a capsule which could allow users to "upload" their "public key" and tie with that capsule's certificate in case they wanted to prove they are the same.
It is a centralized solution, yes, but I think it works for this.
I would guess that privacy as default is better. People want to confirm themselves should do the extra step.
we can sign any files, right? like we send a signature with an email, we can send a signature of the certificate as well? there can be a link somewhere, after you already logged in, that suggests you to upload the presented certificate's signature.
📻 eugene [OP] · Mar 30 at 17:27:
Theoretically, unless someone's user cert generator is braindead (things happen) it can be used to sign an arbitrary bytestream. I even wrote a program that did just that a few years ago for a use completely unrelated to Gemini. But the idea was to embed that information directly inside the individual user certs generated for use with specific sites, which is a rather different ball of wax...
I need to meditate on the whole thing more, what I was initially thinking of is either spectacularly unnecessary, impossible, or actually trivial, and I'm not sure which. :)
IIUC, that’s exactly what certificate issuing is. If the user trusts the end certificate, fine. If they want to verify the issuer, they can walk up the certificate chain. And you can provide the signer certificate via (i) a central CA/RA (ii) DNS (iii) yourself during TLS.
📻 eugene [OP] · Apr 02 at 08:20:
@sy
Yes, there's the CA and potential multiple levels thereof, but here's a thing: The moment you reveal a CA claiming that it is "you", you also automatically reveal that all certificates one previously encountered signed by this CA are also "you" -- whereas you might only want to prove that *one* of them is you, but leave the rest of them anonymous...
The issuer CA may be yourself with a self-signed CA certificate – not necessarily an established CA company. And the verifiers will arrive at that CA certificate only via the chain of certificates that they are trying to verify. They won’t see all the certificates that you, as a CA, have issued.
📻 eugene [OP] · Apr 02 at 12:15:
They will, however, be able to identify any two certificates they happen to have as being signed by the same CA, and will be able to do this for any certificates they encounter later that are signed by the same CA. I.e. the moment we give up the CA to be verified, we don't just depseudonymize a certain pair of certificates, but every possible pair that the one we want to prove identity to ever had access to, or, unless that's where we drop the CA, *will* have access to in the future.
I can imagine how this could be undesirable.
I thought *that* was what you meant by saying ‘tree’. You can have separate CA trees if that’s not what you want. Or if you want the ability to reveal the connection later, you would not publish the real root certificate and use the certificates issued by it as if they were separate roots.