Trusted Credential Inquiry

[KBU2]

I know many of the hundreds of Trusted Credentials that's put in place by the Developers on our Android devices was purely put in place for security reasons, But I'm highly curious on which one's is not totally necessary in some way and not to be trusted as a trusted credential?
Is it possible its a known list of them not to be trusted?
This is just a copy and paste article I found on how these credentials are supposed to work within our devices.




How Certificate Transparency Works
Certificate Transparency adds three new functional components to the current SSL certificate system:

• Certificate logs
• Certificate monitors
• Certificate auditors

These functional components represent discrete software modules that provide supplemental monitoring and auditing services. They are not a replacement for, or an alternative to, the current SSL certificate system. Indeed, these components do not change the fundamental chain-of-trust model that lets clients validate a domain and establish a secure connection with a server. Instead, these components augment the chain-of-trust model by providing support for public oversight and scrutiny of the entire SSL certificate system.
How Log Proofs Work.

Every certificate log must publicly advertise its URL and its public key (among other things). Anyone can interact with a log via HTTPS GET and POST messages.
[paste:font size="5"]How Log Proofs Work.

While log proofs allow an auditor or a monitor to verify that their view of a particular log is consistent with their past views, they also need to verify that their view of a particular log is consistent with other monitors and auditors. To facilitate this verification, auditors and monitors exchange information about logs through a gossip protocol. This asynchronous communication path helps auditors and monitors detect forked logs.
[paste:font size="5"]Typical System Configuration

The Certificate Transparency framework doesn't prescribe any particular configuration or placement of monitors and auditors within the existing SSL certificate system. That said, some configurations are more common than others. In a typical configuration, a CA runs a monitor and a client (browser) runs an auditor (see figure 3). This configuration simplifies the messaging that’s necessary for monitoring and auditing, and it lets certificate authorities and clients develop monitoring and auditing systems that meet the specific needs of their customers and users. Some of the processes that drive this configuration are described below.

Certificate Issuance
A CA obtains an SCT from a log server and incorporates the SCT into the SSL certificate using an X.509v3 extension (for more details on this process, see figure 1). The CA then issues the certificate (with the SCT attached) to the server operator. This method requires no server updates (all servers currently support X.509v3 extensions), and it lets server operators manage their certificates the same way they’ve always managed their SSL certificates.
TLS Handshake
During the TLS handshake, the TLS client receives the SSL certificate and the certificate’s SCT. As usual, the TLS client validates the certificate and its signature chain. In addition, the TLS client validates the log’s signature on the SCT to verify that the SCT was issued by a valid log and that the SCT was actually issued for the certificate (and not some other certificate). If there are discrepancies, the TLS client may reject the certificate. For example, a TLS client would typically reject any certificate whose SCT timestamp is in the future.
Certificate Monitoring
Most monitors will likely be operated by certificate authorities. This configuration lets certificate authorities build efficient monitors that are tailored to their own specific monitoring standards and requirements.
Certificate Auditing
Most auditors will likely be built into browsers. In this configuration, a browser periodically sends a batch of SCTs to its integrated auditing component and asks whether the SCTs (and corresponding certificates) have been legitimately added to a log. The auditor can then asynchronously contact the logs and perform the verification.
Other System Configurations
In addition to the typical configuration described above, where monitors and auditors are tightly integrated with existing TLS/SSL components, Certificate Transparency supports many other configurations. For example, monitors could operate as standalone entities, providing paid or unpaid services to certificate authorities and server operators (see figure 4). A monitor could also be run by a server operator, such as a large Internet entity like Google, Microsoft, or Yahoo. Likewise, an auditor could operate as a standalone service or it could be a secondary function of a monitor.

••••
•••
••
•

 

[KBU2]

----------------------------------------

Google publishes list of Certificate Authorities it doesn't trust
Thawte experiment aims to expose issuers of dodgy creds

By Richard Chirgwin

Posted in Security, 27rd March 2017 04:02 GMT

Google's announced another expansion to the security information offered in its transparency projects: it's now going to track certificates you might not want to trust.

Certificate Authorities (CAs) that your browser (or smartphone) trusts have a suitable entry in “settings”, but if a site presents a certificate from an unknown source, the user is prompted about what to do.

Since users too often click through those warnings, Google's decided that a list of untrusted CAs might be useful to developers and sysadmins.

Mountain View's software engineer, certificate transparency Martin Smith writes that while browser-trusted Certificate Authorities (CAs) are easy to keep track of, there are two classes of CAs that pose a much harder problem.

CAs that have been withdrawn from the trusted list, and new CAs that are on track for inclusion.

“Including these in trusted logs is problematic for several reasons, including uncertainties around revocation policies and the possibility of cross-signing attacks being attempted by malicious third-parties”, Smith writes.

Mountain View has dubbed the new Certificate Transparency log “Submariner”, and hosts it at ct.googleapis.com/submariner. Smith notes that it has the same API as Google's existing CA logs.

The post hints that last year's Symantec certificate SNAFUprovided some of the impetus to create a lookup of untrustworthy certificates. Symantec's subsidiary Thawte.com created a bunch of dodgy certificates for internal use – including one for Google.com – that escaped into the outside world.

Those certificates are included on the don't-trust-this Submariner list: “Initially, Submariner includes certificates chaining up to the set of root certificates that Symantecrecently announced it had discontinued, as well as a collection of additional rootssuggested to us that are pending inclusion in Mozilla”, the post says.

While the log provides “a public record of certificates that are not accepted by the existing Google-operated logs”, the list itself won't be trusted by Chrome. ®