[cabfpub] Proposed new ballot on IP Addresses in SANs

[Peter Bowen]

> On Apr 24, 2016, at 10:05 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Fri, Apr 22, 2016 at 5:05 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> It’s been about two days since I asked them to submit their use case and description of why Ryan’s solution won’t work. Assuming they are doing their due diligence, it’ll probably be early next week. I suspect the reason it doesn’t work is the sheer volume of vhosts they will have to create to support individual certs. However, I don’t have enough information to share anything new.
> 
> 
> I would be shocked to hear that certs bound to IP addresses are being used in significant enough number as to be untenable, but your reply here definitely sounds like it's in the "It's work and we don't want to do work" side of the camp, not that it's fundamentally not viable. Given the risks, and the ecosystem harm done by carving out bits of RFC5280 where it suits customers who don't want to do work, rather than provides positive security benefits, I think such requests should be treated with great skepticism. 

Looking at the combination of the known CT logs, there are about 2216 unexpired certificates with IP addresses in the SAN extension (either as an iPAddress or as an IPv4 address-as-text as a dNSName).  Of these 2216, 930 have IPv4 in a dNSName. Of these, 435 have multiple distinct alternative names.

https://gist.github.com/pzb/ecaf3701bc631a8f0589e8eff277e694 is the list of these 435 certificates.  A few dozen are certificates that cannot be renewed (as they have RFC1918/3330 addresses included) but the rest are examples of certificates where the proposed solution of one IP/name per cert might not be viable.

Thanks,
Peter