[cabfpub] Proposed new ballot on IP Addresses in SANs

Peter Bowen pzb at amzn.com
Fri Apr 22 19:45:15 UTC 2016


> On Apr 21, 2016, at 1:09 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Thu, Apr 21, 2016 at 1:06 PM, Doug Beattie <doug.beattie at globalsign.com> wrote:
> 
> 
> Ryan – This sounds like a possible solution.  Would you support a ballot that allows the issuance of BR compliant certificates containing IP addresses in the dNSName if and only if the same value is also in an iPAddress SAN field?  This comment was within the contest of Name Constraints, so I could be misinterpreting your suggestion.
> 
> 
> 
> 
> No, we will not support any such ballot without Forum members who feel there is a need for it, and who can provide demonstration, evidence, and discussion as to why the conforming solution proposed 8 months ago is not viable.

Ryan,

It is clear that Microsoft SChannel/CryptoAPI on versions of Windows other than Windows 10 does not handle iPAddress entries in the Subject Alternative Name extension.  The “conforming solution” proposed 8 months ago was to place the string-ified IP address commonName attributes.  However as recently discussed on another thread on this mailing list, multiple commonNames in a certificate cause a different set of issues and commonName is also deprecated.  So it would seem that this solution might not be the best option.

The best solution would be for clients to be updated to follow RFC 2818 and check iPAddress entries in the SAN.  Failing that, it is unclear why placing the string-ified IP in common name is any better than placing it in the dnsname.  RFC 2818 does not provide for either option — it says the URIs with IP addresses instead of hostnames must be checked against IPaddress entries in the SAN and does not provide a fallback to common name.

To me, it seems that allowing string-ified IP address in dNSName entries in the SAN when the same IP address is included as an iPAddress entry in the SAN is a reasonable tradeoff.  It is no worse than including the same in the common name.  As you have pointed out, a string-ified IP address can never match a hostname, so there is no chance of confusion  If you have a client that properly conforms to RFC 2818, then this is a no-op for you — you will look at the IPaddress entry and never try to match on DNSname.  You had expressed concern that Mozilla would need to update its code, but Gerv had indicated back in August that this was not necessary (https://cabforum.org/pipermail/public/2015-August/005850.html).

I appreciate that conformance is a great goal, but not causing customer pain is also a laudable goal.  In this case it seems the risk is low and the customer value is high.

Thanks,
Peter


More information about the Public mailing list