Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB

[Ben Wilson]

All,

This email introduces another issue selected to be addressed in the next version of the Mozilla Root Store Policy (MSRP), version 2.8, to be published in 2022. (See https://github.com/mozilla/pkipolicy/labels/2.8)

This is Github Issue #229. 

This issue was previously discussed here:  https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XsVpyOGlagE/m/xw8JGJYZBAAJ.

The proposal is that by July 1, 2022, CAs would have to report all technically constrained CAs in the CCADB.

Currently, MRSP § 5.3 says,

"All certificates that are capable of being used to issue new certificates and that directly or transitively chain to a CA certificate included in Mozilla’s CA Certificate Program MUST be operated in accordance with this policy and MUST either be technically constrained or be publicly disclosed and audited.

...

Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate Program MUST disclose in the CCADB all non-technically constrained CA certificates they issue that chain up to that CA certificate trusted in Mozilla’s CA Certificate Program. This applies to all non-technically constrained CA certificates, including those that share the same key pair whether they are self-signed, doppelgänger, reissued, cross-signed, or other roots."

MRSP§ 5.3.2 would require a slight modification, as well.  It states, "All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s root program: ... MUST be publicly disclosed in the CCADB by the CA that has their certificate included in Mozilla’s root program."

I have made an attempt to address this further with some commits in my GitHub repository:

https://github.com/mozilla/pkipolicy/compare/1829373903c8d58246c781ee11ea77d6d386985a...e6550dba22ed38ac6bdd33677a8bf3d2f00e75de

Among other changes, these commits:

1. Move the 4th paragraph in MRSP § 5.3 to the first paragraph of § 5.3.2.

2. Move content from the second bullet in MRSP § 5.3.2 to the first paragraph and eliminate the bulleted list.

3. Delete the sentence, "All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part" because it no longer makes sense in the context of CA certificate disclosure. (Similar language could be added to MRSP §3.1.4, but it already requires publicly available audit documentation.)

Please provide any additional comments you may have regarding the requirement that CAs disclose all subordinate CAs, regardless of whether they are technically constrained.

Thanks,

Ben Wilson

Mozilla Root Program Manager

[Ben Wilson]

I will close discussion on this matter next Friday, 19-Nov-2021. Right now, I am leaning toward adopting the language presented below.

[Kathleen Wilson]

I feel like this item needs to be further discussed...

1) section 1.1 of Mozilla's Root Store Policy (MRSP) limits the scope of the policy to "intermediate certificates which are technically capable of issuing working server or email certificates". So my understanding is that the proposed changes would mean that all intermediate certificates which are technically capable of issuing working server or email certificates must be disclosed in the CCADB, even if they are name constrained. And the proposed changes would NOT mean that intermediate certificates would need to be disclosed in the CCADB when they contain an Extended Key Usage (EKU) extension which does not contain any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection. 

Correct?

2) Just wondering... How do you all think that requiring disclosure of technically-constrained intermediate certs in the CCADB improves security for end-users?

I have made an attempt to address this further with some commits in my GitHub repository:

https://github.com/mozilla/pkipolicy/compare/1829373903c8d58246c781ee11ea77d6d386985a...e6550dba22ed38ac6bdd33677a8bf3d2f00e75de

3) regarding the proposed change in the first paragraph of section 5.3 from

"Certificate Program MUST be operated in accordance with this policy and MUST either be technically constrained or be publicly disclosed and audited."

to

"Certificate Program MUST be operated in accordance with this policy and MUST either be technically constrained or be audited."

My interpretation of the original sentence was: "MUST either be technically constrained or (be publicly disclosed and audited)."

meaning that 3rd-party audit statements would have to be provided.

I do NOT interpret it as meaning that technically-constrained intermediate certificates do not have to be audited at all. The BRs provide specific requirements for the oversight of technically-constrained intermediate certificates that I view as the minimum oversight that should be done for such intermediate certificates.

Therefore, I think that first paragraph should be changed to:

