Paul Hoffman wrote: > >>> There should at least be a rule stating that any client that accepts the CN >>> attribute to carry the domain name MUST also perform name constraints on >>> this attribute using the domain name logic if name constraints is applied to >>> the path. Failing this requirement poses a security threat if the claimed >>> domain name in CN-ID violated the name constraints set for domain names. > > Fully disagree. I do agree with Paul that something is very wrong about this paragraph. What it seems to request is that dNSName SAN name constraints ought to be performed on CN-ID if server endpoint identification is performed with CN-ID. Since there is a requirement to use (issue) DNS-IDs in server certs, and a requirement to ignore CN-ID when DNS-ID is present, such a name constraints processing scheme looks awkward to me. Name Constraints (and its processing) is something that is specified in PKIX Internet Certificate and CRL profile (rfc-5280 and its predecessor rfc-3280) plus some ISO-specs (btw. are these publicly available anywhere), and that is normally implemented entirely within the certificate path validation of the PKI software. The BCP for server endpoint identification with TLS is something, that according to the last sentence of section 1 of all TLS specs is a matter of the application on top of TLS. A CA with name constraints for DNSName SANs (required critical according to rfc5280, mind you) in its own CA certificate that issues TLS server certificates without dNSName SANs yields "fubar" on my scorecard. The support of CN-IDs is "legacy" and retained for backwards compatibility with the installed base. Those that need the backwards compatibility will _not_ disable the matching fallback if DNSName SANs are present, and they're even more unlikely to adopt such a weird name constraints processing of a fallback they shouldn't be doing in the first place and keep doing only to not interfere with installed base. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf