Closed Bug 1397960 Opened 7 years ago Closed 6 years ago

DigiCert / Telecom Italia: Several Problems

Categories

(CA Program :: CA Certificate Compliance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: jeremy.rowley)

References

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

This bug has been separated out from Bug #1389172 to request an incident report specific to this subCA.

Telecom Italia Trust Systems (TI Trust Systems / TI Systems)

  a) Serial numbers > 20 octets
    - See Bug #1389172: Comments 0, 1, 4, 5, 7, 9, 10, 13
    - Remediation
      - None performed.
      - Comment 4 and Comment 5 proposed revoking this sub-CA, but Comment 9 walked this back and indicated DigiCert would not be revoking.
      - Comment 7 suggests standing up a new sub-CA, and expanded upon in Comment 13. Neither of these remedy the problems with the existing CAs.

  b) Common Names not in SANs
    - See Bug #1389172: Comments 2, 3, 6, 9, 10, 13
    - Remediation
      - None performed. See above.

  c) Reserved/Intranet domain name
    - See Bug #1389172: Comments 3, 6, 9, 10, 13
    - Remediation
      - None performed. See above.

  d) Invalid DNS names
    - See Bug #1389172: Comments 3, 6, 9, 10, 13
    - Remediation
      - None performed. See above.


For the problems listed above, please provide an incident report as described here:

https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
Flags: needinfo?(jeremy.rowley)
1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

a)  m-d-s-p list on 5-Aug-2017 from Jonathan Rudenberg
b)  email on 5-Aug-2017 from Alex Gaynor
c)  m-d-s-p post and direct email 12-Aug-2017 from Jonathan Rudenberg
d)  m-d-s-p list 12-Aug-2017 from Jonathan Rudenberg
    
2.  A timeline of the actions your CA took in response.
a)  revocation email from Jeremy Rowley to Telecom Italia on 8/5 resulting in revocation of certificates 
b)  revocation email from Jeremy Rowley to Telecom Italia on 8/5 resulting in revocation of certificates 
c)  revocation email from Ben Wilson to Telecom Italia on 8/12 resulting in revocation of certificates 
d)  revocation email from Ben Wilson to Telecom Italia on 8/14 resulting in revocation of certificates 
The above, followed by numerous emails between DigiCert and Telecom Italia, emails by DigiCert to the m-d-s-p list and posts to https://bugzilla.mozilla.org/show_bug.cgi?id=1389172.  Key Ceremony conducted on 24-August-2017 and telephone call between DigiCert and Telecom Italia on 6-September-2017.
    
3.  Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
Telecom Italia is issuing TLS/SSL certificates from DigiCert's systems and not the TI Trust Technologies Global CA.
    
4.  A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
a)  See https://misissued.com/batch/2/
b)  See https://misissued.com/batch/1/
c)  See https://misissued.com/batch/8/
d)  See https://misissued.com/batch/9/
    
5.  The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
a)  See https://misissued.com/batch/2/
b)  See https://misissued.com/batch/1/
c)  See https://misissued.com/batch/8/
d)  See https://misissued.com/batch/9/
    
6.  Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Bugs were latent, undiscovered in operation of Unicert CA software and were unknown until discovered by Jonathan Rudenberg. 
    
7.  List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
On 24-August-2017 DigiCert created an internal CA for Telecom Italia, and Telecom Italia has transitioned to the DigiCert platform which does not issue certificates with the defects listed above under a) b) c) and d).
Given that Telecom Italia has transitioned to a new CA platform, but the existing CA platform does not comply with the Baseline Requirements (per "latent, undiscovered in operation of Unicert CA"), will the TI Trust Technologies Global CA be revoked?

If it will not be revoked, what guarantees does DigiCert have that the CA is technically incapable of causing new issuance (and not simply "contractually prohibited" or "We'll be unhappy if they do")
The Sub CA will be revoked and added to OneCRL.  However, we are still trying to figure out the revocation date. Initially, I proposed Sep 15th as that date, but they will need to more time to transition. We are pushing for an aggressive time-frame and will provide an updated date soon. 

