I see several system certificates that aren't trusted. I don't know what they're used for specifically. It's possible they are used internally for signing configurations or something like that. Since the signing and verifying are occurring on the same computer, a chain of trust isn't useful. (the content isn't originating outside the system, so if it were compromised, being signed or not isn't helpful because the key signing ability is locally available)
The details on the certificates can be a little daunting, but look at their "key usage". The ssh keys you've accepted can "encrypt, verify, wrap". Those are public keys only. But my email key can "Verify, Wrap, Derive", the derive means it can DEcrypt.
I think certificates can only encode and verify, not derive. So the ones you were look at can only encrypt and verify signatures, they cannot sign.
If I had to wager, I'd say that the private key (that can decrypt and sign) is embedded in security apps within the kernel. So the kernel can sign things (such as if it makes a change to a signed component of itself) and other insecure system components can verify it using that certificate.
It could be insecure though. If something modified a kernel module, signed it with its own key, and replaced this untrusted certificate, the module would pass the check. but then every other module in the kernel would fail it, so it would have to re-sign everything under the hood. And if the kernel changed anything and re-signed, that would immediately fail verification too. So although it could be a security problem, it would be difficult to pull off.
