Skip to content

Add Relevant Standards and No Exceptions Policies #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add Relevant Standards and No Exceptions Policies #6

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0231ed8
Add Relevant Standards and No Exceptions Policies
kasirota Oct 10, 2025
abac317
Update Requirements.md
kasirota Oct 28, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 12 additions & 1 deletion Requirements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,18 @@ The Microsoft Trusted Root Program enables customers to trust Windows products b

**2.1.12.** Program Participants agree that Microsoft may contact customers that Microsoft believes may be substantially impacted by the pending removal of a root CA from the Program.

**2.1.13.** If Microsoft, in its sole discretion, identifies a certificate whose usage or attributes are determined to be contrary to the objectives of the Trusted Root Program, Microsoft will notify the responsible CA and request that it revokes the certificate. The CA must either revoke the certificate or request an exception from Microsoft within 24 hours of receiving Microsoft's notice. Microsoft will review submitted material and inform the CA of its final decision to grant or deny the exception at its sole discretion. In the event that Microsoft doesn't grant the exception, the CA must revoke the certificate within 24 hours of the exception being denied.
**2.1.13.** If Microsoft, in its sole discretion, identifies a certificate whose usage or attributes are determined to be contrary to the objectives of the Trusted Root Program or the Baseline Requirements, Microsoft will notify the responsible CA and request that it revokes the certificate. The CA must revoke the certificate within 24 hours of receiving Microsoft's notice.

**2.1.14.** CAs trusted by Microsoft products must comply with the most recent and applicable Baseline Requirements (BRs) for the type of certificate they issue, as defined by the CA/Browser Forum and other relevant industry bodies. This includes, but is not limited to: TLS Server Authentication Certificates – CA/Browser Forum Baseline Requirements for TLS, Code Signing Certificates – CA/Browser Forum Code Signing Baseline Requirements, S/MIME Certificates – CA/Browser Forum S/MIME Baseline Requirements. Where Microsoft policy imposes stricter requirements than the applicable BRs, CAs are expected to adhere to Microsoft’s requirements.

**2.1.15.** No single organization, including Microsoft, has the authority to grant exceptions to the Baseline Requirements. Microsoft will not grant exceptions under any circumstances.

**2.1.16.** TRP Participants MUST adhere to the latest version of the CCADB Policy.

**2.1.17.** All publicly-trusted subscriber TLS certificates must be logged within 24 hours to a Certificate Transparency (CT) Log that complies with RFC 6962, "Certificate Transparency." Certificates issued must include at least two SCTs (Signed Certificate Timestamp) from distinct CT Logs that were Qualified, Usable, or ReadOnly at the time of check.
Copy link

@mcpherrinm mcpherrinm Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this implying it is required for the actual certificate to be logged, or is logging pre-certificates sufficient here? The wording implies it may not be sufficient to log pre-certificates.

Copy link
Contributor Author

@kasirota kasirota Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pre-certificates are acceptable. I will update this in the requirement.

Copy link

@aarongable aarongable Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it intentional that this requirement forbids the use of static-ct-api logs?

Copy link
Contributor Author

@kasirota kasirota Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we will modify the language to allow for static-ct-api logs.

Copy link

