Thanks for the response.
(In reply to Jeremy Rowley from comment #1)
For clarity, the plan posted was not all externally operated CAs - the plan was to get rid of all externally operated non-browser TLS Sub CAs.
Can you explain what an "externally operated non-browser TLS Sub CA" is? Are these certs being issued from a publicly-trusted hierarchy that don't require public trust?
Can we also clarify what you mean by not working on accelerated replacement? In the bug, we said "CA 8 and CA 9 are signed by CA 5 and are therefore dependent on it remaining valid. CA 8 and CA 9 last leaf certs expire: October 19, 2020; we are working on accelerated replacement." (comment 7) We were currently shooting for end of the year. If the original plan was October 2020 bug, then end of the year cuts off 10 months from the original timeline. We track the progress of shut down pretty closely, but generally we track no-more-issuance more closely that we do get off the Sub CA. Note that ABB is not issuing new certs off this ICA.
So the comment on "accelerated replacement" is relative to the natural expiration of the certificates rather than the BR revocation deadline? I interpreted the statement to mean that the certificates would be revoked quickly, but not within the 7 days permitted by the BRs for misissued subordinate CA certificates.
I would say we haven't been improperly overseeing as much as not properly communicating status changes about status. What we need is a better reporting system to ensure we post to bugzilla regularly, even if that post is "nothing new to report". This will make the monitoring on long-term projects like this bug and the dev projects more transparent. We will draw up a plan and present it here on how we are going to do that better.
Sounds good. Lack of communication is certainly a factor.
We didn't think Mozilla wasn't getting sufficient information given that the deadline for revocation was still over a year away. Apologies if the updates weren't often enough. How often would you like information? We're thinking that the updates would happen every two weeks going forward. Work for you?
I don't see anywhere in the bug that states that the target for revocation was the end of 2019?
Mozilla's incident reporting guidance requests weekly updates unless a Mozilla representative suggests or accepts a different schedule, which typically only happens when there is a plan with dates in place.
Also, can I object to the "failure to supervise"? We supervise that the CAs aren't issuing new certs and ask for updates regularly. We are aware of what is going on. For example, we know they had a change in staff at ABB which impacted the number of certificates revoked this last month, resulting in a relatively low level of replacements. We weren't too concerned because they are still tracking to end of year.
It appears to me that DigiCert did not set deadlines and push ABB to remediate, and per comment #22 didn't proactively seek updates.
I'll post the status of all other TLS CAs in a minute, once I get the data bit more organized. All but one of the non-Quovadis CAs are no longer issuing, I think. Most are already shut down. We don't have timelines for the Quovadis Sub CAs yet, and are working to establish timelines.
Per my first question, does this wind down include all externally operated TLS capable sub CAs trusted by Mozilla?
Another interesting question is what is a reasonable timeline for shut down? We were thinking of letting most of these expire naturally as long as there is no more issuance. Belgium has been inactive for a while. We don't plan on turning off the ICA any time soon. CTJ will be off soon. At that point, we plan on allowing them to sign revocation responses but no new certificates.
The point of my question was to help me understand how long this kind of oversight issue will remain a concern.