On Thu, Oct 05, 2017 at 11:05:07AM +0800, Gervase Markham via dev-security-policy wrote: > In addition, we do need to address the question of how we can ascertain > that the organization has acquired the technical competence and > management rigour which seems to be lacking. I know you have placed some > audit requirements in there, but I do think we need to discuss whether > those will provide a sufficient guarantee and, if not, if there's > anything that could.
One thing that might provide at least a certain amount of motivation, if not guarantee, would be to apply an additional delay in re-application processing if review of the initial re-application is found to be deficient. I know a similar thing has been suggested in the past for applications in general, to avoid the situation where new applications are essentially being taught webPKI by the participants in the Mozilla application process, although I don't recall off the top of my head what the concerns were in general. However, for a re-application of this sort, a "get it right or face delay" would send a strong message that the applicant really needs to spend the time to get their ducks in a row before coming back. Otherwise, they could very easily spend the entire next twelve months sitting on their hands, then come back with the same infrastructure and play whack-a-mole with whatever gets identified until everyone else gets tired and gives up finding more holes. If they know they'll face another three, six, or even twelve month delay if anything untoward is found, it might encourage them to look a little harder. I'd like to include audit findings in that, although I'm aware that audits, being controlled by the company under audit, can be suppressed if they're not to the company's liking. There is also the possibility of requiring an audit (not necessarily a BR/WTCA audit; it could be any form of review based on identified deficiencies in the organisation) by a Mozilla-selected auditor, *reporting to Mozilla* (not the applicant), and paid for by the applicant. This has a degree of precedent in the StartCom case, where Mozilla required a code audit (above and beyond the usual BR/WTCA ones). There's also precedent in financial auditing, I believe, although I can't find the reference I recall reading (and thinking, "hmm, could that work for CAs?"). Whilst it might be considered an excessive burden in general (even on a "random selection" basis), for an applicant who has been previously distrusted, I don't think it's out of the realm of possibility to say, "sorry, we're going to need a bit more from you". Sure, we can hypothesise about organisations doing shady reorgs to try and look like they're "new". However, the same problems could apply now -- Procert (or any other distrusted org) could try and get around whatever sanctions have been imposed (such as a re-application delay) by re-forming as a seemingly-unrelated entity. Based on the impressive investigations that have been undertaken in the past, I'm fairly confident that most forms of shenanigan could be detected. If Mozilla has "reasonable confidence" that an applicant shares key personnel, or a controlling entity, with a previously distrusted organisation, I don't think it's unreasonable to stick then with the cost of an additional review of their previously-unacceptable infrastructure and processes. - Matt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
