The language you quoted from me is a bit imprecise, my apologies.
I was trying to get CAs to disclose previously undisclosed uses of (4). There are disclosed uses of (4), including from DigiCert, that haven’t made it into the BR methods yet, because in the past year, we have failed to pass Jeremy’s IP validation ballot (https://cabforum.org/pipermail/validation/2017-February/000477.html). I was aware of those at the time I wrote what you quoted, but thought they’d be in the BRs by now … there was a time when it looked like that ballot was close to being finalized. The point is that there are IP methods that are not in the BRs that currently fall under (4) that we’ve been trying to get into the BRs for a while now. DigiCert would like to be able to continue using the IP validation methods we disclosed last year, unless there is a reason why they are worse than other disclosed or undisclosed methods. -Tim From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Tuesday, March 20, 2018 5:08 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Policy 2.6 Proposal: Update domain validation requirements Tim, On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > wrote: > * Add a new bullet on IP Address validation that forbids the use of BR > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address > validation processes in the CA’s CP/CPS. This is a bit premature. Most CA's IP validation procedures still fall under any other method, and the draft ballot that we've been trying to pass for a year or so is not done yet (I was writing it when the Validation Summit started taking over my life...) There's a good chance we will get a ballot passed on this issue this summer, but there's also a good chance that work on improving the non-IP validation methods will be prioritized above it. This seems to contradict your comment in issue 116 [1]: I think the solution to Ryan's issue is to remove 3.2.2.5 (4). The VWG is currently discussing changes to 3.2.2.5 (in order to remove 3.2.2.5 (4)), and we haven't heard of any CA that is using it, though we should check the smaller ones. It's possible 3.2.2.5 (4) could be removed with an aggressive timeline if it's really true no one is using it. It would be great to hear from CAs on the impact they would feel from Mozilla banning 3.2.2.5(4) prior to passage of the VWG ballot you mentioned. - Wayne [1] https://github.com/mozilla/pkipolicy/issues/116
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