All certificates that are capable of being used to issue new certificates which are technically capable of issuing working server or email certificates and that directly or transitively chain to a CA certificate included in Mozilla’s CA Certificate Program MUST be operated in accordance with this policy and MUST be publicly disclosed in the CCADB.

4) Regarding these changes:

> Move the 4th paragraph in MRSP § 5.3 to the first paragraph of § 5.3.2.

> Move content from the second bullet in MRSP § 5.3.2 to the first paragraph and eliminate the bulleted list.

I think the new text of section 5.3.2  looks OK, except

4.a) Move this to its own paragraph:

Name Constrained CA certificates that were exempt from disclosure in previous versions of this policy MUST be disclosed in the CCADB prior to July 1, 2022.

4.b) We CANNOT delete the sentence, "All disclosure MUST be made freely available..."

We must keep that text, especially for audit statements. So keep this text as a separate paragraph:

All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part.

Thanks,

Kathleen

[Kathleen Wilson]

Looks like I made a copy-and-paste error for item 3, so correcting here:

Therefore, I think that first paragraph should be changed to:

All certificates that are capable of being used to issue working server or email certificates and that directly or transitively chain to a CA certificate included in Mozilla’s CA Certificate Program MUST be operated in accordance with this policy and MUST be publicly disclosed in the CCADB.

[Buschart, Rufus]

Hello!

 

Please find my comments inline.

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Kathleen Wilson
Sent: Dienstag, 16. November 2021 00:24
To: dev-secur...@mozilla.org
Subject: Re: Policy 2.8: MRSP Issue #229: Disclose Technically Constrained CAs in the CCADB

 

 

On Monday, November 15, 2021 at 11:40:58 AM UTC-8 Kathleen Wilson wrote:

I feel like this item needs to be further discussed...

 

1) section 1.1 of Mozilla's Root Store Policy (MRSP) limits the scope of the policy to "intermediate certificates which are technically capable of issuing working server or email certificates". So my understanding is that the proposed changes would mean that all intermediate certificates which are technically capable of issuing working server or email certificates must be disclosed in the CCADB, even if they are name constrained. And the proposed changes would NOT mean that intermediate certificates would need to be disclosed in the CCADB when they contain an Extended Key Usage (EKU) extension which does not contain any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection. 

Correct?

 

[>] This was at least my original intention

 

2) Just wondering... How do you all think that requiring disclosure of technically-constrained intermediate certs in the CCADB improves security for end-users?

 

[>] In my opinion, we will get a much better transparency what is there out in the field. Currently there is a big, big unknown. And this risky since these name-constrained CAs are not externally audited but only undergo sample testing acc. BR 8.7. last two sentences.

 

 

I have made an attempt to address this further with some commits in my GitHub repository:

https://github.com/mozilla/pkipolicy/compare/1829373903c8d58246c781ee11ea77d6d386985a...e6550dba22ed38ac6bdd33677a8bf3d2f00e75de

 

 

3) regarding the proposed change in the first paragraph of section 5.3 from

"Certificate Program MUST be operated in accordance with this policy and MUST either be technically constrained or be publicly disclosed and audited."

to

"Certificate Program MUST be operated in accordance with this policy and MUST either be technically constrained or be audited."

 

My interpretation of the original sentence was: "MUST either be technically constrained or (be publicly disclosed and audited)."

meaning that 3rd-party audit statements would have to be provided.

I do NOT interpret it as meaning that technically-constrained intermediate certificates do not have to be audited at all. The BRs provide specific requirements for the oversight of technically-constrained intermediate certificates that I view as the minimum oversight that should be done for such intermediate certificates.

[>] Yes, but the minimum oversight is slim: assess the adherence to the CP/CPS and perform a sample testing on the issued certificates

 

Therefore, I think that first paragraph should be changed to:

All certificates that are capable of being used to issue new certificates which are technically capable of issuing working server or email certificates and that directly or transitively chain to a CA certificate included in Mozilla’s CA Certificate Program MUST be operated in accordance with this policy and MUST be publicly disclosed in the CCADB.

