On 8/13/2014 12:34 PM, Ryan Sleevi wrote: > On Wed, August 13, 2014 12:02 pm, David E. Ross wrote: >> On 8/13/2014 11:16 AM, Kathleen Wilson wrote [in part]: >>> All, >>> >>> As the CFCA discussion showed, there are a few things still to figure >>> out regarding the audits of CA conformance to the BRs. >>> >>> Here are my proposals. >> >> [snipped} >> >> >>> 3) If the CA's auditor missed something regarding the BRs, then the CA >>> has to fix the problems and be re-audited by a different auditor. >>> Would a *complete* audit need to be performed? >>> Or just an audit to show the problems have been resolved? >>> Should we require that the re-audit to be for a minimum of 3 months? >>> >>> This can be added to our wiki pages now, and we may want to consider >>> adding this to the actual policy. >> >> Often, a new auditor will require a complete audit. Changing an auditor >> is somewhat like changing a primary-care physician. The new physician >> will often require a complete physical of the patient instead of relying >> records from the prior primary-care physician. >> >> As with a new physician, a completely new audit is an expense for the >> certification authority, which I suspect would resist any request for >> such an audit. Compliance might not be obtained unless (as proposed in >> the past) we institute publicizing non-compliance, not merely with a >> "wall of shame" on a Mozilla Web site but also sending out press >> releases to appropriate news media, alerts to US-CERT, and messages to >> non-Mozilla newsgroups. > > You are correct, it is an expense for the applying Certification Authority. > > However, Mozilla's policy clearly states, in Section 16 of > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ > > "The burden is on the CA to provde that is has met the above requirements. > However the CA may request a preliminary determination from us regarding > the acceptability of the criteria and/or the competent independent party > or parties by which it proposes to meet the requirements of this policy." > > The alternative to the CA bearing the burden of a re-audit is for Mozilla > to bear the (effective) cost of performing the competent audit, and > bearing the cost to its users if that audit turns out to be insufficient. > > A CA that is unwilling or unable to perform such an audit seems like it is > unable to demonstrate to Mozilla (and the community) it's ability or > willingness to adhere to the Mozilla Inclusion Policy. > > So I wholeheartedly endorse Kathleen's proposal, especially in the broader > context of requiring the auditor examine the known bits of infrastructure > and capabilities for technical conformance. > > If this was a financial institution, and one discovered the books were > proverbially cooked, using the same auditor calls into question > > Why didn't they notice it the first time? Were they not paying attention? > Will they pay attention now? Were there other things they were not paying > attention to? Will they catch them? Was there malfeasance? Did they > conspire? > > In a system based on trust, as certificates intrinsically are, leaving > these questions outstanding seems seriously detrimental. Thus having an > independent third party - another auditor - perform the examination seems > entirely appropriate. > >
Note that I definitely did NOT intend to argue against Kathleen's item #3. I merely wanted to point out where "pushback" from certification authorities might occur. However, I do argue in favor of publicity against authorities that refuse compliance. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
