[cabfpub] Proposed new ballot on IP Addresses in SANs

[Peter Bowen]

> On Apr 26, 2016, at 4:05 PM, Brian Smith <brian at briansmith.org> wrote:
> 
> [Please forward this to the list]

First, I would suggest that you registered as an Interested Party with the CA/Browser Forum.  All that is required is sending a signed IPR Agreement (https://cabforum.org/wp-content/uploads/Intellectual-Property-Rights-Agreement-1.2-PKI-enabled.pdf) to questions at cabforum.org.  Then you can directly participate in the conversation.

> Peter Bowen <pzb at amzn.com> wrote:
> > 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.
> 
> Implementations generally validate all the names in a certificate against all the name constraints, independently of which site is currently being accessed. So, for example, let's say the end-entity certificate contains:
> 
>     dNSName: example.com
>     iPAddress: 1.2.3.4
>     dNSName: 1.2.3.4
> 
> and the name constraints in effect are:
> 
>     Permit iPAddress 1.2.3.4
>     Permit dNSName example.com
> 
> "dNSName 1.2.3.4" does not match this constraint so the certificate is rejected. It doesn't matter whether the user is actually visiting https://example.com or https://1.2.3.4 or something else.

This is good to know.  My reading of the spec is that dNSName 1.2.3.4 would be filtered out of valid names but that the other two names would still be acceptable. This implies that a CA that is the subject of a CA certificate with name constraints cannot also safely be the subject of an unconstrained CA certificate (unless it only issues for names under the constraints).  I’m thinking of a case where a private CA wants to issue for public suffixes they manage plus private/unregistered suffixes (or bare names) which they don’t.  I realize that this is not allowed by the BRs today, but it seemed like a reasonable thing to allow if name constraints were flagged as critical.

> Also, I understand your point that you think it is OK that some implementations just don't implement what Microsoft does. But, web browsers have found (especially in the area of HTML/CSS/JS, but also other areas) that over time all implementations tend to be forced to implementing the union of all browsers' behaviors. Thus, from experience we conclude that such variance is not sustainable in the long term.

I was trying to be careful to avoid that by requiring that all iPAddresses appear as iPAddress type names.  This would ensure that there is no disadvantage for implementors properly following the spec.

Thanks,
Peter