[packetized]

The finding in TLS-01-003 is surprising to me, mostly because it presupposes a lack of sophistication among users of this library who are also using X.509 NameConstraints. From RFC5280:

  For example, a name constraint for "class C" subnet 192.0.2.0 is represented as the octets C0 00 02 00 FF FF FF 00, representing the CIDR notation 192.0.2.0/24 (mask 255.255.255.0).

As they mention in the findings:

  Typically, subnet masks should be contiguous and the presence of a non-contiguous mask might indicate a typo (such as 225.255.255.0 vs. 255.255.255.0), or potentially an attempt to bypass an access control scheme. Therefore, it is recommended to treat certificates containing non-contiguous subnet masks in their name constraints as invalid.

This seems to run counter to the intent in the RFC. By allowing for a four-octet subnet mask, instead of simply an int to represent the a contiguous CIDR mask, the RFC authors may have intended that more complex IP-based NameConstraints could be constructed. This certainly would make a huge difference for something like an intermediate (CA:TRUE), where it becomes much more economical to specify a sparse mask for a highly templated network. Think certs for network equipment or VoIP phones with regular, repeatable IP addressing across many locations/networks. E.g., a VoIP provisioning system that has an intermediate issuing CA with the following NameConstraints: IP:172.16.0.0/255.255.1.239.

If any change comes from this specific finding, I would hope that it's simply a flag to allow or disallow the use of discontiguous masks. I do understand that this is specific to WebPKI; having said that, if a client is implemented using rustls (with these recommendations enabled) and it happens across a perfectly valid certificate issued by an intermediate with a discontiguous mask in the NameConstraints, presumably it would fail or otherwise break. And yes, I have previously configured precisely this in an intermediate CA.

[JoshTriplett]

Leaving aside the question of whether other software will work reliably with non-contiguous subnet masks (which led to this recommendation), in general, most software does not deal well with NameConstraints. Some libraries ignore it, some libraries fail hard if a constraint exists, and in general, I'd expect a certificate chain involving NameConstraints to be poorly supported at best and insecure at worst.

I wish that NameConstraints were better supported, to make it easier to support intermediate CAs; for instance, prove you own example.com and you could then have a CA restricted to *.example.com. But right now, that just doesn't seem feasible.

[briansmith]

I spent significant effort writing the name constraint implementation in mozilla::pkix (used by Firefox) and by webpki (used by Rustls) to fix this situation. The result is summarized by Netflix:

> The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass.

- https://netflixtechblog.com/bettertls-c9915cd255c0

Since then, Google Chrome has implemented and deployed a new certificate processing library on some (most?) platforms it supports, and I bet they have similar or better name constraint support. I believe Apple has also improved their implementation.

> I wish that NameConstraints were better supported, to make it easier to support intermediate CAs; for instance, prove you own example.com and you could then have a CA restricted to *.example.com. But right now, that just doesn't seem feasible.

Since the aforementioned improvements have shipped in production browsers, it is much more practical, from a technical standpoint, to do that. The real problem now is browsers' CA policies. As I understand it, they do not want you to be able to get your own name-constrained intermediate CA certificate. The CA that issues you the intermediate CA certificate would be on the hook, with the consequence of being removed from the root CA programs, if you issued a malformed certificate. And there are other issues with the policy. I hope there are improvements to the browsers' CA policies to make this practical, but I wouldn't hold my breath.

[dathinab]

I'm not completely certain, but my guess is a lot of software and midleware doesn't work well with non-continuous subnet masks.

It's one of this (many) thinks where in theory the RFC has intended support for this but in praxis it's close to unusable and better to block for most application use cases.

Like e.g. many valid email-addresses are in practice unusable and it's recommended to not support them because today they are basically only used to intentionally cause problems (I mean email addresses using quoting like `"a b"@example.com`, you always should support internationalized mail addresses, except maybe as mail provider where it depends on your target customers).

[briansmith]

I commented on this at https://github.com/briansmith/webpki/issues/130. This is nothing to be concerned about, for quite a few reasons. I don't expect any compatibility issues with being stricter since Google Chrome's new X.509 processing does enforce the stricter syntax.