On Saturday, November 7, 2020 at 10:36:58 AM UTC-6, Ryan Sleevi wrote: > On Sat, Nov 7, 2020 at 9:21 AM Jeff Ward via dev-security-policy < > dev-secur...@lists.mozilla.org> wrote: > > > Sure Ryan, the answer is quite simple. When I used the word "public" in > > my post, I should have been more clear as to the nuance of this concept. > > Public reports by definition are generally distributed (available to > > anyone). When reports are restricted in distribution and only intended for > > a certain user or users as specified in the report, they are no longer > > public. In each of the EY examples you reference, they all state in the > > last paragraph before the EY signature, "This report is intended solely for > > the information and use of GPO-CA and the Federal PKI Policy Authority and > > is not intended to be, and should not be, used by anyone other than GPO-CA > > and the Federal PKI Policy Authority." When reports are not generally > > distributed and available to the general public, the specifics of > > individuals performing the audit will not be present. When my firm issues > > reports for FPKI, we also provide the listing of individuals in a letter > > that is not public information. > > > Thanks Jeff, > > This is useful for confirming that there is a clearly viable path forward > here. As you know, I appreciate the nuance here regarding public reporting, > as well as reports that are restricted in distribution but still made > public (e.g. as part of a regulatory function, such as the OIG in this > case). I think we agree in the substance: that this is possible, and are > merely working out the details here with regards to reporting. > > For example, Mozilla could require that, in addition to the "traditional" > WebTrust reporting , Mozilla be named as part of a restricted distribution > report that contains these details. Alternatively, Mozilla could require > that, as part of participating within their root program, CAs ensure such > reports include as restricted distribution those Subscribers, Relying > Parties, and Application Vendors that would rely upon the CAs' services, > much like widely practiced in industry today with respect to cloud > providers. > > Would you agree that it's fair to say that it is not fundamentally that > auditors cannot report such information, but focused here on the details of > how that report is delivered to Mozilla?
Thanks Ryan, I do agree that this information is better placed in a separate communication as you suggest. As we already worked through the restricted use issue with the detailed controls report, we could adopt that same limited distribution language in the added communication you suggest. So now you have me thinking. This separate communication could also be used to discuss other items, especially the locations in scope and visited during the audit. Without having this separate communication, this information will likely be added as another exhibit to the report, especially for the larger, more complex CAs, making a long report even longer in volume. (Side note: length of some reports is an issue when the WebTrust seal is applied). I think if this information was put into the separate communication, we could solve another problem herein by taking this information that is candidly sensitive (specific locations) and move it to a more restricted report. I'll be interested to hea r your thoughts on this approach as well. Jeff _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