Until revoked, the only guarantee we have of them not issuing is "We'll be unhappy if they do". Note, there are several sub CAs in the "no more issuance" category. The inadequacy of control to ensure non-issuance is one reason I asked about adding single intermediates to mandatory CT. We have started requiring some Sub CAs to submit the entire corpus of issued certificates to us for evaluation.  We don't have any assurance that this is the entire corpus other than cross-referencing CT.
Flags: needinfo?(jeremy.rowley)
FYI - they didn't like the Sep 15th date.  We've pushed it back to Oct 31 for OneCRL and Dec 31 for revocation. We're waiting to hear back from them. They are in the process of migrating.
Jeremy: The Baseline Requirements (Section 4.9.1.2) requires the revocation of unconstrained subordinate CAs for a number of reasons, which have been exercised by TI Trust Systems.

At present, it is questionable whether the community has sufficient insight from the answers in Question #6 and Question #7 to be sufficiently assured that the issues have been resolved, or that issuance by TI Trust Systems is no longer possible.

We have routinely seen CAs contractually prohibited from issuing still issuing (Unicredit is an example of this). In asking the community to evaluate whether or not the mitigation is sufficient, it is important to help the community understand why there is not existing or additional risk from the continued trust.

In discussions with other CAs, one proposal put forward is to ensure the CA is technically prohibited from issuance. For example, having DigiCert assume responsibility for providing the OCSP and CRL services (See 4.9.1.2 p8). Have you explored this as a viable option in order to limit the scope of issuance, by transferring key material to DigiCert and DigiCert running OCSP/CRL services? This can provide sufficient assurance (or demonstrate sufficient attempt to mitigate that risk) to avoid revocation.
Yes - having us operate the key material is an option we gave them.  We are waiting to hear back on which they would prefer (revocation or transfer).  TI Trust did revoke all impacted certificates, but I agree there is insufficient information to answer 6 and 7. Would a contract suffice as evidence of non-issuance going forward? I'm not sure what to do to give sufficient assurances while helping TI Trust to  to migrate and still moving towards revocation.
A contract was provided in several past incidents, but failed to ensure the necessary controls were in place. I defer to the Module Owner as to whether a contract would be sufficient going forward, given these issues.
I think our general position is that a contract is not sufficient. We would want to add a cert to OneCRL. However, I don't think OneCRL has a "notAfter" option for distrust, so it would be a total distrust.

Gerv
Hi Jeremy, given Comment #8, do you have any updates?
Flags: needinfo?(jeremy.rowley)
As an update, Telecom Italia is in the process of moving its approximately 2,200 certificates to DigiCert's platform.  Currently they have 881 certificates that they have been able to move over from the TI Trust CA to a DigiCert CA.
Approximately 300 Certificates left to move over. These will take a little longer than the first 2000 because of language issues.  We pushed the OneCRL back until end of Nov to give them a little more time and because no new certs should be coming off the issuing CA.
Flags: needinfo?(jeremy.rowley)
Jeremy or Ben: Please provide an update. Can we add this subordinate to OneCRL now? If so, please specify the certificate(s) to add.

Also, are these the same subordinates being discussed in bug 1304895?
Flags: needinfo?(jeremy.rowley)
Flags: needinfo?(ben.wilson)
Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254
QA Contact: gerv → wthayer
(In reply to Wayne Thayer [:wayne] from comment #12)
> Jeremy or Ben: Please provide an update. Can we add this subordinate to
> OneCRL now? If so, please specify the certificate(s) to add.
> 

These have been added to OneCRL per https://bugzilla.mozilla.org/show_bug.cgi?id=1437038. 

> Also, are these the same subordinates being discussed in bug 1304895?

Yes - that one can be closed, too.
Flags: needinfo?(ben.wilson)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Flags: needinfo?(jeremy.rowley)
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.