[cabfpub] Proposed new ballot on IP Addresses in SANs

Peter Bowen pzb at amzn.com
Tue Apr 26 22:32:54 UTC 2016

(the quoting is probably screwed up, apologies ahead of time)

> Brian Smith <brian at briansmith.org> wrote:
> > Peter Bowen <pzb at amzn.com> wrote:

> > 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.
> This is not true. In particular, not only would the subjectAltName parsing need to be changed, but name constraint processing would also need to be changed. For example, consider a constraint that disallowed all IP addresses. The code for enforcing that would be correct if it only looked at iPAddress subjectAltName entries (and the subject CN, if the implementation supports that deprecated practice). However, if one needs to emulate Microsoft's behavior then it would need to be changed to also look in dNSName entries for IP addresses. Depending on how the code is structured, that may be a very significant change.
> Further, if the implementation doesn't support the deprecated practice of IP addresses in the subject CN, then it would need to add additional code to parse IP addresses into a format suitable for applying the iPAddress constraint. Note that an implementation has an IP Address parser for parsing URLs, but it might not be able to reasonably use that same parser in its certificate validation code.
> Any/all of these kinds of changes add significant risks of adding bugs--not only bugs in processing IP addresses, but also bugs in processing other kinds of names, in particular DNS names. Such bugs could be disastrous for security.

Why would anyone ever need to emulate Microsoft’s behavior?  My proposal assumes that there are two classes of clients:

1) Clients that follow the RFC and look at iPAddress type GeneralNames in the SAN (for example Mozilla)

2) Clients that don’t follow the RFC ignore ipAddress type GeneralNames (for example Windows 8)

For clients in category #1, they process certificates according to the RFCs.  That is they check the URL, determine if the host is a domain or an IP address.  If it is an IP address they don’t do any matching on dNSName type GeneralNames but only look at iPAddress type GeneralNames.  Name constraints on IPs work as per the specification.  On the other hand, if it is a domain, match on dNSName.  This is all per spec. They only thing that these clients have to do is not completely reject a certificate containing an all-numeric hostname.  They can keep these names around or throw them away, but either way they will not be matches.

For clients in category #2, if they are to implement name constraints, they do have to do what you suggest and parse things to apply constraints.  However I’m not suggesting that anyone new go down this path and apparently they already implement the constraint processing you describe.

Is there a third category of clients that does something different?


More information about the Public mailing list