[>] 👍🏻

 

 

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Infrastructure
Technical Solution & Service Quality 1
IT IN COR TSQ-1
Freyeslebenstr. 1
91058 Erlangen, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com
www.twitter.com/siemens
www.siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

[Ben Wilson]

All,

I came across this section in the wiki that will need to be replaced - https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Non-disclosable_Intermediate_Certificates.

Are there any convincing reasons for keeping the current policy of non-disclosure?

Thanks,

Ben

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AM8PR10MB4305FC5A57B9BDE2FD5B31189E9B9%40AM8PR10MB4305.EURPRD10.PROD.OUTLOOK.COM.

[Kathleen Wilson]

On Friday, November 19, 2021 at 9:56:46 AM UTC-8 Ben Wilson wrote:

All,

I came across this section in the wiki that will need to be replaced - https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Non-disclosable_Intermediate_Certificates.

Are there any convincing reasons for keeping the current policy of non-disclosure?

Thanks,

Ben

 

Hi Ben,

In reading https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Non-disclosable_Intermediate_Certificates I see:

"Such TCSCAs are technically limited from the issuance of TLS/SSL certificates..."

and

"For example, if these subCAs are not used for the production of TLS/SSL certificates, but only identity certificates, then you can make use of the Extended Key Usage extension on the sub-CA to ensure it is present, and that it *lacks* the id-kp-serverAuth and anyExtendedKeyUsage extensions."

So I believe that this wiki page section is still very applicable and should be kept.

However the second paragraph does need to be updated to match section 1.1 of MRSP and this current discussion regarding updating the disclosure requirements for intermediate certificates.

I propose the following text to replace the current second paragraph in this wiki page section:

All certificates that are capable of being used to issue working server or email certificates and that directly or transitively chain to a CA certificate included in Mozilla’s CA Certificate Program MUST be operated in accordance with Mozilla's Root Store Policy and MUST be publicly disclosed in the CCADB. Subordinate CA certificates that do NOT have an Extended Key Usage (EKU) extension which contains any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection are technically limited from the issuance of TLS/SSL and S/MIME certificates, so they are allowed to be operated without full public disclosure of their CP, CPS, and audit documentation.

Thanks,

Kathleen

 

[Tim Hollebeek]

Just a minor nit:

 

It’s not clear to me what the word “working” means in “working server or email certificates”.  It would be better if it were expressed in technical language so CAs know how to determine whether a particular certificate “works” or not.

 

-Tim

--

[Ben Wilson]

Elsewhere in the Policy, we use the phrases "certificate capable of being used for TLS [server authentication] ..." and "certificate capable of being used for digitally signing or encrypting email messages".  Are those better?

Thanks,

Ben

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM8PR14MB52371E2C0CF8FC025D9DC75F832E9%40DM8PR14MB5237.namprd14.prod.outlook.com.

[Ben Wilson]

Alternatively, we could replace "working" with "fully functional" or "operational".  Another adjective that might be possible is "compliant" as in "compliant server certificates", but I wouldn't want to encourage the issuance of non-compliant server or email certificates.

[Corey Bonnell]

Hi Ben,

I think it would be best if there were a rigorous definition of “functional”, similar to the language that was introduced in v2.7 to define “capable” for ICA certificates. Concretely:

 

“A certificate is deemed as functional if there exists at least one certification path that includes the certificate and where all certificates in the path are in scope as defined in Section 1.1 of this Policy”.

 

As an aside, it appears that a requirement to audit TCSCs was included in the commit from two days ago: https://github.com/BenWilson-Mozilla/pkipolicy/commit/7a22e6b935b3da72e419b91f2be9951fb3871406#diff-73f95f7d2475645ef6fc93f65ddd9679d66efa9834e4ce415a2bf79a16a7cdb6R617. Was this intentional?

 

Thanks,

Corey

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZfeKT71w6K61-zNz4cMbCXQxqznSFighhMDLW5rp6vag%40mail.gmail.com.