Rework Cert Extensions

[JesusMcCloud]

concerns what we have in the next branch:

We should add another layer, because currently the value of an extension is directly encoded/decoded as part of the extension (oid, critical, and then bare fields representing the contained value), but there is no externally usable representation of that value. I do think it would make sense, though. because it is a repeating pattern.

right now we have this middle ground with odd private constructors and a public constructor that kind of does this. If we add this additional layer, we'd get rid of this odd constructor pattern too, which leads me to think that we should go for it.

@StjepanovicSrdjan @wkornewald what's your take?

[wkornewald]

I'm not yet sure what API you have in mind, but getting rid of the repetition would be nice indeed.

[JesusMcCloud]

Also: I just stumbled over utterly cursed extension being used in production (and accepted for years), that encode critical=false instead of omitting it.

Never should the devices that do that have been released, much less should any x.509 library have ever parsed it and surely not validated certificate chains.

Yet, bouncy castle is extremely lenient and so far, only bouncy castle was ever used to check those chains, so we have a couple of millions devices out there (still in use!) that screw this up and we need to be more lenient.

[JesusMcCloud]

will be much, much smoother, as soon as ASN.1 support for kotlinx serialization is there