Confused about AllCertificateRecordsReport.csv
Tim Lake
Ryan Dickson
Hi Tim,
Some fields included in the report are described here.
The specific fields referenced in your message are described below:
TLS Capable: Refers to CAs technically capable of issuing TLS certificates given no observed restrictions in doing so based upon EKU values included in its own certificate, or the certificates observed up to and including the corresponding root. If no EKU values are present, the CA’s capability is determined by the union of the trust-bits/EKUs that are on the parent root certificate for each root store that it is included in.
Examples (all framed from the perspective of whether the Intermediate CA (ICA) is “capable"):
if an ICA certificate contains an EKU of id-kp-serverAuth and its issuer (root) contains no EKU - it’s considered “TLS Capable”
if an ICA certificate contains no EKU and its issuer (root) contains no EKU - it’s considered “TLS Capable"
if an ICA certificate contains an EKU of only id-kp-codeSigning and its issuer (root) contains no EKU - it’s not considered “TLS Capable"
if an ICA certificate contains an EKU of id-kp-serverAuth and its issuer (root) contains only an EKU of id-kp-codeSigning - it’s not considered “TLS Capable”
TLS EV Capable: Described here as “EV SSL capable" - generally, the same as above, but additionally considers the presence of an EV capability indicator from at least one root store on the corresponding root’s record.
Code Signing Capable: Same as “TLS Capable" but instead focused on use of the id-kp-codeSigning EKU.
S/MIME Capable: Same as “TLS Capable" but instead focused on the use of the id-kp-emailProtection EKU.
The system logic used to convey the above is a bit more nuanced, but hopefully this allows a general understanding of the intent of these fields.
In the case of the specific certificate you referenced, I believe the possible confusion stems from the fact that it once appeared trusted by Microsoft for Code Signing use cases, but the certificate’s record was later updated with a “Not Before" date of 6/1/2020 for the Code Signing purpose, meaning it’s no longer capable of issuing Code Signing certificates issued after that date.
The IncludedCACertificateReportForMSFT report considers the “all-time" set of EKUs (i.e, to include those EKUs with Not Before flags set) for a given root, where the AllCertificateRecordsCSVFormatV2 report only considers EKUs permitted at the time of report generation (i.e the EKUs corresponding with Not Before dates in the past are not listed).
I’ll respond to your other message, but we’ve created an issue to track documenting the “All Certificate Information (root and intermediate) in CCADB (CSV)” report fields here.
Hope this helps.
Thanks,
Ryan, on behalf of the CCADB Steering Committee
I want to know what the TLS Capable, TLS EV Capable, Code Signing Capable and S/MIME Capable fields in AllCertificateRecordsReport.csv mean? Because I found in https://ccadb.my.salesforce-sites.com/microsoft/IncludedCACertificateReportForMSFT that the root certificate with SHA-256 of EEC5496B988CE98625B934092EEC2908BED0B0F316C2D4730C84EAF1F3D34881 can be Code Signed. But the Code Signing field in AllCertificateRecordsReport.csv is False.Can you help me solve my confusion?
--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CANY-0oegA1WO%3DzDVrS20o%2BEUieWOQrgPhykKzCE_aCJN2s3LFw%40mail.gmail.com.