Re: Sorting through EV root CA requests
Frank Hecker wrote: The first step is getting a complete list of all current EV-related CA requests. I believe the following is the complete list, based on searching bugzilla: I've got several of these listed now on the pending list, as noted below; I 'll get the remainder up as soon as I can. * Secomtrust (394419) http://www.mozilla.org/projects/security/certs/pending/#SECOM%20Trust * Comodo (401587) * VeriSign (402947) http://www.mozilla.org/projects/security/certs/pending/#VeriSign * Valicert/Starfield/Go Daddy (403437) * Digicert (403644) http://www.mozilla.org/projects/security/certs/pending/#DigiCert * QuoVadis (403665) http://www.mozilla.org/projects/security/certs/pending/#QuoVadis * Network Solutions (403915) * GlobalSign (406796) * Thawte (407163) * GeoTrust (407168) * Trustwave (409837, 409838, 409840) http://www.mozilla.org/projects/security/certs/pending/#Trustwave Some of the above I'm ready to render preliminary approval on; more on this later today. 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: Sorting through EV root CA requests
Hi Again Frank Hecker wrote: First, we need to reach a consensus on what to do about CAs audited under the draft WebTrust EV criteria. AFAICT right now if we applied our policy strictly we wouldn't have any CAs that comply with it, and may not have any for some time to come (per my point below). However it's not clear to me a) if the differences between the draft WebTrust EV criteria and the final WebTrust EV criteria are actually that significant, and b) if they are significant, to what extent they're security-relevant. (Because after all our ultimate concern is users' security, not guidelines and criteria per se.) Well, this is a dangerous statement, because CAs are all about policies and criterion, security is only part of the implementation of these. To explain my point, there are CAs which might be very appealing to subscribers and perhaps even secure to a certain extend, but they don't have any policies in place nor a way to govern and enforce them. Neither was a criteria applied to confirm these policies Therefore let me disagree with you and rephrase that to Because our ultimate concern is the users security we need guidelines, rules and criterion. Otherwise we just might want to skip all the hassle and have all requests approved...why bother? As we've done in the not so distant past, we had to adjust the Mozilla CA policy in order to support EV, which was the only right thing to do at the time. Else we shouldn't bother with a policy either. I think this to be very important, because this is what Mozilla expects from the CAs as well in turn... This is where I could use help from people more familiar with the nitty-gritty details of the WebTrust EV criteria and the underlying EV guidelines. I could try to dive into this and find out what the differences are in relation to the criteria and audits. However it might be that not all information is available to me at this stage (must check). As I understood from a representative of KPMG, there are differences (including the pricing) on the EV readiness audit and the real EV audit...Maybe some more information can be received from the CAB forum too, in addition to comparing the draft and final. Who is currently representing Mozilla at the CAB forum? If the differences really aren't that relevant from a security perspective then arguably we should consider a provisional approval scheme like I mentioned earlier. We aren't talking about the case of audited vs. not audited; all the CAs in question have been audited, albeit under slightly different criteria than in our current policy. Also, a CA that got audited prior to 2007/09/30 (when the final WebTrust EV criteria went into effect) is not instantly going to re-do its audit; for reasons of cost and other factors it's typically going to wait for the next audit cycle. This introduces a fair amount of (IMO) unnecessarily arbitrary variation in when CAs are able to get approved for EV in Mozilla products. Again, the question is policy wise and a moral one. Not going to voice my opinion beyond the explanation from above. Second, we need to triage the EV requests to see which are most suitable for consideration right now. For example, we might privilege cases where the root in question is already in NSS/Mozilla and just needs upgrading for EV, since we can leverage work already done for the original approval. Here I could use help both to do the triage and also to follow up and get the relevant questions asked and answered regarding the CAs we're looking at first. OK, I could pick the first four or five requests from your list and start to work on it...or just assign a few bugs to me and I'll go through them. Whatever you prefer... -- 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: Sorting through EV root CA requests
Frank Hecker wrote: Eddy Nigg (StartCom Ltd.) wrote: Without offending, but does Johnathan has the right background for this? I don't know, but if I remember right his specializations are in different fields... Johnathan and other Mozilla people, e.g., members of the NSS team, have participated actively in CAB Forum meetings and related discussions. IMO they have as good a grasp of the relevant issues as Gerv or I. In General the NSS team has focused on implementability of the standard (on the browser side), and some basic cryptography (key sizes of various certificates). Draft 11 was proposed as a standard in Oct 2006 in order to meet the deadline for inclusion in Vista. Mozilla abstained on that vote due to the closed nature of the spec (it was not publicly available at the time). Objections to the draft up to that point was mainly that it was too restrictive. I would be OK with accepting validations started before June 12, 2007 based on Draft 11. Webtrust's chart indicates that their validations switched to 1.0 immediately on it's approval by the CAB (including mid-evaluation for those that weren't completed before June 12, 2007). This is pretty much true of all early EV issuers, and should clear itself out once the revaluations are completed. bob smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Sorting through EV root CA requests
Hi Bob, Robert Relyea wrote: Draft 11 was proposed as a standard in Oct 2006 in order to meet the deadline for inclusion in Vista. Mozilla abstained on that vote due to the closed nature of the spec (it was not publicly available at the time). Objections to the draft up to that point was mainly that it was too restrictive. I would be OK with accepting validations started before June 12, 2007 based on Draft 11. Webtrust's chart indicates that their validations switched to 1.0 immediately on it's approval by the CAB (including mid-evaluation for those that weren't completed before June 12, 2007). This is pretty much true of all early EV issuers, and should clear itself out once the revaluations are completed. Do you mean before or after? If before, how much before that date? -- 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: Sorting through EV root CA requests
Robert Relyea wrote: Draft 11 was proposed as a standard in Oct 2006 in order to meet the deadline for inclusion in Vista. Mozilla abstained on that vote due to the closed nature of the spec (it was not publicly available at the time). Objections to the draft up to that point was mainly that it was too restrictive. You've jogged my memory, that's my recollection as well: that some of the stuff in draft 11 was seen as unnecessary in practice, and CAs wanted some relief on specific points. If that's the case then that bolsters the argument that accepting audits against draft 11 doesn't represent a real issue in terms of user security. I would be OK with accepting validations started before June 12, 2007 based on Draft 11. Webtrust's chart indicates that their validations switched to 1.0 immediately on it's approval by the CAB (including mid-evaluation for those that weren't completed before June 12, 2007). That's somewhat at variance with the statement on the CAB Forum web site, that the final WebTrust EV criteria were effective September 30, 2007. But I don't think we need to parse the dates that closely. My proposal would rather be just to accept all valid WebTrust EV audits, whether against the draft or final criteria/guidelines, for all CA EV applications submitted before a certain date. To allow for any additional applications that come in, I'd set the date at some point in the future, maybe July 1 2008; after that we'd revert the policy to specify the final criteria and guidelines only, to emphasize that the drafts are obsolete and deprecated. 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: Sorting through EV root CA requests
Frank Hecker wrote: As I wrote previously, I don't want to parse this too closely, but I think the situation may be as follows: * WebTrust EV audits completed by June 12, 2007 would have used the draft 11 guidelines. * WebTrust EV audits started before June 12, 2007 but completed after that date would have used the draft 11 guidelines and then switched to the 1.0 guidelines after their adoption. * WebTrust EV audits started after June 12, 2007 would have used the 1.0 guidelines. In terms of revising our policy I don't think it really matters. We'd just consider the draft 11 and 1.0 guidelines to both be acceptable (at least until some future date), and we wouldn't need to determine exactly which version of the guidelines was used when. To make this more concrete, I'll file a bug with a proposed policy change to reflect this line of thinking. OK. Please send me the bug number for reference, thanks! -- 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: Sorting through EV root CA requests
Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker wrote: snip To make this more concrete, I'll file a bug with a proposed policy change to reflect this line of thinking. OK. Please send me the bug number for reference, thanks! https://bugzilla.mozilla.org/show_bug.cgi?id=413545 A proposed revision to the policy is attached (as a patch to the existing policy). 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: Sorting through EV root CA requests
Eddy Nigg (StartCom Ltd.) wrote: What's the time frame for this? Time frame for what? I plan to work intensively on EV requests this week, and get as many as I can on the path to approval as soon as I can. So if you have comments, either general or on any of the specific requests, please submit them now. 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: Sorting through EV root CA requests
Frank Hecker wrote: Eddy Nigg (StartCom Ltd.) wrote: What's the time frame for this? Time frame for what? I plan to work intensively on EV requests this week, and get as many as I can on the path to approval as soon as I can. OK So if you have comments, either general or on any of the specific requests, please submit them now. Well, you said: If anyone wants to double-check my conclusions above please feel free; I could use some help with this. So I asked in reply what the time frame is...as *you* know, it takes quite some time to go through just the basic informations, verify some of it, make notes and follow up on stuff which isn't clear...me willing to help and spare some time for this, but it really somewhat depends on how much time we've got. -- 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: Sorting through EV root CA requests
Eddy Nigg (StartCom Ltd.) wrote: Well, you said: If anyone wants to double-check my conclusions above please feel free; I could use some help with this. So I asked in reply what the time frame is...as *you* know, it takes quite some time to go through just the basic informations, verify some of it, make notes and follow up on stuff which isn't clear...me willing to help and spare some time for this, but it really somewhat depends on how much time we've got. Ah ok, my apologies for not understanding the context of the question. I'll give you a two-part answer regarding where I could use help, and when: First, we need to reach a consensus on what to do about CAs audited under the draft WebTrust EV criteria. AFAICT right now if we applied our policy strictly we wouldn't have any CAs that comply with it, and may not have any for some time to come (per my point below). However it's not clear to me a) if the differences between the draft WebTrust EV criteria and the final WebTrust EV criteria are actually that significant, and b) if they are significant, to what extent they're security-relevant. (Because after all our ultimate concern is users' security, not guidelines and criteria per se.) This is where I could use help from people more familiar with the nitty-gritty details of the WebTrust EV criteria and the underlying EV guidelines. If the differences really aren't that relevant from a security perspective then arguably we should consider a provisional approval scheme like I mentioned earlier. We aren't talking about the case of audited vs. not audited; all the CAs in question have been audited, albeit under slightly different criteria than in our current policy. Also, a CA that got audited prior to 2007/09/30 (when the final WebTrust EV criteria went into effect) is not instantly going to re-do its audit; for reasons of cost and other factors it's typically going to wait for the next audit cycle. This introduces a fair amount of (IMO) unnecessarily arbitrary variation in when CAs are able to get approved for EV in Mozilla products. In any case, IMO we need to resolve this issue one way or another very shortly, because it affects everything else related to consideration of the outstanding EV requests. Second, we need to triage the EV requests to see which are most suitable for consideration right now. For example, we might privilege cases where the root in question is already in NSS/Mozilla and just needs upgrading for EV, since we can leverage work already done for the original approval. Here I could use help both to do the triage and also to follow up and get the relevant questions asked and answered regarding the CAs we're looking at first. Does this help answer your question? Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
