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.

📻 eugene

Oct 20 · 8 weeks ago · 👍 LucasMW

1 Comment

🚀 LucasMW · Oct 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.