@fdroidorg I checked it for fdroid and saw it on 30, so it's much behind, which is what the article is referencing to.

I did not expect fdroid basic to be further, so I didn't bother to check.

So I am *not* the last being on the planet this perverse.

You are the kind of person that can imagine what my brain went through in this one passage of Devil May Cry. where there is a gate control containing "three openings to insert something". My brain went just on its own "It's like a woman."

Collecting more input on EKU (Extended Key Usage). While there are several proprietary extensions, the more logical source of EKUs is OID (1.3.6.1.5.5.7.3)

That defines 44 EKUs, of which 5 are declared to be obsolete. Now for browser communication, Google wants to reduce that list to the first entry only, id-kp-serverAuth. Any other EKU in a cert means no trust by Chrome in future.

iana.org/assignments/smi-numbe…

And now for the coop part. First the definition I use, because that is important:

"A cooperative is an autonomous association of persons united to meet common economic, social, and cultural goals. They achieve their objectives through a jointly-owned and democratically-controlled enterprise."

[1]OK. With that out of the way, let's see what this means for the CA idea behind nerdcert.

[1] single-market-economy.ec.europ…

Cooperatives

Defining characteristics of cooperatives and why they are important, European Commission initiatives, and supporting information.

^{Internal Market, Industry, Entrepreneurship and SMEs}

There are a lot of interesting terms in the definition. It is an autonomous association (jointly-owned, not by a single person or investor) of persons (not companies) with a defined (set of) goals, a coop however acts as an enterprise (so doesn't have to be a non-profit) and is democratically controlled (transparent by definition).

This makes a coop a better fit than a foundation. In a coop people focus on building solutions, not on managing a foundation, which is a very different skillset.

For an idea/project like nerdcert, but also more general for open source projects, the coop reflects in its construction the values I hope it can represent.

But there is a bigger advantage. The jointly-owned means that you have to create a trusted registry for owners/members. That you have to manage the money they owe the coop.

So, by accident, more or less, you have to solve the same problem for the coop that you need to solve for running a CA/PKI: KYC — Know Your Customer.

It's only a problem when being accepted in the root pool is your goal ;) This whole idea started because Google has decided to un-trust all root CAs that allow more than just the authServer EKU in certificates from mid next year on. Becoming included in that club is definitely not the goal.

The consensus in the CA/PKI world seems to be anyway that for anything but browser acceptance, a private CA is the better and preferred approach. A cooperative approach to that — that's my idea.

Here's my logic (which might be flawed, that's why I share in the open):

- For web/mail server certificates letsencrypt exists and works just fine.

- For M2M, mTLS, device certificates having more EKUs that just authServer makes a lot of sense

- Consensus in the industry is that for those use cases you should run a private CA/PKI

- That's however a big ask for many projects/groups out there

- So why not build that as a service, as a coop?

HTH (Hope This Helps)

Can be good.... but...
A cert is mostly meaningless (untrusted) if you do not trust the CA that signed it, as then anyone could make a CA and cert and claim to be a given host.

DANE TSLA circumvents that problem by putting the "CA trust" into DNS/DNSSEC (which is not a bad way IMHO, but requires participants to use/support that...);

thus either everyone needs to trust the new CA or everyone support DANE; egg meet a hard problem (distros could sneak in a new CA)

There is a (sorta) Euro Let's Encrypt, BuyPass Go (something I use for my XMPP and other random bits) works fine, and is just a small config tweak, Yes they are a commercial CA, but they are European, and not Let's Encrypt (they don't do wildcards though), and they have a commercial purpose overall, I am ultimately fine with this, your mileage may vary

(no hate to Lets Encrypt, they are lovely people, but I do worry about their scale compared to the rest of the CA ecosystem)

Buypass Go SSL - Gratis TLS/SSL-sertifikat

Leveres fra norske Buypass, basert på ACME-standarden. Gratis, automatisk fornyelse.

^Buypass.com

I mean sure, but does this actually matter? (outside of XMPP I guess that actually does use client auth)

The SMTP argument that everyone is bringing up doesn't seem to be the default configuration deployed at scale. It sucks that full CA trusted client auth is going to be a little more tricky, but I generally prefer when the complaining not just defending weird non standard configs

also it’s not that hard to override the certificate checking in most libraries to accept certs with just serverAuth.

Heck the RFC definition of id-kp-serverAuth and id-kp-clientAuth is so vague that arguably using id-kp-clientAuth for this was always wrong