On Mon, Feb 15, 2021 at 6:07 PM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Ryan, I hope you are not suggesting I am dodging you points. That would > be absurd. Let me use different words as comparable world seems to be > tripping you up. I'm not trying to suggest you're dodging intentionally, but as I said, I think we were, and to a degree still are, talking past each other. I think your reply captured that you don't think I understood your phrasing, which I didn't, but I also don't think you understood why I was trying to unpack that phrase more. > You are not providing a general/public distribution example to make your > point so it is baseless. You are using a restricted opinion from EY and > neither Ryan Sleevi nor Google are listed as the two intended users. I'm not sure why you're bringing in Google with respect to https://wiki.mozilla.org/CA/Policy_Participants . I'm also not sure how this relates to the specific questions I asked, which were an attempt to reset the conversation here to try and make progress on finding solutions. > The closest I have seen to support your desire to name individual auditors > is in public company audit reports, which are housed on the SEC website. > To be clear, of your two examples, one is an opinion, which is restricted, > and the other represents the guidelines. Perhaps you have seen a > public/general distribution report from your second opinion as I do not see > it in this thread. I am aware, as mentioned previously, of the Federal PKI > program desiring to know more about team members, but that is not listed in > a non-restricted report, in a public/general distribution format. Sure, and the purpose of the questions was an attempt to reset the conversation to a point where we're not talking past each other, by trying to build up from basics. I know we both know there are many different audit criteria that are used, and the WTTF member organizations are global organizations. I don't want to assume that those who focus on the WTTF are as familiar with, say, the BSI requirements or other audit criteria, much the same way it wouldn't be reasonable to expect I know as much about AI as PKI :) The example report I provided wasn't about calling out an individual member, but rather to highlight an area that, objectively, seems comparable, particularly to Ben's proposed language, to better understand what you meant by that, and whether you had concerns with the new approach still. You've anchored here on the public disclosure part, which I can understand and appreciate the risk perceived by having auditor names attached to the reports, instead of just firms. I see most of your answers focus on a specific form of disclosure, but that wasn't what my previous mail was trying to get to yet. I was trying to work back to understand where "comparable" criteria diverge, so we can figure out possible paths. To be clear, I support Ben's proposal as a very useful and meaningful interim step. Your original message was a bit ambiguous about where you stand, in large part because your use of "comparable" left quite a bit ambiguous, and whether you thought the changes were sufficient. I'm quite glad to hear that it sounds workable for those performing WebTrust audits, because that helps make forward progress. However, I still think it'd be useful to view this as an interim step, and it certainly feels like you might be saying this as far as things can go. In the cloud services space, we regularly see end users expecting audits of their cloud provider, and those transitively apply to dependencies of that cloud provider (e.g. datacenter security, software vendors used by the cloud provider, etc). This is similarly true with respect to software supply chain security: working out not just first order dependencies, but working through second and third-order dependencies as well, to build up a holistic risk picture. Browsers rely on and delegate to CAs, so it's no surprise that browsers expect audits for CAs. Yet browsers have their own customers, and need to provide those customers the assurances they need, and their customers need, etc. My Question #5 was an attempt to unpack "comparable" further, because these are hardly unique problems to software vendor/service provider relationships. It's not even unique to "cloud" or "PKI", as supply chain assurances are pretty universal, as shown by goods such as coconut milk, coffee, chocolate, or diamonds. You answered in the context of "public report", but I wasn't trying to go there yet. I was trying to figure out where "comparable" split off, and what schemes were and weren't comparable, so that we can continue to make improvements. Now that it seems we have a path forward for direct disclosure, I think it's reasonable to spend time thinking about how to bring that assurance to browser's users/customers, such as this community, in the same way we help bring transparency to cloud provider customers and their customers. We don't have to do it right now, in this thread, but I also don't think we can say this is as far as we can go, which I took this most recent reply to be suggesting. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
