Microsoft PKI Services: Failure to modify policy documents within 365 days
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: Dustin.Hollenback, Assigned: Dustin.Hollenback)
Details
(Whiteboard: [ca-compliance] [disclosure-failure])
How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.
DigiCert notified us via email that the MS PKI policy documents were greater than 365 days old and asked about the status of these documents. We investigated and have confirmed that we have policy documents greater than 365 days old.
Section 2.3 of the Baseline Requirements requires that the CA "annually update a Certificate Policy and/or Certification Practice Statement". Section 4 of the Mozilla Root Store Policy interprets this to mean that the CP and CPS are "updated as necessary at least once every 365 days".
A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
Note: All times in Pacific Time (PT).
2022-01-19: CPS updates were finalized - https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.2.1.pdf
2022-02-15: CP updates were finalized - https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.5.pdf
2023-02-14 12:23 PM: DigiCert notified us that CCADB has policy documents greater than 365 days old
Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
Microsoft PKI Services has not stopped certificate issuance. This is a compliance problem and does not directly impact certificate issuance or cause harm to issued certificates while we publish the updated documents.
In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
No certificates are in scope for this bug.
In a case involving TLS server certificates, 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. It is also recommended that you use this form in your list "https://crt.sh/?sha256=[sha256-hash]", unless circumstances dictate otherwise. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
No certificates are in scope for this bug.
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
We are still investigating these details and expect to have a complete answer within 7 days.
We have been working on Drafts of both documents since the early Fall of 2022 but have failed to complete them by the required date.
List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
We are still investigating these details and expect to have a complete answer within 7 days.
|
||
Updated•2 years ago
|
|
||
Comment 1•2 years ago
|
||
Microsoft PKI Services: Failure to Modify Policy Documents within 365 Days - Update
How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.
DigiCert notified us via email that the MS PKI policy documents were greater than 365 days old and asked about the status of these documents. We investigated and have confirmed that we have policy documents greater than 365 days old.
Section 2.3 of the Baseline Requirements requires that the CA "annually update a Certificate Policy and/or Certification Practice Statement". Section 4 of the Mozilla Root Store Policy interprets this to mean that the CP and CPS are "updated as necessary at least once every 365 days".
A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
Note: All times in Pacific Time (PT).
2022-01-19: CPS updates were finalized:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.2.1.pdf
2022-02-15: CP updates were finalized:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.5.pdf
2023-02-14 12:23 PM: DigiCert notified us that CCADB has policy documents greater than 365 days old.
2023-02-15 12:02 PM: Opened this Bug in Bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1817023.
2023-02-22 11:18 AM: Finalized and published the new versions of the CP and CPS documents to our public repository (https://www.microsoft.com/pkiops/docs/repository.htm).
2023-02-22 11:54 AM: Posted the updated documents to CCADB (created Root Case 00001259 that is open).
2023-02-22 1:43 PM: Added and tested a basic monitoring and alerting script as a safety net to notify in case it is missed by future human review (see details below).
Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
Microsoft PKI Services has not stopped certificate issuance. This is a compliance problem and does not directly impact certificate issuance or cause harm to issued certificates while we publish the updated documents.
In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
No certificates are in scope for this bug.
In a case involving TLS server certificates, 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. It is also recommended that you use this form in your list "https://crt.sh/?sha256=[sha256-hash]", unless circumstances dictate otherwise. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
No certificates are in scope for this bug.
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Policy document management was entirely a manual process managed by a primary individual and backup missed this year. Changes to these policy documents have been in process since early Fall but were not completed, approved, and posted in time.
MS PKI Services had identified human tracking of these dates as a potential risk while reviewing processes last year (summer time) and created a project in our project pipeline to add robust automated monitoring and alerting, but it has not been implemented yet.
A lesson learned is that we should have implemented a basic monitor script instead of waiting for resourcing for the more permanent solution.
We have since implemented that script which compares the list of policy documents from our repository website against a list of known documents and alerts if there is a mismatch. It also alerts if the known documents list ages are older than our thresholds.
List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
MS PKI Services finalized the outdated policy documents and posted them to our public repository and CCADB. We also implemented a basic script to monitor policy document age and alert when any documents are beyond our threshold. We believe these actions have mitigated the incident and ask that this bug be closed.
|
Assignee | |
Comment 2•2 years ago
|
||
There have not been comments/concerns posted since this bug was opened. Is there anything else needed before this can be closed? Thank you.
|
|
||
Updated•2 years ago
|
|
||
Updated•7 months ago
|
Description
•