On 13/01/17 01:56, Ryan Sleevi wrote: > Notably, 1.3.7 also has IP encumbrances - and uncertainty - the same > as 1.4.1, so presumably, Mozilla is OK with having encumbered methods > included. Considering some of these exclusions have existed since the > BR's adoption, that doesn't seem an unreasonable conclusion.
This is a fair point, to a degree. IP issues with the documented methods are not avoided just because they are documented in a document which existed before the disclosures were finally properly filed. > So what's the difference between 1.3.7 and 1.4.1? > - A few methods were introduced which may or may not be encumbered > - The ability for the CA to select anything they want to argue is > equivalent is removed > > I would presume that your contention with 139 is not because new > methods were (potentially) encumbered, but on the basis that it > removes the any other method. Yes, I think that's more it. I was nervous about removing that "escape hatch" for CAs before the IPR questions were more fully settled. > Given that there are other methods > available (as reaffirmed by Ballot 181) that have no encumbrances by > CA/B Forum members, and given that potentially *any or all* of the > methods used may be encumbered by non-Forum members (who have no > obligation to disclose), it does not seem that it creates any new > meaningful risk for Mozilla to impose 1.4.1 upon CAs. It's true that the passing of 181, which had not happened when I prepared my original thoughts for this Github issue, does clarify matters. And it includes at least one 'unencumbered' automatable method. > Given that you can always revisit it if a CA can provide demonstrable > evidence of concern and proposed alternatives, without waiting on the > CA/Browser Forum, I'd like to encourage you that 1.4.1 is no worse > than 1.3.7, either technically or from an IP encumbrance perspective, > but is significantly and substantially better. The GoDaddy incident is relevant, I agree. OK, sold. Many recent changes to the BRs have been additionally-permissive, and so don't require a lead time for CAs to adopt. The most recent change which is not so is ballot 174, which changed the requirements about what CAs must put in their CPs and CPSes when their issuance practices conflict with the BRs due to local law. That passed on 29th August 2016, 4.5 months ago, and led to version 1.3.9. By the time we ship policy 2.4, I expect it'll be nearly 6 months. So we could move to 1.3.7, 1.4.1, or 1.4.2. So the real policy question here is: "Does Mozilla want to leave the 'any other method' option open to CAs and, if so, for how long?" If the answer is no, we should adopt 1.4.1 and require strict compliance (i.e. you can't actually use 1.4.2 or later) for section 3.2.2.4, although we might allow any later version for all other sections. If the answer is yes, we should adopt 1.4.2, and permit compliance to later versions. When we decide to stop permitting "any other method", we either update the version number to a later version of the BRs if it has that option removed by then, or we simply state that we don't allow it any more. Google's policy, AIUI, is that they are requiring strict 10-method compliance by the original effective date of ballot 169, which is 1st March 2017. I suspect we won't ship CA Policy 2.4 before that, although I'd like to ship soon after. Because of Google's requirement, I expect most CAs will be working towards that date anyway. So we could probably piggy-back on that. Comments? Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
