1381406 - Add StartCom CA root certificates

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[Iñigo]

Attachment: Mozilla application.docx

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063

Steps to reproduce:

StartCom CA has generated new root certificates as part of its remediation plan and now is able to request for inclussion in the Mozilla program

Comment 1

[Iñigo]

Attachment: StartCom BR Self Assessment.xlsx

Comment 2

[Iñigo]

Attachment: StartCom BR Self Assessment.xlsx

Comment 3

[Iñigo]

Attachment: StartCom roots.zip

Comment 4

[Iñigo]

Attachment: WT reports.zip

Comment 5

[Hanno Boeck]

I saw that the private key used by this new root is also used by two intermediate certificates, one of them revoked:
https://crt.sh/?spkisha256=d3b8136c20918725e848204735755a4fcce203d4c2eddcaa4013763b5a23d81f

This seems highly unusual to me and I think it would also violate the BRs (6.1.7. Key Usage Purposes).

Comment 6

[Kathleen Wilson]

Iñigo, I am interested in your response to Comment #5. Please reply here in the bug.

Comment 7

[Rob Stradling]

The "one of them revoked" is https://crt.sh/?id=117764314, which (to make matters worse) StartCom have also "un-revoked" from the CRL.  (See also bug #1369342, although that covers a different set of certificates).

Comment 8

[Rob Stradling]

(In reply to Rob Stradling from comment #7)
> The "one of them revoked" is https://crt.sh/?id=117764314, which (to make
> matters worse) StartCom have also "un-revoked" from the CRL.  (See also bug
> #1369342, although that covers a different set of certificates).

Sorry for the noise.  Please disregard comment #7.

I was looking at the "Last Observed in CRL" timestamp on https://crt.sh/?id=117764314, but I just realized that this field only gets updated when crt.sh actually processes a new CRL.  (crt.sh's CRL monitor has been checking http://crl.startssl.com/sfsca.crl approximately hourly, but has received an HTTP Not Modified response every time since 2017-06-05 13:34:16 UTC; therefore, it's not update the "Last Observed In CRL" timestamp since then).

Comment 9

[Iñigo]

Hi,

StartCom asked to include G3 root CA certificate, SN 3f ad 7f d6 a9 bf b8 3a, shown in crt.sh as #175285894 and also disclosed in the CCADB. This was generated during the key ceremony back in March.

Later, and following Mozilla recommendations, we proceed to cross-sign the new root with the old one just for compatibility reasons. Then we created a cross-signed certificate for this root, in which we use the same key because it´s the same root, for 5 years on april 10th, with SN 7e a4 43 7d 27 fc 85 a0 84 87 69 d6 13 a3 be 6c, which has to be revoked because we had a problem with the coding and not used UTF8, and this is what crt.sh #117764314 indicates. In CCADB is also set as revoked.
So, the following day, we generated a new cross-signed certificate, SN 32 11 e0 6c 2d 8c 9a 39 86 8f 40 60 78 3c b6 01, shown in crt.sh #120339949 and included in the CCADB.

The G3 root has a certificate for 25 years and these 2 (one revoked) had 5 years, just in case, to maintain backwards compatibility during the inclusion process. 

The BRs in section 6.1.7 is about key usages for root CA private keys, and in the exceptions, in point 2 says that certificates for subordinates CAs and cross certificates are allowed, and this is what we have done. It´s the same root that we used to generate those cross certificates. IMHO, there´s no such violation of the BRs.

And it´s not related to what Rob indicates in comment #7.

Regards

Comment 10

[Kathleen Wilson]

Note: Will need to look at full CA Hierarchy for the new roots. For example, see bug #1386894.

Comment 11

[Iñigo]

Hi,

I´ve replied in the bug #1386894 showing that the majority of those certs included there were revoked and there are only a few ones unrevoked due to the use of different curves allowed by the BRs.

Regards

Comment 12

[Kathleen Wilson]

It looks like StartCom is going to stop issuing certificates, so closing this bug.

Reference:
https://groups.google.com/d/msg/mozilla.dev.security.policy/LM1SpKHJ-oc/4nBsP1xJAQAJ