Re: Is there an ETA yet for when Firefox will use libpkix by default?
I've just filed Bug 764393 to track this request. I've attached an updated version of Nelson's disgusting hack patch. I've also attached a patch for the alternative idea I mentioned. I'd be very grateful if the NSS Team would seriously consider accepting one of these two patches ASAP! On 11/06/12 15:25, Rob Stradling wrote: On 09/06/12 06:03, Wan-Teh Chang wrote: Rob, Please fix the bug in the old certificate verification library. Thanks. Are you going to use the approach outlined by Nelson in bug 479508 and bug 482153? Wan-Teh Hi Wan-Teh. I'm afraid I have nowhere near enough knowledge of NSS internals to turn Nelson's disgusting hack [1] into something that the NSS team would, under normal circumstances, contemplate committing [2]. I've just tested Nelson's 2 patches ([1] and [3]) against mozilla-inbound, and they appear to fix the problem. IMHO, a disgusting hack fix is much better than a non-disgusting, significantly delayed fix. So, how would Mozilla and the NSS Team feel about committing Nelson's 2 patches? [1] https://bugzilla.mozilla.org/attachment.cgi?id=366236 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=482153#c1 [3] https://bugzilla.mozilla.org/attachment.cgi?id=366225 P.S. An alternative idea, for which I am willing to write a patch (if you think this would be preferable to Nelson's disgusting hack): - Define a certHashesToAvoidUsing[] array in nssCertificateArray_FindBestCertificate(). Populate this array with the hashes of all of the UTN-AddTrust and AddTrust-UTN cross-certificates. Make the code consult this list: if a match is found, do not consider this cert to be the best match. P.P.S. 2 other ideas which didn't appear to work... 1. I tried adding the affected UTN--AddTrust cross-certificates as distrusted built-ins, but this didn't help. Presumably distrust is only evaluated after the best certificate chain has been chosen, rather than during the process of chain selection. 2. I tried removing one of the affected UTN root-certificates and then adding the relevant AddTrust-UTN cross-certificate as a built-in. This didn't work either, presumably because the UTN root-certificate was for some reason still listed as a Software Security Device. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Is there an ETA yet for when Firefox will use libpkix by default?
On 09/06/12 06:03, Wan-Teh Chang wrote: Rob, Please fix the bug in the old certificate verification library. Thanks. Are you going to use the approach outlined by Nelson in bug 479508 and bug 482153? Wan-Teh Hi Wan-Teh. I'm afraid I have nowhere near enough knowledge of NSS internals to turn Nelson's disgusting hack [1] into something that the NSS team would, under normal circumstances, contemplate committing [2]. I've just tested Nelson's 2 patches ([1] and [3]) against mozilla-inbound, and they appear to fix the problem. IMHO, a disgusting hack fix is much better than a non-disgusting, significantly delayed fix. So, how would Mozilla and the NSS Team feel about committing Nelson's 2 patches? [1] https://bugzilla.mozilla.org/attachment.cgi?id=366236 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=482153#c1 [3] https://bugzilla.mozilla.org/attachment.cgi?id=366225 P.S. An alternative idea, for which I am willing to write a patch (if you think this would be preferable to Nelson's disgusting hack): - Define a certHashesToAvoidUsing[] array in nssCertificateArray_FindBestCertificate(). Populate this array with the hashes of all of the UTN-AddTrust and AddTrust-UTN cross-certificates. Make the code consult this list: if a match is found, do not consider this cert to be the best match. P.P.S. 2 other ideas which didn't appear to work... 1. I tried adding the affected UTN--AddTrust cross-certificates as distrusted built-ins, but this didn't help. Presumably distrust is only evaluated after the best certificate chain has been chosen, rather than during the process of chain selection. 2. I tried removing one of the affected UTN root-certificates and then adding the relevant AddTrust-UTN cross-certificate as a built-in. This didn't work either, presumably because the UTN root-certificate was for some reason still listed as a Software Security Device. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Is there an ETA yet for when Firefox will use libpkix by default?
On 09.06.2012 11:53, Erwann Abalea wrote: Le vendredi 8 juin 2012 22:55:33 UTC+2, Rob Stradling a écrit : [...] Might there be a Firefox 13.x point-release that will enable libpkix by default? Will Firefox 14 enable libpkix by default? Or can you say that enabling libpkix by default will definitely not happen until Firefox 15 or later? What is missing from libpkix to delay its adoption? See the dependency list of https://bugzilla.mozilla.org/show_bug.cgi?id=pkix-default for the list of blocker issues. Any contributions to get those resolved would be highly appreciated. Thanks Kai -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Is there an ETA yet for when Firefox will use libpkix by default?
Le vendredi 8 juin 2012 22:55:33 UTC+2, Rob Stradling a écrit : [...] Might there be a Firefox 13.x point-release that will enable libpkix by default? Will Firefox 14 enable libpkix by default? Or can you say that enabling libpkix by default will definitely not happen until Firefox 15 or later? What is missing from libpkix to delay its adoption? If I understood correctly, it's already used for EV validation, and seems to work, right? If you're reasonably sure it won't happen by Firefox 14, my CTO has asked me to urgently i) attempt to write an ugly kludge of a patch to fix the bug in the old certificate verification library and then ii) petition Mozilla and the NSS team to accept my patch and ship it in Firefox 14 or sooner. You'll have to rewrite the construction path algorithm to avoid duplicates... Bon courage. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Is there an ETA yet for when Firefox will use libpkix by default?
Brian, It has been well over 3 years since the cross-certification looping bug described in Bug #479508 and Bug #634074 was first filed. It was decided that the proper fix was to wait for Firefox to migrate to libpkix by default. We and our customers have been waiting patiently for this fix. The effects of this bug have apparently been getting worse over time, and we don't believe that we can tolerate it for very much longer. Might there be a Firefox 13.x point-release that will enable libpkix by default? Will Firefox 14 enable libpkix by default? Or can you say that enabling libpkix by default will definitely not happen until Firefox 15 or later? If you're reasonably sure it won't happen by Firefox 14, my CTO has asked me to urgently i) attempt to write an ugly kludge of a patch to fix the bug in the old certificate verification library and then ii) petition Mozilla and the NSS team to accept my patch and ship it in Firefox 14 or sooner. Thanks. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Is there an ETA yet for when Firefox will use libpkix by default?
Rob, Please fix the bug in the old certificate verification library. Thanks. Are you going to use the approach outlined by Nelson in bug 479508 and bug 482153? Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
