Linux Certificate Authority root stores have a too simple view of 'trust'

Java has used the standard PKCS12 format by default since version 9:

* https://openjdk.org/jeps/229

* https://en.wikipedia.org/wiki/PKCS_12

* https://openjdk.org/projects/jdk9/

Clearly you disagree on the definition of the word “blockchain”. Let's consult Wikipedia, a trustworthy source on anything [1].

> A blockchain is a type of distributed ledger technology (DLT) that consists of growing lists of records, called blocks, that are securely linked together using cryptography. [...] Since each block contains information about the previous block, they effectively form a chain, with each additional block linking to the ones before it. Consequently, blockchain transactions are irreversible in that, once they are recorded, the data in any given block cannot be altered retroactively without altering all subsequent blocks.

So far this is exactly what's going on in the Certificate Transparency scheme.

> Blockchains are typically managed by a peer-to-peer (P2P) computer network for use as a public distributed ledger, where nodes collectively adhere to a consensus algorithm protocol to add and validate new transaction blocks.

This part deviates from CT (no validation is going on in real time, browsers usually just have a few hardcoded CT logs and a custom rule on when a certificate is trusted). But note the word “typically”: this doesn't mean CT can't be called a blockchain just because it doesn't use PoW, PoC or any other consensus algorithms conventional in the cryptocurrency world.

Calling Git a blockchain is arguably more of a stretch because the purpose of keeping the old records intact is not what we use Git for. Maybe you can build blockchain on Git though? (edit: OF COURSE YOU CAN https://github.com/CouleeApps/git-power)

---

[1]: /s

Yeah, this confused me when working with java because some of the tools just silently changed to generating PKCS12 certificates when the same options used to generate their proprietary format.

Java has the exact opposite of a solution to this, though their intentions were very admirable. PKCS#12 is a terrible solution, and Java does it's best to enforce it, and it's move to adopt it further is the exact opposite direction that everyone has been moving in.

What everyone's realized in recent years is that trust is context-dependent, and that you don't want to use the same roots of trust (or trust anchors, or CAs, though each of those terms has a slightly different meaning) everywhere, nor do you want to co-mingle them. It doesn't make sense to have one file that specifies "Here are all the CAs I trust, and here are rules for each of them"; It makes a lot more sense to have configuration per use-case of "Here are all the CAs for this usecase", and to rely much more on code within the program to disambigutate. Having one file with all those CA certificates and your private keys is... Backwards. Keytool and their custom format at least kept a clear distinction between "these are my private keys" and "these are keys I trust". PKCS#12 has no such distinction, and the tooling around it (Particularly Java's!) makes it hard to disambiguate safebags, so you're left with one giant mess.

It's actually the same problem as Global Variables[1]; Security and trust isn't one object. It's many. One program may act as itself to many providers, but it might also act as three or four different roles within it's scope to the same provider.

[1] https://dl.acm.org/doi/10.1145/953353.953355

There's been a ton of discussion on what constitutes "Trust" in the modern web world of late, but very little of it seems to have borne fruit. One minor advance Kubernetes formally adopting a proposal for a trust anchor[1][2]; Which is to say, a set of CAs that are equivalent.

Someone mentioned earlier that "At least we all agree that they're PEM and DER Formatted", to which someone mentioned that Java had it's own world, and ugh... That's a whole thing. Java has moved backwards in recent years; Their old Keystore format was useful for a single context, in that you could say "Here's the keystore for communicating with Google, it's got a list of public keys to trust and list of private keys that we are"; And that more or less worked with the tooling. The move to PKCS#12 moves to one unified bag with all your private and public keys mixed in and you have to specify which are which, which is theoretically better but in practice represents a configuration nightmare over just specifying separate files with the trusted CAs, our public keys, and our private keys. You still can't deliver a single PKCS12 file to all of your servers as a whole, because SafeBags aren't; They're DES encrypted, which is to say: Not at all[3], but at least it's clear that they aren't.

The right answer is basically what Cloudflare[4] and then Google Cloud[5] tried to do and failed: Create a single file-format for "Public Key and accompanying Private Key", and make it easy to extract the public key from many of those to form a list of CAs.

[1] https://github.com/kubernetes/enhancements/pull/3258 [2] https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ [3] The actual Java recommendation is to use a single well-know DES key for all PKCS12 operations, which obviates all of the stated and even best-case-steelman arguments for why Java made this change, to the point that anyone defending the decision should probably not be trusted and the proposers were more likely malicious than stupid. That's a rant for a different post. [4] https://github.com/cloudflare/cfssl [5] https://cloud.google.com/docs/authentication/application-def...