Re: Trustwave request for EV root inclusions/upgrade
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
Re: Trustwave request for EV root inclusions/upgrade
Frank Hecker wrote, On 2008-01-28 05:08: 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. Thanks, Frank. 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). Does it follow from that recommendation that Mozilla browsers should provide a user-configurable preference to enable/disable the EV UI entirely? Should users have the option to disable Larry? Has anyone expressed desire to do so? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Trustwave request for EV root inclusions/upgrade
Nelson B Bolyard wrote: Does it follow from that recommendation that Mozilla browsers should provide a user-configurable preference to enable/disable the EV UI entirely? Should users have the option to disable Larry? Has anyone expressed desire to do so? I haven't (yet) heard anyone express a desire to disable Larry. In this regard, I wasn't thinking so much of users wanting or needing the option to disable Larry. I was actually thinking more of the reverse case, where either we or the end user might want to only accept EV certs from a particular CA. (Perhaps we and/or the end user don't like that particular CA's procedures for non-EV certs). In other words, show the Larry interface for that CA's EV certs, but reject their non-EV certs as invalid, same as if the CA didn't have an embedded root. This is really a question for the future, but it might be useful to think about for long-term NSS/PSM planning. It's sort of a special case of the general problem of having NSS/PSM be able to take special actions (either built-in or user-specified) based on certificate policy values. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Trustwave request for EV root inclusions/upgrade
Frank Hecker wrote: Trustwave has applied to add two EV root CA certificates to the Mozilla root store, and to also upgrade an existing root CA certificate for EV use, as documented in the following bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=409837 https://bugzilla.mozilla.org/show_bug.cgi?id=409838 https://bugzilla.mozilla.org/show_bug.cgi?id=409840 and in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/#Trustwave I have evaluated their request, as per the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/certs/policy/ and plan to officially approve this request after a public comment period. Note that the WebTrust EV audit for Trustwave was done under the final EV guidelines and WebTrust EV criteria, so its acceptance under our policy is not dependent on making the proposed policy change discussed in my previous message. Question: The entry at http://www.mozilla.org/projects/security/certs/pending/#Trustwave states that At this time there are no subordinate CAs for any of these roots; instead end entity certificates are issued directly from the roots. 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... -- 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
