On Thu, Jan 7, 2016 at 2:34 PM, David E. Ross <nobody@nowhere.invalid> wrote: > On 1/7/2016 12:29 PM, Kathleen Wilson wrote: >> On 1/7/16 11:15 AM, Peter Bowen wrote: >>> <snip> >>> >>> Until such time that the provide this, I don't see how they are any >>> different from the thousands of private PKIs that are run by companies >>> for their own use. Many of those PKIs may be used to MITM >>> connections. >> >> OK. I suppose that means I should go ahead and start the information >> verification process for this request. >> https://wiki.mozilla.org/CA:How_to_apply#Information_Verification >> >> >>> All CAs should be held to the same standard when asking for admission >>> to the Mozilla program, this is no different. >> >> That's very logical. >> I was sort of hoping to avoid spending the time doing the Information >> Verification if I didn't have to. >> >> Kathleen >> > > I suggest deferring any effort on this request other than informing the > certification authority that they need audits both for WebTrust for CA > and for BR. That notice should also indicate that, without PROPER > audits with public-facing audit reports, no action can be taken. > > No other effort should be expended on this.
I agree 100%. MITM implies that they are not following BR, as there is no way they can be validating domain control[1]. This should mean that they cannot complete a BR audit without having a massive qualification on the report. Mozilla gets lots of requests for inclusion which are summarily closed because the request does not meet the requirements; this should be treated the same. Thanks, Peter [1] I can imagine exactly one way they could claim to simultaneously meet the BRs and issue MITM certificates: claim they are using a practical control method and show that from their vantage point they have practical control of the Internet. They could even modify HTTP responses to inject validation tokens and/or modify DNS responses to do the same. Obviously this is not the intent of practical control validation but would be an interesting tactic. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
