Re: most secure algorithms
Thanks! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DCSSI Root Inclusion Request
DCSSI’s root inclusion request has been in public discussion for a week now. No issues or concerns about this request have been raised. According to https://wiki.mozilla.org/CA:How_to_apply “If there are no open issues or action items after the first discussion period, and there is general agreement that you comply with our policy requirements, then at the Foundation's discretion the second phase of public discussion may be skipped, the request will be immediately approved, and the request will move into the inclusion phase...” If no issues or concerns are raised in the next couple of days, then I will assume it’s OK to move forward with inclusion. Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Certigna Root Inclusion Request
As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule Certigna is the next request in the queue for public discussion. Certigna (a French CA for the European market) has applied to add one new root CA certificate to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=393166 and in the pending certificates list here: http://www.mozilla.org/projects/security/certs/pending/#Certigna%20of%20Dhimyotis Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=359344 Some quick comments regarding noteworthy points: * The Certigna root has three internally operated subordinated CA’s: Certigna SSL is for SSL-enabled servers, Certigna ID is for authentication and digitally-signed email, and Certigna Chiffrement is for encrypting email. * The CP documents are in French. English translations for relevant sections have been provided and verified. * Certigna has undergone audits by La Sécurité des Technologies de l'Information (LSTI), a private certification body specializing in the field of information security. The audits are current, and the audit statement from 2008 has been verified. This begins the one-week discussion period. After that week, I will provide a summary of issues noted and action items. If there are no outstanding issues, then this request can be approved for inclusion. If there are outstanding issues or action items, then an additional discussion may be needed as follow-up. Kathleen Wilson -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
David, David Stutzman wrote: Jean-Marc Desperrier wrote: You *obviously* never had to handle this CRL : http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL Java programs just can't take it up. And J2EE is by far the most popular application server architecture nowadays. 64 bits J2EE with an enterprise level stability is not a reality today. I can personally attest to the fact that trying to load a CRL with ~250,000 entries destroys Java using the Sun API. I opened a bug with Sun on this issue. I can also tell you that NSS handles CRLs of that size just fine. In fact I was testing a CRL with 1.2 million entries as far back as 2002 when I implemented the CRL cache in NSS 3.6. It does take a lot of RAM, but that is generally not that much of an issue for servers, especially the 64-bit servers we have today. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Ian, Ian G wrote: On 31/1/09 03:56, Kyle Hamilton wrote: The PKIX standard can deal with problems of this extent. If an implementation of the standard cannot, then the implementation is nonconforming, and cannot be expected to interoperate. Do you mean, an implementation should be able to deal with a CRL of any size? I thought the whole OCSP thing was about the realisation that CRLs were basically impractical out in userland? Don't get me wrong, I'm not trying to start an argument here, but it seems pretty tough to blame an application for not being able to cope for something we've already moved on from. You thought wrong. OCSP is not a replacement for CRLs. They both have different use cases. On the server side, OCSP is not suitable, and CRLs must be used. Servers need to be prepared to handle large CRLs. NSS has been able to do so for a long time. On the client side, OCSP makes much more sense. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: most secure algorithms
Ian G wrote: Or: http://www.keylength.com/ is more convenient. Thanks for posting this link again. I had gone to it previously and forgotten it and almost posted to the list to ask about it a couple weeks ago. Dave -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DCSSI Root Inclusion Request
Kathleen, this is not a snark against you, and in fact it is intended to be a very high compliment for the quality of your work. That said, though, I have to snark: Like, OMG! It's a Mozilla Foundation person who actually wants to maintain and deal with the policies! If you haven't read my prior thanks on this list, K, then I thank you from the bottom of my heart for helping to bring order to the chaos and quagmire that the root list has historically suffered. (Also, to the proposal: I am generally in favor of governmental CAs being included, particularly when they're designed to authenticate governmental entities to their constituencies. The design of this particular PKI appears to be better than most of the ones I've looked at before, and I do not have any issues with this inclusion.) -Kyle H On Mon, Feb 2, 2009 at 12:12 PM, kathleen95...@yahoo.com wrote: DCSSI's root inclusion request has been in public discussion for a week now. No issues or concerns about this request have been raised. According to https://wiki.mozilla.org/CA:How_to_apply If there are no open issues or action items after the first discussion period, and there is general agreement that you comply with our policy requirements, then at the Foundation's discretion the second phase of public discussion may be skipped, the request will be immediately approved, and the request will move into the inclusion phase... If no issues or concerns are raised in the next couple of days, then I will assume it's OK to move forward with inclusion. Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DCSSI Root Inclusion Request
On 02/03/2009 01:12 AM, Kyle Hamilton: If you haven't read my prior thanks on this list, K, then I thank you from the bottom of my heart for helping to bring order to the chaos and quagmire that the root list has historically suffered. Seconded from the bottom of another heart ;-) (Also, to the proposal: I am generally in favor of governmental CAs being included, particularly when they're designed to authenticate governmental entities to their constituencies. The design of this particular PKI appears to be better than most of the ones I've looked at before, and I do not have any issues with this inclusion.) Incidentally I've reviewed as always this request too and nothing warranted a comment from my side either. Green light on. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SECOM Trust EV root inclusion request
Frank filed the inclusion request for SecomTrust on Dec. 8th, 2008. As we're almost 2 months past the discussion period for this request, I'd like to reconfirm that there are no other open issues. If there are any open issues, SecomTrust is eager to resolve them asap in order to have the cert included in the next possible version. Your comments would be appreciated. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SECOM Trust EV root inclusion request
On 02/03/2009 03:20 AM, Gen Kanai: Frank filed the inclusion request for SecomTrust on Dec. 8th, 2008. As we're almost 2 months past the discussion period for this request, I'd like to reconfirm that there are no other open issues. If there are any open issues, SecomTrust is eager to resolve them asap in order to have the cert included in the next possible version. Your comments would be appreciated. According to Frank, he has reviewed the audit reports which isn't public. This might be a problem. Also because SecomTrust apparently doesn't use an OCSP responder and isn't required to do so for another year, Firefox has no way to check the certificates status. Firefox intends to treat such certificates as non-EV at least as I understood. This might be another problem. As such there should be an answer in this respect in order to add the SecomTrust EV root or have them correct whatever needs to be corrected. Cross-posting to the bug as well. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SECOM Trust EV root inclusion request
EV requires OCSP. I believe that Mozilla requires OCSP to be functional else it won't pass the internal EV checks to show the green bar (please correct me if I'm wrong). So, by my reading (and subject to the possible misbelief above), even if the root is enabled for EV it won't necessarily work for the EV functionality requested. This may be a marketing sticking point for SecomTrust, but I do not believe that it is a Mozilla issue to resolve. If Mozilla violates the EV guidelines by showing a green bar even when OCSP fails, then this root needs to not be enabled for EV, even if admitted to the root list. -Kyle H On Mon, Feb 2, 2009 at 5:37 PM, Eddy Nigg eddy_n...@startcom.org wrote: On 02/03/2009 03:20 AM, Gen Kanai: Frank filed the inclusion request for SecomTrust on Dec. 8th, 2008. As we're almost 2 months past the discussion period for this request, I'd like to reconfirm that there are no other open issues. If there are any open issues, SecomTrust is eager to resolve them asap in order to have the cert included in the next possible version. Your comments would be appreciated. According to Frank, he has reviewed the audit reports which isn't public. This might be a problem. Also because SecomTrust apparently doesn't use an OCSP responder and isn't required to do so for another year, Firefox has no way to check the certificates status. Firefox intends to treat such certificates as non-EV at least as I understood. This might be another problem. As such there should be an answer in this respect in order to add the SecomTrust EV root or have them correct whatever needs to be corrected. Cross-posting to the bug as well. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SECOM Trust EV root inclusion request
Kyle Hamilton wrote: EV requires OCSP. No, not true. From the EV Guidelines, section 26(a): CAs MUST support an OCSP capability for Subscriber Certificates that are issued after Dec 31, 2010. Mozilla currently includes EV enabled roots of CAs which do not yet provide OCSP respondes for their server certs. I believe that Mozilla requires OCSP to be functional else it won't pass the internal EV checks to show the green bar (please correct me if I'm wrong). It's supposed to do so, but current Firefox versions will happily show the EV indicator if an EV end-entity cert doesn't include an OCSP responder URI (see https://bugzilla.mozilla.org/show_bug.cgi?id=413997 and https://bugzilla.mozilla.org/show_bug.cgi?id=474606, and try https://addons.mozilla.org). Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
