I'm glad to see some discussion of this issue. Note that other implementations treated this as a bug and fixed it a long time ago.
On 05/30/2016 11:56 AM, Rich Salz wrote: > WebPKI has deprecated > cn-as-hostname for more than a decade and mandated SAN names. Well, maybe that is the Right Answerâ„¢ I'm not sure what "deprecated" and "mandated" mean in the openssl context. If openssl actually de-implemented CN-as-hostname and actually mandated SAN, that would solve the nameConstraints bypass bug in grand style. > Leaving this open because we might be able to do some hueristics/hacks to > determine when the CN "should be" a DNS name. How about this for a heuristic: If nameConstraints are in effect, then the validator MUST NOT accept the CN as a DNS name. This seems like the least the validator could do, in light of the aforementioned deprecation. This seems unlikely to generate false alarms, since any issuer who uses nameConstraints should be savvy enough to not rely on CN-as-hostname to the exclusion of SANs. Optionally a CN that satisfies the nameConstraints could be tolerated, insofar as it is deprecated but harmless. > But the workaround is to use SAN. That workaround is not specific enough to solve the security problem. Note the contrast: -- As it stands, good guys are /allowed/ to use SAN. -- The problem is not solved until bad guys are /required/ to use SAN; ... or more to the point, required to not use anything but SAN; ... or even more to the point, required to not use anything that bypasses the nameConstraints. The crucial word there is "required". -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev