On Thu, 2010-09-23 at 18:13 +0200, Martin Rex wrote: > 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.
[...] > 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. But if by doing that they can issue certificates that clients will accept for server names the superior CA did not intend, that's a big security problem. > Those that need the backwards compatibility will _not_ disable > the matching fallback if DNSName SANs are present, NSS doesn't: https://mxr.mozilla.org/mozilla/ident?i=CERT_VerifyCertName The idea is that by including a dNSName SAN, the CA opts out of the backward compatibility. I don't think anyone issues certificates with both dNSName SAN and CN with the intent that the CN be honored as a server name. > 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. Those that need backwards compatibility, name constraints, and security need to do something about this issue. Some previous discussion: http://www.ietf.org/mail-archive/web/pkix/current/msg27619.html -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
