Thanks, Kathleen. Snipped the other changes (which sound good), and a few replies inline below.
On Thu, Oct 31, 2019 at 4:39 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > >> 2. Full name of the CA that was audited; > >> 3. SHA-256 fingerprint of each root and intermediate certificate that > >> was in scope of the audit (see format specifications below); > >> > > > > Microsoft policy actually requires the disclosure of the full hierarchy > > (c.f. > > > https://docs.microsoft.com/en-us/security/trusted-root/program-requirements > > 3.4) > > > > This may help, or harm, the approach used with ALV. There is benefit in > > disclosing what is known-and-out-of-scope, but this may cause ALV to > > believe that it was in-scope. I've seen CAs disclose explicitly what's > out > > of scope (e.g. Amazon), and I find this hugely valuable. You can see the > > proposed wording from the BR is actually more explicit: > > > > """the full PKI hierarchy of all certificates that are capable of being > > used to issue new certificates, identified by Distinguished Name and the > > SHA-256 fingerprint of each and every certificate, and including all > Roots, > > Subordinate CA Certificates, and Cross Certificates, clearly identifying > > which were certificates (and associated keys) were in-scope and > > out-of-scope of the audit;""" > > > I will have to look into this. For example, does Microsoft's policy say > that the full CA hierarchy must be disclosed in the audit statement? Or > does their policy just mean that the full CA hierarchy must be disclosed > to Microsoft, which does not necessarily mean public disclosure, and > does not necessarily mean via the audit statement. > > Also, I believe that ALV assumes that the SHA-256 fingerprints found in > audit statements are for certs that were in scope of the audit. So the > approach of also listing the SHA-256 fingerprints of certs that were not > in scope might break ALV. > > So, it may turn out that we need another requirement saying that SHA-256 > fingerprints for certs not in scope of the audit must not be in the > audit statement. > It's unclear Microsoft's position here. https://docs.microsoft.com/en-us/security/trusted-root/audit-requirements B indicates that the CA MUST include the entire hierarchy /in/ the scope of the audit, so it seems the answer is "Yes", but that's not entirely followed. The WebTrust Illustrative Guidance provides guidance on how to do this (e.g. for the non-performance of activities). The reason I highlight this is that it significantly reduces the ambiguities that we're seeing with Intermediate ALV and the questionable reissuance of reports, and/or CA-defined AUP for retroactive reports. Forcing the disclosure of the explicit scope - and the consideration - resolves the ambiguity that we presently see, which is "Was it in scope, and the auditor looked and forgot to say this, or was it out of scope, and the auditor never looked" > > Any expectations on authoritative English version? Is that to be left to > > root policy? > > Just before the list it says: "must contain at least the following > clearly-labelled information in English:" > > Do you think it's necessary to say authoritative? > "An authoritative English language version of the publicly-available > audit information MUST be supplied by the Auditor." > That's a fair question. We've seen some reports provided where it is provided by a translator independent from the auditor, and that certainly calls into question the authoritativeness of the audit - e.g. if the translator mistranslates a phrase, it could affect the level of assurance and reliance placed upon that audit. Similarly, we've seen audit reports (along with CP/CPSes) in which they say that the local-language version controls, and the English version is merely informative. So I'm not fully convinced it needs to say authoritative, but that's the set of scenarios we've seen in the past that are useful to consider. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
