Eddy Nigg (StartCom Ltd.) wrote: > I working up my backlog....at first I thought this to be a good idea to > split the request up, but on the other hand I wonder if it's really that > good. Because we might see all requests in their context maybe...not sure.
For some information on context please see below. > Just what somewhat annoys me, is that all this roots issue all types of > certificates from DV to EV, sometimes even their intermediate CAs do > that...it's not really an issue but makes it somehow unclear, plus if > we'd want to limit this or other CAs in some way it makes it difficult > if not impossible. As I understand it, the original plan (as worked out within the CA Browser Forum) was for EV not to require the creation of new roots. Instead the certificatePolicies extension was to be used to limit how and where EV certificates could be issued within existing CA hierarchies. This plan is reflected in section 7 of the 1.0 EV guidelines (pages 11-12). Under this plan, my understanding is that the original intent of Comodo, VeriSign, and other CAs was simply to mark their existing roots for EV use, with an associated EV policy OID (or OIDs). Then they could simply create new EV-specific subordinate CAs, and permit those subordinate CAs to issue EV certificates by putting the certificatePolicies extension with the appropriate EV OID on the subordinate CAs' CA certificates. Unfortunately this simple plan had to be abandoned because it didn't work properly with EV-aware versions of IE on Windows. It was OK for Windows Vista, because Vista by default doesn't include any CA certs other than Microsoft's own certs. Thus when IE on Vista went to a new EV site, Windows would realize it needed the root CA cert, would go out to Microsoft to fetch it, and would get an up-to-date copy with all the associated EV metadata. However although Windows XP can also fetch new roots in this way, XP already had copies of legacy roots from Comodo, VeriSign, etc., and hence would use the out-of-date root data that didn't include the EV OIDs. Hence Comodo, VeriSign, etc., had to create new EV-specific roots, so XP would be forced to go out and get the new roots (and the associated EV metadata) instead of relying on its pre-loaded data. But creating new EV-specific roots in turn meant that old versions of browsers (including Firefox) wouldn't recognize sites with EV certs as being valid SSL sites at all, since they wouldn't recognize the new roots. So Comodo, VeriSign, etc., also implemented schemes whereby the new EV roots would be cross-signed by legacy roots, and EV SSL sites would send cert chains that include a CA cert corresponding to the new EV roots, but chain up to the old roots. Finally, the cross-signing scheme meant that an EV-aware browser (or OS) could now see two possible paths to a trust anchor: a path terminating at the new EV root, and a path terminating at a legacy root. In order to absolutely guarantee that EV-aware browsers recognize EV certs in all cases, both the new EV root and the legacy root have to be marked with the EV metadata. This compensates for any indeterminancy in the underlying certificate path processing code that might cause browsers to sometimes use the legacy root as a trust anchor and in other cases to use the new EV-specific root as a trust anchor. So, to summarize the situation as I understand it: Adding new EV roots was basically a hack to get IE7 on XP to treat EV certs properly. Cross-signing using legacy roots was then a hack to get older browsers (like Firefox 2) to recognize EV SSL sites as valid SSL sites (as opposed to getting "unknown root" errors). Marking both the new EV roots and legacy roots with the EV OIDs was then a hack to get EV-aware browsers like (Firefox 3) to recognize EV certs no matter which cert chain the underlying PKI library decided to follow. Now that you have the context, let me get back to the Comodo application. Comodo's roots can be divided into three classes: 1. The new Comodo EV root (COMODO Certification Authority). 2. The three legacy Comodo roots that are specifically documented (i.e., in Comodo's EV CPS) as participating in Comodo's cross-signing scheme and thus could be encountered as trust anchors when processing cert chains from EV sites (AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware). 3. All other legacy Comodo roots, which might end up being involved in EV-related cross-signing schemes, but don't appear to be documented as doing so right now, based on the CPSs I've reviewed. Based on this division, I've done evaluations and preliminary approvals for the new EV root (class 1) and the three legacy roots in class 2, but I've postponed action on the remaining roots (class 3) until it's clearer whether I need to approve them for EV purposes, or can wait on this. > Supposed an intermediate CA or CA root is dedicated > for EV only, we might have much better control. Just imagine Comodo > issues a DV cert with the EV bits on....thoughts, suggestions? I think we've discussed a similar issue in relation to subordinate CAs. There's a trade-off here between maximum control and complexity. If we wanted maximum control then we would maintain data on every CA that issued (or could issue) end entity certificates -- basically every root CA and every subordinate CA under those roots, without exception. Then we could exercise very fine-grained control: We could say, this subordinate CA (which might be 3 or 4 levels down in the hierarchy from a given root) can do this (issue EV certs, issue email certs, whatever), while this other subordinate CA (somewhere else in the hierarchy under that root) can't. However exercising this amount of control would involve lots and lots of work on our part, and would require maintaining very large sets of CA-related data that we would either have to ship with Firefox or build a scheme to have Firefox automatically fetch. Quite frankly I think it's a non-starter. The scheme we have now trades off maximum control for implementability. We have relatively coarse-grained controls, and then we rely on CAs to implement more fine-grained controls (e.g., using certificatePolicies, EKU, etc.). This means that CAs in theory could abuse the scheme (e.g., by issuing EV certs from subordinates not intended to be used for this purpose). That's where we rely on auditors to verify that CAs are operating according to their stated plans. If that turns out not to be true in certain cases then we can look at those on a case-by-case basis and figure out if we need to or want to take certain actions. I can't write any more on this right now, but I hope the above addresses at least some of the questions you had. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
