338552 - Add StartCom CA certificate to NSS

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[Frank Hecker]

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.

Comment 1

[Frank Hecker]

Attachment: 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.

Comment 2

[Evaldo Gardenali]

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?).

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Reassigning bug to default assignee until we can figure out who will do this.

Comment 4

[Frank Hecker]

(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.)

Comment 5

[Eddy Nigg (StartCom)]

Attachment: 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 6

[Nelson Bolyard (seldom reads bugmail)]

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 7

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 8

[Eddy Nigg (StartCom)]

(In reply to comment #7)
> (From update of attachment 223625 [details] [diff] [review] [edit])

OK, tried it again with your instructions (I hope the path is correct). Please verify and check...

Comment 9

[Eddy Nigg (StartCom)]

Attachment: certdata.txt with StartCom CA

Comment 10

[Eddy Nigg (StartCom)]

Attachment: certdata.c with StartCom CA

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 223666 [details] [diff] [review]
certdata.txt with StartCom CA

These unified diffs have the right format to be reviewed.  Thanks.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

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 13

[Wan-Teh Chang]

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 14

[Wan-Teh Chang]

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.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 16

[Wan-Teh Chang]

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

Comment 17

[Wan-Teh Chang]

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: 1.36.24.1; 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.37.24.1; previous revision: 1.37
done
Checking in nssckbi.h;
/cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v  <--  nssckbi.h
new revision: 1.14.2.1; previous revision: 1.14
done

Comment 18

[Julien Pierre]

Wan-Teh,

Is there any reason to keep this bug open now that the checkin was completed ?

Comment 19

[Wan-Teh Chang]

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.

Comment 20

[Kai Engert (:KaiE:)]

fixed1.8.1 with bug 340724