MRSP 2.9: Issue #250: Clarify MRSP 5.3.2 to expressly include revoked CA certificates

615 views
Skip to first unread message

Ben Wilson

unread,
Jul 5, 2023, 3:28:41 PM7/5/23
to dev-secur...@mozilla.org

All,

This email opens up discussion of our proposed resolution of GitHub Issue #250. 

Currently, MRSP section 5.3.2 (Intermediate CA Certificates must be publicly disclosed and audited) requires that all types of intermediate CAs capable of issuing server certificates and email certificates be disclosed in the CCADB. (Other root stores may have their own requirements about reporting other types of CAs – e.g. document-signing, code-signing, etc., so this discussion is not about CCADB disclosure for those types of CAs.)

Last year, we added language that required CCADB reporting of name-constrained CAs with the following language, “Name-constrained CA certificates that are technically capable of issuing working server or email certificates that were exempt from disclosure in previous versions of this policy MUST be disclosed in the CCADB prior to July 1, 2022.”  Our intent at that time was that it also included CA certificates that have been revoked but not yet expired. (One of several reasons for requiring disclosure of revoked CAs is that we use this information for OneCRL.)  However, there was some confusion last year about this intention because a revoked CA is not “technically capable of issuing working server or email certificates.”  See discussion - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XM7hWqmqmPw/m/MEVlq7REAAAJ

The purpose of the proposal below is to clarify that revoked intermediate CAs must be disclosed in the CCADB. Thus, “including such CA certificates that are revoked but not yet expired” would be added to the first sentence of MRSP section 5.3.2.  It is also proposed that we remove “prior to July 1, 2022” because that date has passed.

-----MRSP Proposal Begin-----

The operator of a CA certificate included in Mozilla’s root store MUST publicly disclose in the CCADB all CA certificates they issue that chain up to that CA certificate trusted in Mozilla’s root store that are technically capable of issuing working server or email certificates, including such CA certificates that are revoked but not yet expired and those CA certificates that share the same key pair whether they are self-signed, doppelgänger, reissued, cross-signed, or other roots. The CA operator with a certificate included in Mozilla’s root store MUST disclose such CA certificate within one week of certificate creation, and before any such CA is allowed to issue certificates. Name-constrained CA certificates that are technically capable of issuing working server or email certificates that were exempt from disclosure in previous versions of this policy MUST also be disclosed in the CCADB.

-----MRSP Proposal End-----

Please review this proposal and provide questions or comments here in this thread.

Thanks,

Ben and Kathleen

Ben Wilson

unread,
Aug 18, 2023, 1:56:57 PM8/18/23
to dev-secur...@mozilla.org
All,
Here is the currently proposed language for the first paragraph of MRSP section 5.3.2:

The operator of a CA certificate included in Mozilla’s root store MUST publicly disclose in the CCADB all CA certificates it issues that chain up to that CA certificate trusted in Mozilla’s root store that are technically capable of issuing working server or email certificates, including such CA certificates that are revoked but not yet expired and those CA certificates that share the same key pair whether they are self-signed, doppelgänger, reissued, cross-signed, or other roots. The CA operator with a certificate included in Mozilla’s root store MUST disclose such CA certificate in the CCADB within one week of certificate creation, and before any such CA is allowed to issue certificates. Name-constrained CA certificates that are technically capable of issuing working server or email certificates that were exempt from disclosure in previous versions of this policy MUST also be disclosed in the CCADB, but the submission of an audit report under section 3.1 of this policy is not required.

The most recent changes made to this section 5.3.2 may be reviewed here:

Unless there are additional comments, I am assuming that discussion on this topic is now closed.

Thanks,

Ben
Reply all
Reply to author
Forward
0 new messages