The Boring Choice Is the Correct One, and It Is Not Where Our Risk Lives

The primitive described below is not in question; our assembly of it has never been reviewed.

What makes a signature scheme trustworthy

Not elegance. Not novelty. Age, deployment and the number of people who have tried to break it.

A scheme carrying twenty years of adversarial attention has been examined by people with careers and grant funding riding on finding something. One published last year has been examined by its authors and a handful of reviewers.

Cryptography is one of the few fields where "widely used and old" is a stronger recommendation than "recently improved."

Why the default here is deliberately unexciting

The signature scheme on our ordinary credentials is the one used by SSH, by modern TLS, by Signal, and by most contemporary chains.

That means fast verification, small signatures, no exotic parameter choices, and implementations in every language somebody might integrate from. It also means that if it breaks, it breaks for a very large fraction of the internet at once, which is a strange kind of comfort and a real one: the incentive to find a problem is enormous and nobody has.

A vendor whose base credential path uses something novel should be asked why. The interesting cryptography belongs where it buys a property you cannot get otherwise, not in the default path.

Where we do use something less scrutinised, and why

The selective-disclosure path with unlinkability uses a different, younger family, because the boring scheme cannot do it. Hiding fields while proving an issuer signed the whole set is not something a conventional signature supports.

So the split is deliberate: conservative by default, adventurous only where the adventure buys a property. That is the right shape, and it is worth checking that a vendor's split runs the same way rather than the reverse.

The part that is actually our risk

The primitive is not the risk. Our assembly of it is.

How our token signing is put together, how key material moves through our services, how our identifier documents encode keys, how our verification code handles malformed input. None of that has been independently reviewed.

That distinction matters because it is where real systems fail. Signature schemes rarely break; the code around them mishandles a key, accepts something it should reject, or encodes a value in a way another implementation cannot read.

We know that last one specifically applies to us, because our identifier documents currently encode key material in a way a conformant resolver cannot decode, which is written up separately and filed. A perfect primitive, assembled wrongly, produces a document that fails to load.

What to ask any vendor about cryptography

"What is your default path, and how old is that primitive?" Old and boring is the right answer for a default.

"Where do you use something newer, and what does it buy?" There should be a property that the conservative option cannot provide. If there is not, the novelty is a cost.

"Has your assembly been reviewed, as distinct from the primitive?" Almost every vendor answers the primitive question when asked this one. For us: no.

"Do you write your own cryptographic implementations?" The correct answer is almost always no, and ours is no.

Where this leaves a decision

If you need reviewed cryptographic engineering, we cannot offer it, and the gap is in our assembly rather than in the primitives we chose.

If you are evaluating choices rather than assurance, the split here is the conservative one: an old, heavily attacked scheme by default, and a younger family only where it buys something the old one cannot do.

The audit status of this implementation

The unlinkability implementation described here is unaudited.