Add Relevant Standards and No Exceptions Policies

[kasirota]

No description provided.

[mcpherrinm]

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.

[kasirota]

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

[aarongable]

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

[kasirota]

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

[robstradling]

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.

[timfromdigicert]

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.

[kasirota]

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.