Frank, thanks for your detailed explanation. I concur with everything you've said, but I'd just like to add a couple of additional comments (inline) in reply to Eddy...
On Wednesday 12 March 2008, Frank Hecker wrote: > 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, The Root Certificate Programs of many software providers place restrictions on the total number of Root CA Certificates that they will accept from any one CA organization. In the case of Microsoft's Root Certificate Program: "Up to three roots per CA can be accepted into the Program because each additional root negatively impacts users by increasing download time". http://www.microsoft.com/technet/archive/security/news/rootcert.mspx?mfr=true Also, we have encountered a number of Root Programs for mobile/embedded devices that restrict the number of roots to only 1 or 2 per CA. Given that we want to embed the same Root Certificate(s) in all platforms (to avoid, if at all possible, the need for further problem-prone cross-certification!), we really need to have generic (rather than purpose-specific) trust anchors. > > sometimes even their intermediate CAs do that... For the record, I can assure you that Comodo never issue DV and EV certs from the same Intermediate CA. Having just said that, there is one exception I can think of: to help Mozilla do technical testing, we recently issued an EV certificate and a non-EV Certificate directly from each of our Roots. > > 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 -- Rob Stradling Senior Research & Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
