> > One further issue I've noticed is that CP/CPS policy document URLs from > Root Certificate records currently appear in the "Certificate Practice > Statement (CPS) URL" field in the CSV file rather than the "Certificate > Practice & Policy Statement" field. But perhaps your "larger policy > document related enhancement separately in the future" already plans to > address this?
Correct on both accounts. This issue (which existed before the recent update) was one of the drivers for creating the new fields and we expect the upcoming enhancement to resolve it. On Thu, Sep 26, 2024 at 10:57 AM Rob Stradling <r...@sectigo.com> wrote: > Hi Chris. Thanks for the quick action! > > I've implemented corresponding updates to the code that produces crt.sh's > CCADB disclosure pages. There are now fewer false positives! 🙂 > > One further issue I've noticed is that CP/CPS policy document URLs from > Root Certificate records currently appear in the "Certificate Practice > Statement (CPS) URL" field in the CSV file rather than the "Certificate > Practice & Policy Statement" field. But perhaps your "larger policy > document related enhancement separately in the future" already plans to > address this? > > ------------------------------ > *From:* Chris Clements <ccleme...@google.com> > *Sent:* 25 September 2024 20:07 > *To:* Rob Stradling <r...@sectigo.com> > *Cc:* Ben Wilson <bwil...@mozilla.com>; public <public@ccadb.org>; Clint > Wilson <cli...@apple.com>; Mike Shaver <mike.sha...@gmail.com>; Dimitris > Zacharopoulos (HARICA) <dzach...@harica.gr> > *Subject:* Re: Questions regarding which policy documentation to keep in > CCADB > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > CCADB records that formerly had "CP/CPS Same as Parent" ticked now have > "CP Same As Parent" and "CPS Same As Parent" ticked but, crucially, "CP/CPS > Same As Parent" has been *unticked*. > > > These values have been restored. > > Please append the following fields to AllCertificateRecordsCSVFormatv2 as > soon as possible: > "CP Same As Parent" > "CPS Same As Parent" > "CP Last Updated" > "CPS Last Updated" > > > These have been appended to the AllCertificateRecordsCSVFormatv2 report. > We've also appended the "Certificate Practice & Policy Statement" field, > which can be used in the future to describe the location of a combined > CP/CPS. > > We'll plan to convey the larger policy document related enhancement > separately in the future, but hopefully restoring the "CP/CPS Same as > Parent" values and appending the report resolves the crt.sh "incomplete > disclosure" tracking issue. Thanks again, Rob! > > On Wed, Sep 25, 2024 at 11:38 AM Chris Clements <ccleme...@google.com> > wrote: > > Thanks for calling attention to these two issues Rob. We'll investigate > and respond. > > -Chris > > On Wed, Sep 25, 2024 at 5:11 AM Rob Stradling <r...@sectigo.com> wrote: > > > Please add those fields to > https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatv2 > too. > > Just chasing up on this... > > CCADB records that formerly had "CP/CPS Same as Parent" ticked now have > "CP Same As Parent" and "CPS Same As Parent" ticked but, crucially, "CP/CPS > Same As Parent" has been *unticked*. > > AllCertificateRecordsCSVFormatv2 still only includes the "CP/CPS Same As > Parent" field, which has been set to "false" for almost all Intermediate > Certificate records. Consequently, crt.sh's "incomplete disclosure" > tracking (e.g., > https://crt.sh/mozilla-disclosures#disclosureincompletesummary) has gone > haywire, false positively flagging nearly every intermediate certificate. > > Please append the following fields to AllCertificateRecordsCSVFormatv2 as > soon as possible: > > - "CP Same As Parent" > - "CPS Same As Parent" > - "CP Last Updated" > - "CPS Last Updated" > > Thanks! > > ------------------------------ > *From:* 'Rob Stradling' via CCADB Public <public@ccadb.org> > *Sent:* 20 September 2024 16:33 > *To:* Ben Wilson <bwil...@mozilla.com> > *Cc:* public <public@ccadb.org>; Clint Wilson <cli...@apple.com>; Mike > Shaver <mike.sha...@gmail.com>; Chris Clements <ccleme...@google.com>; > Dimitris Zacharopoulos (HARICA) <dzach...@harica.gr> > *Subject:* Re: Questions regarding which policy documentation to keep in > CCADB > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > Great. That works. Thanks Ben. > > Please add those fields to > https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatv2 > too. > > ------------------------------ > *From:* 'Ben Wilson' via CCADB Public <public@ccadb.org> > *Sent:* 20 September 2024 15:47 > *To:* Rob Stradling <r...@sectigo.com> > *Cc:* public <public@ccadb.org>; Clint Wilson <cli...@apple.com>; Mike > Shaver <mike.sha...@gmail.com>; Chris Clements <ccleme...@google.com>; > Dimitris Zacharopoulos (HARICA) <dzach...@harica.gr> > *Subject:* Re: Questions regarding which policy documentation to keep in > CCADB > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > Hi Rob, > There will be three fields for "Last Updated Date" --one for CP, one for > CPS, and one for CP/CPS. > Ben > > On Fri, Sep 20, 2024 at 3:24 AM 'Rob Stradling' via CCADB Public < > public@ccadb.org> wrote: > > Thanks Clint, Chris et al. > > > On the Intermediate Certificate record, we will add the ability to > identify if the CP, CPS, or CP/CPS is the same as the parent record, rather > than only having the ability to identify “CP/CPS same as parent”, which is > today’s current state in the CCADB. > > Please could you also reflect this enhancement in > https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatv2 > somehow? > > One further thought... > How are CA Owners expected to populate the single "CP/CPS Last Updated > Date" field on an Intermediate Certificate record when multiple > non-superseded policy documents are applicable, each of which could have > been updated on different dates? > Should "Last Updated Date" become a per-document field instead? > > ------------------------------ > *From:* 'Clint Wilson' via CCADB Public > *Sent:* Thursday, September 19, 2024 23:24 > *To:* public > *Cc:* Mike Shaver; Chris Clements; Dimitris Zacharopoulos (HARICA); Clint > Wilson > *Subject:* Re: Questions regarding which policy documentation to keep in > CCADB > > Hi All, > > The CCADB Steering Committee plans to move forward with introducing the > changes described below by Chris [1] into the production instance of the > CCADB. There are semi-related future enhancements we hope to make beyond > the scope of these near-term changes that we expect will further address > areas of inconsistency, confusion, and/or transparency that are currently > lacking. For now, if there are any final points of feedback folks would > like to make, please do so as soon as possible. > > Thank you! > -Clint > > [1] - > https://groups.google.com/a/ccadb.org/g/public/c/CIR6vB52Z-g/m/91ZZ3e9vCgAJ > > On Sep 6, 2024, at 2:01 PM, 'Clint Wilson' via CCADB Public < > public@ccadb.org> wrote: > > In the context of the TLS and S/MIME Baseline Requirements, the cPSuri is > not required to point to the specific document(s) which govern the > certificate in which it may be found. The requirement is only that the > cPSuri contain a "HTTP or HTTPS URL for the Issuing CA's Certificate > Policies, Certification Practice Statement, Relying Party Agreement, or > other pointer to online policy information provided by the Issuing CA”. > > As far as I understand, CA/B Forum Guideline documents don’t require CAs > to maintain availability of CPs/CPSes which are not currently authoritative > for the issuance of new certificates. Root Programs do require maintenance > of such an archive [1] and the CCADB’s (alongside incorporating Root > Program Policies') requirement for disclosure of all CPs/CPSes [2] > effectively creates a secondary, consistently structured source of this > archive. In theory (and often in practice), the cPSuri should at minimum > point to a repository containing the archive of active and historical (but > still authoritative) CPs/CPSes, but it may be a substantial amount of > effort to identify the document(s) governing any given leaf certificate. > Part of the intent with the CCADB storing the effective date, and > superseded date in the future, is to make it a little bit easier for > relying and interested parties to find and validate that information — > hopefully improving the overall situation your (not naive, imo) question > highlights. > > It’s also worth pointing out that including the cPSuri is not recommended > and generally provides very little practical value. That could be changed > and improved, but given the current direction of managing CAs and their > policies at scale, I suspect such efforts may not be exceptionally fruitful. > > Cheers, > -Clint > > [1] - > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses > [2] - https://www.ccadb.org/policy#5-policies-audits-and-practices > > On Sep 5, 2024, at 12:45 PM, Mike Shaver <mike.sha...@gmail.com> wrote: > > On Thu, Sep 5, 2024 at 3:23 PM 'Chris Clements' via CCADB Public < > public@ccadb.org> wrote: > > Currently, we see some CA Owners using a URL with a specific version of > the document and others using a URL that points to where the latest version > of the document can be found. Both are acceptable. The POLICY DOCUMENTS > guide > <https://docs.google.com/document/d/1qAVihgbo7TuH3xqq2zbxhxHajQnJwbHUGEFf2VjxoZQ/edit#bookmark=id.gqczpewy5797> > states: > "If the link to your CA’s most current policy document remains constant, > then you can simply edit the document object to update the date, add policy > identifiers, update comments, and update the list of applicable root > certificates." > > > Naive question: if a policy document can change without the URL changing, > how does one find the policy under which a given certificate was issued? > Doesn't cpsUri have to point to the policy that governed the issuance of > the certificate? > > Mike > > > -- > 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+unsubscr...@ccadb.org. > To view this discussion on the web visit > https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZquKwxKpJDfii7_ixs_zpZRqho9iuBp5-r9s_pgbLU9H2w%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZquKwxKpJDfii7_ixs_zpZRqho9iuBp5-r9s_pgbLU9H2w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > > -- > 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+unsubscr...@ccadb.org. > To view this discussion on the web visit > https://groups.google.com/a/ccadb.org/d/msgid/public/9C03D8B5-C6E1-4AA6-9BFF-471E33E4D119%40apple.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/9C03D8B5-C6E1-4AA6-9BFF-471E33E4D119%40apple.com?utm_medium=email&utm_source=footer> > . > > > -- > 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+unsubscr...@ccadb.org. > To view this discussion on the web visit > https://groups.google.com/a/ccadb.org/d/msgid/public/067DEA69-2F04-4C52-B771-A2706FF8525E%40apple.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/067DEA69-2F04-4C52-B771-A2706FF8525E%40apple.com?utm_medium=email&utm_source=footer> > . > -- > 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+unsubscr...@ccadb.org. > To view this discussion on the web visit > https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB4729B42F59C16FEA6D600DF9AA6C2%40MW4PR17MB4729.namprd17.prod.outlook.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB4729B42F59C16FEA6D600DF9AA6C2%40MW4PR17MB4729.namprd17.prod.outlook.com?utm_medium=email&utm_source=footer> > . > > -- > 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+unsubscr...@ccadb.org. > To view this discussion on the web visit > https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaap37DuZfUFJAPzr96tEKK578NdvdeDUMnq%2BvMOyH99cg%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaap37DuZfUFJAPzr96tEKK578NdvdeDUMnq%2BvMOyH99cg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- > 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+unsubscr...@ccadb.org. > To view this discussion on the web visit > https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB472974C25744C4D3260C142CAA6C2%40MW4PR17MB4729.namprd17.prod.outlook.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB472974C25744C4D3260C142CAA6C2%40MW4PR17MB4729.namprd17.prod.outlook.com?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@ccadb.org. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mDqsssOdXjbsN3ejchD7OzmjWMXqiHRuRMq7Gs%3DLQmoDA%40mail.gmail.com.
