Hi Frank, Thanks for this interesting information! You also saved me from combing through the EV guidelines, so I will have to do that soon anyway :-)
One thing to note concerning intermediate CAs and why I prefer such setups is, that should at any time such an intermediate CA certificate's key be compromised, than this particular certificate can be revoked and instead a new one issued. By issuing directly from the CA root and have it online (even indirect) is a much higher risk even with the best HSM. Strict off-line CA roots are much safer in that respect (I don't want to get into other issues in case such a (sub) CA key is compromised and the implications of it. But obviously it doesn't affect the whole CA and *all* issued certificates underneath, but only part of it! Hence the risk is lower again). Sorry for talking to myself too long here. In short, the Mozilla CA policy and EV doesn't require it and that's what I wanted to know. Thanks again Frank for clearing this. Frank Hecker wrote: > Eddy Nigg (StartCom Ltd.) wrote: > >> Except of the Mozilla CA policy suggesting to use intermediate CA >> certificates or different roots according to different policies , >> doesn't EV *require* the usage of intermediate CAs (no direct issuance)? >> Does anybody know from memory about this? Else I'll look it up... >> > > I looked it up just now. The EV guidelines do not contain the term > "intermediate" CA, but do have several references to subordinate CAs. > The guidelines specify how subordinate CAs must be set up for use with > EV; basically, the subordinate CA certificate has to have a > certificatePolicies extension marked as non-critical and containing > either the EV policy OID or the special anyPolicy value. However as far > as I can tell it is not mandatory to use a subordinate CA; there seems > to be nothing in the guidelines that prevents issuing EV certificates > directly from the root. > > Regarding the Mozilla CA policy, the language in the policy (section 13) > is a recommendation only, because we couldn't reach consensus on making > it mandatory. Also, recall that the purpose of the recommendation was > "so that we or others may selectively enable or disable acceptance of > certificates issued according to a particular policy, or may otherwise > treat such certificates differently (e.g., in our products' user > interfaces)." Arguably the use of EV policy OIDs can accomplish this > same purpose, albeit in a slightly different way. > > In particular, for a CA issuing both EV and non-EV SSL certs, we could > (at least in theory) choose any of the following options: > > 1. Support both EV and non-EV certs from that CA, by recognizing the EV > policy OID and using a different UI for the different types of certs. > 2. Recognize only EV certs from that CA, by rejecting certs without the > EV policy OID. > 3. Recognize only non-EV certs from that CA, by rejecting certs with the > EV policy OID. > 4. Treat EV certs from that CA as non-EV certs, by ignoring the EV > policy OID. > > All of the above options could be implemented without requiring the use > of separate roots (or separate intermediate CAs) for EV vs. non-EV > certs. Granted, we don't currently have a preferences UI to allow end > users to select these options, but that's ultimately our problem, not > the CA's. > > Frank > > -- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
