Re: Permission to use Errata CAA Algorithm
Google Chrome's position on this matter has been posted on the Public CA/B Forum mailing list here: https://cabforum.org/pipermail/public/2017-September/012148.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Permission to use Errata CAA Algorithm
On 15/09/17 20:24, j...@letsencrypt.org wrote: > We would like to ask the Mozilla and Google root programs on this list to > immediately grant at least temporary dispensation for CAs to implement the > CAA checking algorithm as described in this errata: > > https://www.rfc-editor.org/errata/eid5065 Mozilla's current position on CAA checking algorithms is as follows. CAA is now mandatory. As such, we expect all CAs to be making good faith efforts to either: a) do the algorithm in RFC6844, or b) do the algorithm in RFC6844, as amended by erratum 5065 Once a motion passes in the CAB Forum to update the BRs to require b), I would expect CAs in category a) to move to category b) within a reasonable amount of time, such as 3 months. (If the motion fails, I would expect the reverse.) So yes, CAs which wish to do b) may do so according to Mozilla. If such "non-compliance" ends up on an audit report, Mozilla will not consider that material or concerning. There is apparently also an open question about DNAME handling, and another erratum which clarifies things, but my understanding is that the RFC is open to two interpretations, one compatible with the algorithms in the DNAME RFC, and one not. And that no-one uses DNAME in the wild except people trying to test CAA ;-) So until I understand the situation better, my general approach is that CAs may do whatever they can reasonably justify as consistent with the RFC when it comes to DNAME. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Permission to use Errata CAA Algorithm
We applaud the recent addition of CAA checking requirements to the Baseline Requirements. However, there are known problems with the CAA checking algorithm specified in RFC 6844, and those problems are leading to many reports from our subscribers. The issues are described here: https://community.letsencrypt.org/t/legacy-caa-implementation/ We would like to ask the Mozilla and Google root programs on this list to immediately grant at least temporary dispensation for CAs to implement the CAA checking algorithm as described in this errata: https://www.rfc-editor.org/errata/eid5065 We believe that the algorithm described in this errata is a better algorithm, and that the IETF working group behind CAA agrees. We believe a CA/B Forum ballot will pass in the near term to make the algorithm compliant. A CA/B Forum ballot will take some time to pass, however, and subscribers are hurting now. Therefore we believe the right course of action is for root programs to grant at least temporary dispensation for CAs to implement the errata algorithm starting immediately. Let’s Encrypt has implemented the errata algorithm for CAA checking for some time now, until Thursday (yesterday) morning, when we switched to the RFC 6844 algorithm for compliance reasons. Let’s Encrypt acknowledges that we did not move to the compliant algorithm until after the compliance deadline and we apologize for that. We should have sought dispensation before the compliance deadline and not having done so was wrong regardless of whether or not dispensation is granted now. Nonetheless, we believe the right thing to do going forward is to allow any CA to at least temporarily implement the errata algorithm. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
