1815933 - Make Derived Trust Bits and EV-Enabled logic match crt.sh

Status: NEW

(CA Program :: Common CA Database, task, P3)

Description

[Kathleen Wilson]

The current logic in the CCADB for determining the Derived Trust Bits and EV-enabled values for an intermediate certificate is incomplete, as it does not take all considerations into account like crt.sh does.

One example is Bug #1815355, which I only noticed because I was looking at crt.sh data. It would be better if the values in CCADB matached those of crt.sh (even for the complex scenarios) so that the CA Task lists will contain correct information to notify of problems caused by cross-signings and missing audit statements.

The crt.sh code is all published at https://github.com/crtsh under GPLv3, so it'll be fine for us to use that logic. Though the code will all be different because the crt.sh code is postgres stored procedures that access tables on the crt.sh database, while the CCADB code will be within Salesforce and use the Salesforce data.

From Rob:
https://github.com/crtsh/certwatch_db/blob/master/fnc/determine_ca_trust_purposes.fnc is the main bit of code. It currently runs every 10 minutes on the primary crt.sh database. As input it takes the trust settings of each root certificate in each root program (which are stored on the "root_trust_purpose" table), and as output it updates another table ("ca_trust_purpose") that holds the derived trust settings for each CA(*) in the context of each root program.

(*) "each CA": crt.sh's considers all CA certificates that share the same Subject Name and Public Key to belong to the same CA. This is directly equivalent to multiple CCADB records that share the same "Subject + SPKI SHA256" value.