Kaspar Brand wrote: > > On 14.07.2010 17:47, Nelson B Bolyard wrote: > > > > SANs solve this whole problem. They have a component that may ONLY contain > > DNS names, and therefore is easily constrained. DNS name constraints would > > be effective if certs ONLY put DNS names into SANs. > > That's an argument for completely banning CN-IDs, in the first place. > But I fail to see how it is relevant for the decision whether to only > check the "(most specific) Common Name field" or all of the CNs.
In the PKIX specs implementing name constraints for DNames is a MUST, while implementation of DNSName SANs officially "RECOMMENDED" and in reality probably a MAY. > > > But putting DNS names > > into SANs effectively bypasses name constraints (at least, in > > implementations I tested last year). > > Should read "... into CNs", I guess? AFAIK, Name constraints conceptually are supposed to work at the certificate path validation level. So a name constraint imposed by a rootCA for an intermediate CA works for exactly that particular type of name. If applications check for acceptable names in certs by comparing with different types of names (like DNSName SAN and CN-ID), then a name constraint on only one of them is obviously ineffective from preventing the intermediate CA to bypass the name constraint. > > In any case, if you disregard CNs > in the subject for name matching as soon as there is a subjectAltName > extension with at least one dNSName (as > draft-saintandre-tls-server-id-check-08 does), then it's becoming a > non-issue. I don't think this is an appropriate characterization of the issues at hand. There are a number of parties involved, each with very different objectives. Name constraints is tool for a multi-CA hierarchy that a CA higher up the hierarchy can use to impose limits to the authority of CAs closer to or issuing the EE certs. name constraints are not in the interest of the server, not in the interest of the client and not necessarily in the interest of the issuing CA (the presencs of name constraints is evidence that it is not in the interest of the issuing CA -- but instead in the interest of the higher up CA). The inclusion of DNSName SANs or CN-IDs in a Servers EE-Cert might be in the interest of the Server, might be in the interest of the issuing CA or might be a mere technical restriction of the CA's software or the CA's configuration. A Server that intentionally uses an EE-Cert with DNSName SANs has no control over the clients that connect to that server. Whether these clients understand DNSName SANs or only CN-IDs, or whether these clients ignore CN-IDs when DNSName SANs are present or always check both, is also completely outside of the control of the server. The server and the issuing CA might consent to not put a CN-ID into the server's EE-Cert, but that is likely result is a number of clients rejecting the server's cert. > > > IMO, we should be attempting to drive a stake in the heart of DNS names in > > subject CNs, and moving all CAs to use SANs exclusively for DNS names. That decision, and the risk management for the resulting interop problems, should be left to the combined decision of the Server operator and issuing CA to no longer include CN-IDs in EE-Certs on a case-by-case basis. > > -08 already does this in several places: > > The certificate SHOULD NOT represent the server's fully-qualified > DNS domain name in a CN-ID, even though many deployed clients > still check for this legacy identifier configuration within > certificate subjectName. [...] > > Notwithstanding any of the foregoing rules, reference identifiers > of type CN-ID (if included) MUST always be the lowest-priority > reference identifiers in the list. [...] It has been recently asked (I think by Paul Hoffman) why there is an ordering when checking is going to be performed as a linear search, and similarly I'm wondering what "lowest-priority reference identifiers" is supposed to mean here. I assumed the matching was about a Boolean decision, either it matches the servers identity or it doesn't match. "lowest-priority" sounds like a XX% acceptable match instead of a Boolean. > > Security Note: A client MUST NOT seek a match for a reference > identifier of CN-ID if the presented identifiers include an > SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName > entry types supported by the client. This MUST NOT is an unnecessary a violation of rfc-2119 section 6, and completely ignorant of the situation that software updates must not break the installed base. It is trivial for the server&CA to make this happen by having the CA issue a Cert without CN-ID. -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
