[cabfpub] Proposed new ballot on IP Addresses in SANs
rbarnes at mozilla.com
Thu Apr 21 13:22:02 UTC 2016
On Thu, Apr 21, 2016 at 9:13 AM, Jody Cloutier <jodycl at microsoft.com> wrote:
> Ryan, I'm not sure I understand why Google is so intent on this new course
> of public shaming on this matter and others currently under discussion, but
> if it helps to do the right thing, then fine. The fact is that the
> requirement was not addressed, and we need to figure out how to fix the
> issue for all of our customers. Microsoft has addressed this in Windows 10,
> but we are not currently planning on back-porting this change to previous
> operating systems. As such, this change is needed or all of our customers
> will be affected.
Maybe I'm being dense, but I'm still not understanding what's changed
here. How have these customers not been "affected" already for all time?
The BRs have *always* prohibited IP addresses in dNSName SANs (all the way
back to v1), so presumably if everyone were adhering to the BRs, people
haven't *ever* been able to use pre-Win10 cilents. Why do we need to
create that capability now?
> *From:* public-bounces at cabforum.org <public-bounces at cabforum.org> on
> behalf of Ryan Sleevi <sleevi at google.com>
> *Sent:* Saturday, April 16, 2016 9:37 AM
> *To:* Rick Andrews
> *Cc:* public at cabforum.org
> *Subject:* Re: [cabfpub] Proposed new ballot on IP Addresses in SANs
> On Sat, Apr 16, 2016 at 9:31 AM, Rick Andrews <Rick_Andrews at symantec.com>
>> I disagree with the tone that CAs are entirely to blame here.
> Why? I provided you evidence on how you could have issued such
> certificates without violating the BRs.
> The fact that you:
> 1) Seemingly did not attempt to discover this yourself
> 2) If you did attempt, were unable to, and did not seek for outside input
> 3) When you did receive outside input, ignored it
> 4) Have continued to argue that it's necessary, without providing any
> response in over 8 months show that it isn't
> Shows that the CAs doing this ARE entirely to blame.
>> The BRs are baseline requirements, and browser vendors often say that
>> they have the right to impose additional requirements above and beyond the
>> BRs. When that happens, though, it sometimes puts CAs in a bind.
> And by a bind, it means you'd like to do something, but can't, besides
> browsers say you shouldn't. That isn't a bind - that's how security works.
> You can't be simultaneously trusted to be the bastion of online security
> while also engaging in insecure practices. That isn't how trust works.
>> This is a case in which the BRs say we can't do something, but one
>> browser vendor says we can.
> I'd love to hear that from Jody, given the evidence.
>> Ideally, Microsoft would have recognized this back before the BRs were
>> adopted, and addressed it in their platform or lobbied to rewrite the
> "And addressed it in their platform" - but they did, as you yourself have
> said. Windows 10 addressed this.
>> But that didn't happen. We're trying to rectify the situation now.
> You're not trying to rectify it. If you were, you would have explored 8
> months ago what I proposed, and reported back to the Forum why it wasn't
> And let's be clear here: there's a big difference between "not viable"
> (e.g. it doesn't work) and "not desirable" (e.g. our customers or we have
> to do more work). Given the role that CAs play in the online trust
> ecosystem, the goal is not to enable every business desire a CA has, nor to
> encourage or bless every practice that violates standards. It's to make a
> balanced tradeoff between risk, reward, and standards. I have seen no
> evidence of good-faith effort on your part in the past 8 months to strike
> that balance, because if there had been, the line of reasoning for this
> change wouldn't be what you're presently arguing.
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public