Re: New intermediate certs and Audit Statements
On 3/24/21 5:32 AM, Rob Stradling wrote: On 9th July 2019, Kathleen wrote: I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. Hi Kathleen. CCADB now automatically shows the following message (when relevant) in red text at the top of each intermediate certificate page: "This certificate was created after the audit period of the current audit statement, so please make sure to include it in the CA's next periodic audit statement." Do you still expect CAs to "use the Public Comment field to indicate that the new certificate will be included in the next audit statements"? Or may we stop doing that now? Thanks. Rob, Thanks for bringing this up. I agree that it is not necessary to use the Public Comment field to indicate that the new certificate will be included in the next audit statements. CAs may stop doing that. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New intermediate certs and Audit Statements
On 9th July 2019, Kathleen wrote: > I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. Hi Kathleen. CCADB now automatically shows the following message (when relevant) in red text at the top of each intermediate certificate page: "This certificate was created after the audit period of the current audit statement, so please make sure to include it in the CA's next periodic audit statement." Do you still expect CAs to "use the Public Comment field to indicate that the new certificate will be included in the next audit statements"? Or may we stop doing that now? Thanks. From: dev-security-policy on behalf of Kathleen Wilson via dev-security-policy Sent: 09 July 2019 22:50 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: New intermediate certs and Audit Statements All, There is some confusion about disclosure of new intermediate certs that are issued to subordinate CAs with currently valid audit statements. Section 5.3.2 of Mozilla's Root Store Policy says: "If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports." I think it is reasonable to assume that the same policy applies to subordinate CAs, such that if the subordinate CA has a currently valid audit report at the time of creation of a new intermediate certificate, then the new certificate MUST appear on the subordinate CA's next periodic audit reports. The confusion is about how to disclose such a new intermediate certificate in the CCADB. I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. (Also, a quick comparison of the cert's Valid-From date and the audit period dates will indicate this situation.) Please let me know if you foresee any problems with this approach. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New intermediate certs and Audit Statements
On 7/9/19 3:17 PM, Ryan Sleevi wrote: On Tue, Jul 9, 2019 at 5:50 PM Kathleen Wilson via dev-security-policy I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. To support this, we have added the "Comments" column to these two reports: https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAuditsCSV Note that if the same policies do not apply to the new sub-CA, it has seemed uncontroversial that some form of new audit is required. Is that consistent with your understanding as well? That is consistent with my understanding as well. I'll make a note to look into this in regards to enforcement in the CCADB, and the above listed reports should probably also be updated to show the CP/CPS data. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New intermediate certs and Audit Statements
On Tue, Jul 9, 2019 at 5:50 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > There is some confusion about disclosure of new intermediate certs that > are issued to subordinate CAs with currently valid audit statements. > > Section 5.3.2 of Mozilla's Root Store Policy says: "If the CA has a > currently valid audit report at the time of creation of the certificate, > then the new certificate MUST appear on the CA's next periodic audit > reports." > > I think it is reasonable to assume that the same policy applies to > subordinate CAs, such that if the subordinate CA has a currently valid > audit report at the time of creation of a new intermediate certificate, > then the new certificate MUST appear on the subordinate CA's next > periodic audit reports. > > The confusion is about how to disclose such a new intermediate > certificate in the CCADB. > > I propose that to handle this situation, the CA may enter the > subordinate CA's current audit statements and use the Public Comment > field to indicate that the new certificate will be included in the next > audit statements. (Also, a quick comparison of the cert's Valid-From > date and the audit period dates will indicate this situation.) > > Please let me know if you foresee any problems with this approach. > That aligns with past discussions [1][2], which resulted in similar uncontroversial proposals [3]. Wayne previously discussed the lifecycle of certificates during past CA/Browser Forum F2Fs [4][5]. With respect to [5], Wayne proposed the uncontroversial "Change #3" for the alignment of audit reports, and this would similarly align the disclosure. This is particularly important to be harmonized, given reports like [6], which provide an important signal to the community about the entities involved with issuance. Note that if the same policies do not apply to the new sub-CA, it has seemed uncontroversial that some form of new audit is required. Is that consistent with your understanding as well? [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/CAaC2a2HMiQ/IKimeW4NBgAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/v8-V2D957tU/BtogJ3rECQAJ [3] https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/ [4] https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/#28-Audit-requirements-over-the-lifecycle-of-a-root [5] https://cabforum.org/2019/05/03/minutes-for-ca-browser-forum-f2f-meeting-46-cupertino-12-14-march-2019/#Audit-requirements-over-the-lifecycle-of-a-Root-CA [6] https://groups.google.com/d/msg/mozilla.dev.security.policy/7bLbgXTf5Ng/l8nmVfzEAwAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
