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.
Something like that. Take for example the com.apple.systemdefault certificate in System.keychain. That's created as a self-signed root certificate as part of system installation. Its purpose is to the authoritative certificate for the concept of "this computer". The system uses it to sign/encrypt information that has no use or validity on any other computer in the world.
For a case in point, consider an un-code-signed application that decides to store information in the keychain. By default, that application and no other is allowed to retrieve that information. Some days later, some application goes to the keychain and says "Remember me? I'm the one app gave you that data a few days ago. I'd like it back now, please." How is the keychain to know it's really the same app?
Well, it does that by code-signing the application on the fly the first time it sees it. That means it builds a manifest listing all the components of the application and a message digest for each (MD5 or SHA1). Then it builds a message digest for the manifest, encrypts that digest with a private key, and stores the result in the keychain as the "official" name of the application. Included in the manifest is the "public" part of the certificate used to sign it. (That is, the certificate minus the private key that was actually used to do the encryption.)
When the application wants access again, the keychain finds the manifest, verifies that all the components that are still present have the same digest, all the required components are present, and recomputes the digest of the manifest. It also decrypts the saved signature using the public key from the signing certificate, and verifies that those two digests match.
But which certificate is used to do this validation? Had the application been code-signed, the vendor would have bundled with the application their own certificate (minus its private key) and a precomputed and pre-signed manifest. For applications that haven't been code-signed, the system uses com.apple.systemdefault to build the ad-hoc code signature, and to validate it later.
If anything happens to com.apple.systemdefault, keychain will start bugging the user each time a non-code-signed app tries to use it. As the user individually OKs access for each ap, it'll be signed anew by the new com.apple.systemdefault.
I'm sure there are other uses for this certificate. The ability to authoritatively state "this was done on this machine and nowhere else" is too powerful to have only found one use. ("This machine" really means "this instance of an installation of OS X. The certificate is surely preserved in clones and across software updates, which are arguably the same computer, even if on different hardware running different software. But an erase-and-install produces a "different" computer, even on the same hardware.)
