[cabfpub] Proposed new ballot on IP Addresses in SANs

[Peter Bowen]

> On Apr 21, 2016, at 7:30 AM, Ryan Sleevi <sleevi at google.com> wrote:
> One might change the proposal, to require that if an IP is present in the dNSName SAN, then it MUST ALSO be present in an iPAddress SAN. That is, a BR conforming cert would have to encode as:
> 
> commonName:8.8.8.8
> subjectAltName:
>   dNSName:8.8.8.8
>   iPAddress:8.8.8.8
> 
> There, a conforming RFC5280 compliant implementation will properly reject the certificate as violating the name constraints. While an 'evil subCA' could issue a certificate
> 
> commonName:8.8.8.8
> [subjectAltName omitted]
> 
> Which would trigger the evasion behaviour described above, such a certificate is "clearly" non-conforming to the BRs.
> 
> And of course, there's no guarantee that the solution I proposed above - one to protect users - would actually be deployable in practice and not trigger bugs in other clients. Which is why the idea of "let's just violate the BRs" is so deeply discouragingly problematic.

I meant to include this in the list of requirements in my previous email.  Any IP address included as a string in dNSName must also be included in iPAddress.  This is done today and has been confirmed to work for current clients.  This also makes it clear that clients that implement SAN checking as defined in RFC 5280 don’t need to change.  This purely a compatibility feature, just like commonName.

The prior discussion pointed out that putting the iPAddress entry before the stringified dNSName entry allows all clients to work without modification.

Thanks,
Peter