On Wed, Aug 7, 2019 at 6:28 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I have been working towards extending Audit Letter Validation (ALV) to > intermediate certificate records in the CCADB. This is involving some > changes. > > I added a field to intermediate cert records called 'Subordinate CA > Owner', with help text: "If this certificate does not have the same > audit statements as its parent certificate, then enter the name of the > subordinate CA as it appears in its audit statements." > > I will appreciate input on how to make that more clear. > Thanks for doing this, Kathleen! As we saw from the discussions related to the recent crt.sh changes, it seems some CAs have taken an interesting approach to audits - namely, that the same certificate is included in multiple audits, but with different scopes. That is, within one audit, the inclusion is limited to the scope of issuance, while in another audit, its inclusion is within the scope of the actual operation (e.g. key protection, validation, etc). Thus, the proposed language seems like it'll suffer from the same ambiguity that has tripped up CAs. Note that there's also some confusion, it seems, as it applies to root certificates - particularly those in which a third-party organization performs all the relevant activities. "List all organizations as they appear on audit statements that include this certificate in scope. If both control of the private key and domain, IP, and email validation activities are only performed by the organization listed on the audit statement of the parent certificate, this may be left blank." I mean, it's much wordier, for sure, but I'm wondering how well that precision resonates. The reason I phrased it like this is that I believe we've seen suggestion that a multiple organizations may control access to a given private key - for example, the organization that physically operates the infrastructure, and the organization with administrative access to the machines and configuration. In that case, this would list both organizations. I admit, I'm somewhat concerned by the interpretation that some CAs have offered, but it sounds like yet more opportunities to dive into the messy world of audits and scoping :) I suspect that, in the future, a way we can resolve this forcing CAs to disclose which portions of the audit were in scope, if they're included - or even prohibiting the interpretation seen and requiring separate audits for scope-limitation (i.e. for certificates in which the only thing in scope was "issuance", and not all of the other activities listed on the organization's audit) If you wanted to get really precise, it would be the enumeration of all organizations involved in the performance of the activities listed in the Baseline Requirements. My issue there is that would pick up not only RAs, but also potentially ISPs (used to serve OCSP/CRLs) and CDNs, which today are functionally excluded. "When an intermediate certificate record in the CCADB corresponds to a certificate which has an audit for the operational and issuance activities that names an organization different than the organization named in the audit statement of the parent record in CCADB, then fill in the 'Subordinate CA Owner' field to indicate the name of the organization as it appears in the intermediate certificate's operational audit." Again, messy as all get out. But maybe it'll spark ideas on how to trim that down or clarify > > I believe there is now a trigger that will require this field to be > filled in when audit statements are added or updated in an intermediate > cert record. > > I also plan to add a CA task list item to CAs home page called: > "Provide ‘Subordinate CA Owner’ and ‘Auditor’ for Intermediate Certs > with their own Audit Statements" > with Instructions: "When an intermediate certificate record in the CCADB > corresponds to a certificate that has different audit statements than > the parent record in the CCADB, then fill in the ‘Subordinate CA Owner’ > field to enter the name of the CA as it appears in its audit statements. > Also fill in the Auditor name as it appears in the audit statements." > > Again, I'm open to suggestions about how to make this more clear. > > Regarding these reports > > > https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits > > > https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAuditsCSV > I plan to add a "Subordinate CA Owner" column, and change the name of > the current "CA Owner" column to "Parent CA Owner". > > There is now a "Derived Trust Bits" field in the "Certificate Data > [Fields NOT editable; extracted from PEM]" section. This is used to > determine which audit statements the intermediate cert needs (e.g. if > ServerAuth, then need BR audit) > Very high level logic: If the cert has EKU in it, then that will be > used. Otherwise see which root store it's parent root cert is in. If in > both Mozilla and Microsoft then create union of the trust bits that the > parent/root cert is trusted for. > > When "Audits Same as Parent" is checked, CCADB will look up the parent > chain until audit statements are found. When "Audits Same as Parent" is > not checked, then CCADB will just pass the audit statements in the > intermediate cert record into Audit Letter Validation (ALV). > > There are some ALV status/results fields and a 'Date ALV Processed' > field that are currently only visible to root store operators, as we > continue to test/debug. I hope to make these fields visible to CAs soon. > Of course, eventually (after things are working enough) I plan to > provide public-facing reports with the information. > > We are working on a process that will run nightly to update ALV results > on intermediate cert records when new audit statements are provided. > > Thanks, > Kathleen > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
