Per my comments in bug 289077 I'm approving inclusion of the StartCom root CA certificate in NSS/Mozilla; trust bits should be set for SSL server use and S/MIME email use. The bit for object signing should be OFF, as StartCom does not issue object signing certificates at present and is not planning to do so in the foreseeable future. The CA certificate itself is located at <http://cert.startcom.org/ca.crt>. Its SHA-1 fingerprint is 95E6 ADF8 D771 4602 4DD5 6A21 B2E7 3FCD F23B 35FF as listed on the StartCom FAQ page <http://cert.startcom.org/?lang=en&app=110>, and computed by NSS when downloading the cert in question. I've double-checked the fingerprint via a phone call with Eddy Nigg of StartCom.
Created attachment 222630 [details] StartCom root CA certificate in PEM format Attaching a copy of StartCom's root CA certificate as downloaded from <http://cert.startcom.org/ca.crt> today.
Nice! All those policies, all those expensive audits, all those papers, then the fingerprint is checked by phone? Is that the security I should expect from Mozilla? This has really let me a bit upset, and it means I really should disable every CA when I install my desktop, as I use to do. Then I can re-enable the ones I verify/trust, and add the others that dont have 75k/year to throw away with WebTrust but dont rely on phone for security :/ Also, I would obtain the root certificate using offline, trusted medium, since collision attacks are highly improbable and theoretical, but still possible. I dont know what 3-letter-agencies or multi-billion-dollar-companies have in their basements. Sure, the policies and other documents are somewhat necessary/useful, but totally useless once the key is downloaded via untrusted medium and checked via untrusted medium (there are many guys that could fake a voice over the phone, you know?).
Reassigning bug to default assignee until we can figure out who will do this.
(In reply to comment #2) I've had multiple communications with StartCom both via email and by phone, with independent verification of the phone number and email address. I have no reason to believe that my communications have been spoofed or other maliciously manipulated. Note that I'm not opposed on principle to adding additional communications channels to ensure we're getting the right root CA certificates. However I'm not going to do this in an ad hoc manner in this particular instance. Feel free to open a thread on the mozilla.dev.tech.crypto newsgroup (dev-tech-crypto mailing list) on this topic, and we can discuss what particular mechanisms might be appropriate for future use. (Just saying "offline, trusted medium" begs the question somewhat, especially if your threat model includes a TLA as the attacker.)
Created attachment 223625 [details] [diff] [review] Proposed patch for adding StartCom CA This is a proposed patch. Please contact me in case 1) Any developer of Mozilla prefers to make the match 2) The patch has a problem (can not be applied etc) 3) Trust settings are not correct. For No 3, I was not sure and documentation is somewhat unclear concerning that one... Patch should apply to the current cvsroot (checkout): patch -p0 -i startcom-ca.patch
Comment on attachment 223625 [details] [diff] [review] Proposed patch for adding StartCom CA Eddy, you can't give your own patch r+, but you can request review with r? (I've done that for you here.) Your patch should be a "unified diff", the output of cvs diff -u filename
Comment on attachment 223625 [details] [diff] [review] Proposed patch for adding StartCom CA unfortunately, this patch is not in a format that enables bugzilla's patch reviewing tools to work on it. In your cvs source tree, please replace the originaql file with your modified file, then do cvs diff -u9 <filename> > patchfile and then attach patchfile here. Thanks.
(In reply to comment #7) > (From update of attachment 223625 [details] [diff] [review] ) OK, tried it again with your instructions (I hope the path is correct). Please verify and check...
Created attachment 223667 [details] [diff] [review] certdata.c with StartCom CA
Comment on attachment 223666 [details] [diff] [review] certdata.txt with StartCom CA These unified diffs have the right format to be reviewed. Thanks.
Comment on attachment 223667 [details] [diff] [review] certdata.c with StartCom CA I'm not sure why these diffs show different RCS revision numbers. But I'm not sure it's important. Requesting review, on your behalf.
Comment on attachment 223666 [details] [diff] [review] certdata.txt with StartCom CA I verified that this is the same as the output of addbuiltin -n "StartCom Ltd." -t CT,C,c
Comment on attachment 223667 [details] [diff] [review] certdata.c with StartCom CA It's not necessary to review the patch of a generated file. The different RCS file names and revision numbers in the CVS_ID string are an artifact of our checking in this generated file. The generated value is correct; it shows that certdata.c is generated from this version of certdata.txt using this version of certdata.perl. When you check this in to CVS, the file names "certdata.txt" and "certdata.perl" get changed to "certdata.c", and their revision numbers changed to that of certdata.c. The reason we checked this file in to CVS was that we had problem running certdata.perl during the build in the classic Mac build system. Now that all the platforms we support use GNU makefiles, we can go back to running certdata.perl during the build. On the other hand, the CVS_ID string is only used in debug builds, so it may not be worthwhile to make this change.
Wan-Teh, I agree there's no need to review computer generated files IFF you trust their source, e.g. if you generate them yourself. Given that you've obsoleted the certdata.c file, I gather you intend to do just that.
I added StartCom CA to the NSS trunk (NSS 3.12). Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 1.37; previous revision: 1.36 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.tx t new revision: 1.38; previous revision: 1.37 done Checking in nssckbi.h; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h new revision: 1.15; previous revision: 1.14 done
I added StartCom CA to the NSS_3_11_BRANCH (NSS 3.11.2). Note that the CA still needs to be propagated to the Mozilla trunk and the MOZILLA_1_8_BRANCH (for Firefox 2.0). Checking in certdata.c; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.c,v <-- certdata.c new revision: 220.127.116.11; previous revision: 1.36 done Checking in certdata.txt; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/certdata.txt,v <-- certdata.tx t new revision: 18.104.22.168; previous revision: 1.37 done Checking in nssckbi.h; /cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v <-- nssckbi.h new revision: 22.214.171.124; previous revision: 1.14 done
Wan-Teh, Is there any reason to keep this bug open now that the checkin was completed ?
Kai, please remember to add the fixed1.8.1 keyword to this bug when you check in a new NSS_3_11_BRANCH snapshot on the MOZILLA_1_8_BRANCH.
fixed1.8.1 with bug 340724