@robstradling robstradling Oct 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's really great to see Microsoft moving towards 'requiring CT', but I have quite a few concerns about 2.1.17 as currently worded. I think it's absolutely vital to carefully consider the other CT / Root Program policies that are in effect in the CT/WebPKI ecosystem in order to ensure that there are no unintended incompatibilities that would hinder interoperability and hurt the ecosystem. With that in mind:

  1. The Chrome CT Policy is not part of the Chrome Root Program Policy, and the Apple CT Policy is not part of the Apple Root Certificate Program Requirements. In both cases, CT compliance is necessary to avoid a browser warning; but since CT non-compliance is not a root program policy matter, it is also not an "incident" for the CA. (The Chrome CT Policy puts it this way: "The issuance of certificates that are not CT compliant is not considered mis-issuance or a violation of Chrome’s root program; such certificates will simply fail to validate in CT-enforcing versions of Chrome"). So it seems strange to me that Microsoft is proposing to add the language in 2.1.17 directly to the Microsoft Root Program Requirements. I recommend removing 2.1.17 and creating a Microsoft CT Policy instead.

  2. Whilst it's certainly common for CAs to submit certificates to CT logs on behalf of Subscribers, there is no suggestion in RFC6962 that this action should ever be considered the responsibility of the CA - indeed, section 1 explains that certificates "can be submitted by anyone":

    • Writing "must be logged" in the Microsoft Root Program policy would seem to imply that Microsoft considers this to be the CA's responsibility.
    • Is this "must" deliberately lower-case, rather than RFC2119 UPPER-CASE?
    • If any leaf TLS certificate is not logged within 24 hours, will Microsoft consider this to be an "incident" for the CA?
    • As with my first point, I recommend aligning with existing CT ecosystem practice and not making CT (non-)compliance a root program matter.

  3. Each CT log program maintains its own state information for each log, so (for example) a log could be "Usable" in Apple's log list but "Retired" in Chrome's, or "Qualified" in Chrome's log list but not yet present in Apple's, etc. For "Qualified, Usable, or ReadOnly" in Microsoft policy to be meaningful to CAs and other ecosystem participants, I think it's vital to publish a human-readable Microsoft CT Log List that indicates the state of each participating log according to Microsoft. (The CT Log List currently shipped by Microsoft in authroot.stl is not human-readable and does not identify the state of each log).

  4. Aligning CT Log List updates with (at best) monthly root program updates could delay the propagation of log state changes considerably, which (if/when Microsoft is enforcing CT compliance in Edge) would have a knock-on effect on the rest of the ecosystem. Chrome and Apple are able to publish log list updates more or less immediately, AFAICT.

  5. There needs to be a Microsoft CT Log Policy, so that log operators (i) know how to contact Microsoft to request log removal or submit new log shards and (ii) understand their obligations to Microsoft. If Microsoft expects any logs' Accepted Roots lists to include Root Certificates that are present in the Microsoft Root Store but absent from the Chrome and/or Apple Root Stores, then Microsoft needs to state this as a requirement in a CT Log Policy.

  6. "complies with RFC 6962". Is the lack of support for Static CT logs intentional? The Chrome and Apple CT Policies currently both require two SCTs, of which only one needs to be from an RFC6962 log. I recommend aligning with that approach.

  7. RFC6962 defines 3 mechanisms for distributing SCTs and in section 3.3 requires that "TLS clients MUST implement all three mechanisms". One of these mechanisms is the embedding of Precertificate SCTs in the corresponding Certificates; and as written, "Certificates issued must include at least two SCTs" requires that that mechanism is always used, which would effectively outlaw the other two SCT distribution mechanisms (OCSP Stapling and the signed_certificate_timestamp TLS extension) across the entire CT ecosystem. I recommend supporting all of the mechanisms that RFC6962 mandates that TLS clients MUST support.

  8. RFC6962 does not require logging of a Certificate when the corresponding Precertificate has already been logged. Your draft language in 2.1.17 says nothing about Precertificates but seems to require that the corresponding Certificates are always logged. Is this deviation from current ecosystem requirements intentional?

  9. Requiring CT compliance for "All publicly-trusted subscriber TLS certificates" seems unlikely to play nicely with the PQC Pilot Program that Microsoft pre-announced at CABForum this week. I'm not aware of any CT log today that supports certificates that are signed by ML-DSA and/or that have ML-DSA public keys. If you do intend to require CT compliance for ML-DSA leaf certificates, I suggest reaching out to CT log operators ASAP to discuss timelines for adding ML-DSA support to logs. Alternatively, you might want to consider not requiring CT compliance for ML-DSA certificates during the 1-year PQC Pilot Program.

Copy link

@timfromdigicert timfromdigicert Oct 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all good comments. Also, given the complexity, there needs to be a reasonable effective date and time to communicate the transition to affected customers.

Copy link
Contributor Author

@kasirota kasirota Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted. We really appreciate the feedback, Rob. A lot to get through but @timfromdigicert I can state this will not be requirement from November 15 - we will extend accordingly.


**2.1.18.** Certificate Authorities must update their Certificate Policy (CP) and Certification Practice Statement (CPS) documents before applying any change in operations. The updated documents must be made publicly available and communicated to Microsoft. CAs should provide these updates by updating the CCADB. CAs MUST update the changelog in their CP/CPS documents with what changes were made.



## 3. Program Technical Requirements
Expand Down