Sorting through EV root CA requests
I've been very remiss in sorting through the various CA requests to have their roots enabled for EV use (or to add new EV-enabled roots), for which I apologize. I'm now pushing to work through these requests as soon as possible. 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: * Secomtrust (394419) * Comodo (401587) * VeriSign (402947) * Valicert/Starfield/Go Daddy (403437) * Digicert (403644) * QuoVadis (403665) * Network Solutions (403915) * GlobalSign (406796) * Thawte (407163) * GeoTrust (407168) * Trustwave (409837, 409838, 409840) These are all entered with the correct product/component (mozilla.org / CA Certificates) and are all assigned to me. If anyone knows of any other EV-related CA requests not in the above list, please post to this group and/or email me. Next step is figuring out the basic parameters for each request. Till later... 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: KISA root CA certificate inclusion request
Hi Frank, Having had a look at this request last summer and followed the entries of Gerv I wanted to ask you some quick question before investing more time on this... As per your comment 61 https://bugzilla.mozilla.org/show_bug.cgi?id=335197#c61 how did you establish the audit performed by the Korean Ministry of Information and Communication to be equivalent to the Webtrust (assuming AICPA) criteria? I can't find any statement in that respect, but perhaps I'm simply missing it. 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 Frank Hecker wrote: Korea Certification Authority Central (KCAC) of the Korean Information Security Administration (KISA) has applied to add three root CA certificates to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=335197 and in the pending certificates list here: http://www.mozilla.org/projects/security/certs/pending/#KISA I have evaluated their request, as per the mozilla.org CA certificate policy: http://www.mozilla.org/projects/security/certs/policy/ and plan to approve this request in two weeks time. If you have any objections, or know of facts which might influence this decision, please make them known before then. Frank ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: KISA root CA certificate inclusion request
Eddy Nigg (StartCom Ltd.) wrote: As per your comment 61 https://bugzilla.mozilla.org/show_bug.cgi?id=335197#c61 how did you establish the audit performed by the Korean Ministry of Information and Communication to be equivalent to the Webtrust (assuming AICPA) criteria? This was stated by MIC in their public statement. I don't know if they used the actual WebTrust criteria themselves, or something else judged equivalent; this is worth asking about, and I have done so. 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: Handshake Exception with Firefox and Jetty Servlet Container
skleinei wrote, On 2008-01-17 09:44: [...] Here are the basics: First of all, I am using version 2.0.0.11. The following parameters might be of interest:security.enable_ssl2=false, security.enable_ssl3=true, security.enable_tls=true The error I am getting after a few clicks or reloads After a few reloads? Are you saying that it works for a while and then fails? Are you able to connect to this site at all when it is using that particular certificate? is Could not establish an encrypted connection because certificate presented by localhost has an invalid signature. OK, so there you have the root of the problem, signatures that cannot be verified and therefore are declared invalid. The problem is either with the signature in one of the certificates in the server's cert chain, or with the signature in the server key exchange message. It would be necessary to examine the entire server cert chain to determine which of those is the case. As I mentioned this happens with DSA certificates only. RSA seems not to cause a problem. I'd guess that your answer to my questions above will be that you are not able to communicate with the https server at all while it is configured to use the DSA certificate. Assuming that guess is right, then the problem is likely that no certificate in the DSA certificate chain contains the PQG parameters for the DSA public key. There also also other possibilities. Complete diagnosis cannot be made without the answers to the questions above and the complete server certificate chain. Please let me know, if there is additional information I can provide. Did you get this DSA certificate from a professionally run CA? or did you make the cert yourself? If you made the DSA cert yourself, then the problem is likely that the certificate (key) is incomplete or incorrectly made. Try some other approach, one that works for you. Explaining all the intricacies of DSA certs is beyond the charter of this newsgroup. Sorry. OTOH, if you can reproduce this with a DSA cert from a real CA, then I'm willing to pursue this further. /Nelson ___ 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
