Google is aiming to steal Amazon cloud customers in the media industry
cnbc.com1 pointsby packetized0 comments
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 you’re being paid well, obviously you’ll be annoyed by concepts contrary to your work.
e: edits are hated, but the downvotes prove out: Kubernetes is simply OpenStack for hipsters.