Bugzilla

(In reply to Microsoft PKI Services from comment #130)
> As mentioned in [comment 126](https://bugzilla.mozilla.org/show_bug.cgi?id=1965612#c126), numerous investments and improvements have been made as part of remediation of this bug to address the root causes of not being able to meet the stipulated timelines. We stay committed to meeting BR requirements for revocation timelines and readiness.

Previously we were told that Microsoft PKI were not ready to stick by BR requirements until March 2025 at the earliest:
>Over the past six months, we have made considerable progress in addressing the underlying root causes of this bug (CRL partitioning, new CAs, migration to new CAs, lifetime reduction, warm standbys), which are all in various stages of rollout. Once all repair actions are complete, we do expect to be in a much better position to be able to meet the BR stipulated timelines.

**Q1:** Which is true: Microsoft PKI are capable of sticking to BR-mandated timelines as of today, or when "repairs are complete"?

>To address the question around further actions, as part of our regular mass revocation readiness planning, we plan on conducting ongoing testing to measure not only the effectiveness of these repairs, but also the overall preparedness as mandated by [Ballot SC089](https://cabforum.org/2025/07/22/ballot-sc-089-mass-revocation-planning/) (and MRP), and apply learning from those tests as part of continuous improvement.  

**Q2:** Could you clarify what is mandated by SC089, and what is additional as 'MRP'?

> ---
> **Question 2**
> > 2. How did you underestimate the size of the final batch?
> 
> We underestimated the size of the final batch because the CRL drop-off rates were estimations rather than exact calculations (drop off rates are particularly difficult to precisely project given the volume of certificates and frequency of revocations). The Certificate Revocation List reached the 15 MB operational limit mid-week, and did not drop as quickly as projected, which prevented additional revocations until entries age out and space becomes available.

**Q3**: Why was anything involved an estimate? Does Microsoft PKI lack inventory of their certificates issued and plan of action for revocation?

We have already heard claims of 'planned' revocations not accounting for expiration which can not be charitably read in a way compliant with a functional CA.

**Q4**: Given the 15MB limit was entirely fabricated late in the game after claims of a 10MB limit - there was no technical limitation as shown by far larger CRLs in practice [Comment 21](https://bugzilla.mozilla.org/show_bug.cgi?id=1965612#c21). Why is this still being used as an excuse for non-compliance?

> **Question 3**
> > 3. When did you discover this underestimation?
> 
> See response to #2.

The underestimation mentioned in question 2 was in regards to CRL mismatches noticed mid-week. It does not account for hundreds of thousands of expired certificates that were 'planned' to be revoked. This is after over 6 months of alleged planning.

**Q5**: Can Microsoft PKI please explain when they discovered an underestimation would occur for their revocation numbers, without referring to another response?

> **Question 4**
> > 4. How did you discover that you had underestimated?
> See response to #2.

Again, the final batch was hundreds of thousands of certificates bigger. We have no excuse to date as to why November 15th is an absolute cut-off for Microsoft PKI to be capable of revocation until next March. There should be no technical or procedural block for Microsoft PKI to revoke these remaining 85k certificates within 24h or 5d if they make bold claims as to be able to stick by the baseline requirements.

**Q6**: Is there any intention of handling all of the remaining certificates prior to March 2026? If not, why not?

**Q7**: There is no transparency as to whether Microsoft PKI is truly separate from Microsoft's Root Program, what is the functional difference day-to-day on the personnel side?

**Q8**: Can the personnel involved honestly state how many Copilot, or similar, briefly skimmed summaries are posted to this mailing list under the guise of official communications from your compliance team?

**Q9**: Could the above be the actual root cause for these 'estimations' being off when plans have allegedly been drafted from a strict list of certificates to be revoked?

To say there is a lack of trust or reliability in actions to date is to be overly generous. Please try to show you are at least putting a modicum of effort into this process.

(In reply to Microsoft PKI Services from comment #130)
> As mentioned in [comment 126](https://bugzilla.mozilla.org/show_bug.cgi?id=1965612#c126), numerous investments and improvements have been made as part of remediation of this bug to address the root causes of not being able to meet the stipulated timelines. We stay committed to meeting BR requirements for revocation timelines and readiness.

Previously we were told that Microsoft PKI were not ready to stick by BR requirements until March 2026 at the earliest:
>Over the past six months, we have made considerable progress in addressing the underlying root causes of this bug (CRL partitioning, new CAs, migration to new CAs, lifetime reduction, warm standbys), which are all in various stages of rollout. Once all repair actions are complete, we do expect to be in a much better position to be able to meet the BR stipulated timelines.

**Q1:** Which is true: Microsoft PKI are capable of sticking to BR-mandated timelines as of today, or when "repairs are complete"?

>To address the question around further actions, as part of our regular mass revocation readiness planning, we plan on conducting ongoing testing to measure not only the effectiveness of these repairs, but also the overall preparedness as mandated by [Ballot SC089](https://cabforum.org/2025/07/22/ballot-sc-089-mass-revocation-planning/) (and MRP), and apply learning from those tests as part of continuous improvement.  

**Q2:** Could you clarify what is mandated by SC089, and what is additional as 'MRP'?

> ---
> **Question 2**
> > 2. How did you underestimate the size of the final batch?
> 
> We underestimated the size of the final batch because the CRL drop-off rates were estimations rather than exact calculations (drop off rates are particularly difficult to precisely project given the volume of certificates and frequency of revocations). The Certificate Revocation List reached the 15 MB operational limit mid-week, and did not drop as quickly as projected, which prevented additional revocations until entries age out and space becomes available.

**Q3**: Why was anything involved an estimate? Does Microsoft PKI lack inventory of their certificates issued and plan of action for revocation?

We have already heard claims of 'planned' revocations not accounting for expiration which can not be charitably read in a way compliant with a functional CA.

**Q4**: Given the 15MB limit was entirely fabricated late in the game after claims of a 10MB limit - there was no technical limitation as shown by far larger CRLs in practice [Comment 21](https://bugzilla.mozilla.org/show_bug.cgi?id=1965612#c21). Why is this still being used as an excuse for non-compliance?

> **Question 3**
> > 3. When did you discover this underestimation?
> 
> See response to #2.

The underestimation mentioned in question 2 was in regards to CRL mismatches noticed mid-week. It does not account for hundreds of thousands of expired certificates that were 'planned' to be revoked. This is after over 6 months of alleged planning.

**Q5**: Can Microsoft PKI please explain when they discovered an underestimation would occur for their revocation numbers, without referring to another response?

> **Question 4**
> > 4. How did you discover that you had underestimated?
> See response to #2.

Again, the final batch was hundreds of thousands of certificates bigger. We have no excuse to date as to why November 15th is an absolute cut-off for Microsoft PKI to be capable of revocation until next March. There should be no technical or procedural block for Microsoft PKI to revoke these remaining 85k certificates within 24h or 5d if they make bold claims as to be able to stick by the baseline requirements.

**Q6**: Is there any intention of handling all of the remaining certificates prior to March 2026? If not, why not?

**Q7**: There is no transparency as to whether Microsoft PKI is truly separate from Microsoft's Root Program, what is the functional difference day-to-day on the personnel side?

**Q8**: Can the personnel involved honestly state how many Copilot, or similar, briefly skimmed summaries are posted to this mailing list under the guise of official communications from your compliance team?

**Q9**: Could the above be the actual root cause for these 'estimations' being off when plans have allegedly been drafted from a strict list of certificates to be revoked?

To say there is a lack of trust or reliability in actions to date is to be overly generous. Please try to show you are at least putting a modicum of effort into this process.