[cabfpub] Proposed new ballot on IP Addresses in SANs

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 3:32 PM, Peter Bowen <pzb at amzn.com> wrote:

> Why would anyone ever need to emulate Microsoft’s behavior?


Because people will inevitably see something as accepted and see it as
recommended? The same way most of the WebPKI has historically, and
unfortunately, happened?


> 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.
>

Which is to say, clients can't enforce compliance with RFC5280, nor does an
implementation that expects certificates from publicly trusted CAs to
comply with RFC5280 work with such certificates.


> 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.
>

Are you suggesting that Windows earlier than 10 applies nameConstraints
from iPAddresses against dNSNames and commonNames? That's not what I've
seen. Certainly, the application against commonNames isn't specified in
RFC5280 (for dNSNames or iPAddresses), even if it's something a number of
implementations have begun to do.

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

Yes, there's those in category #3 - which don't look at if the host portion
of the URL is a domain or an IP address, and simply treat is as an opaque
string, examining against either the dNSName or the iPAddress. Given the
significant complexities of the URL spec with relation to determining if
the host is one or the other (e.g. http://12345/ is a valid URL in many
implementations - but is perhaps not what you'd expect), it's much easier
to enforce compliance that dNSNames are DNS, iPAddresses are IPs, and then
just do a string-match on either when evaluating against the host, assuming
it will fit into the right slot.

So your description of how clients process iPAddress in GeneralNames is not
correct. Whether you consider that a subset/correction for #1 (since they
do respect iPAddress) is perhaps qubbling
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160426/2b5ae177/attachment.html