Hi Pedro, I think that the proposed language works with the scenario you present. In other words, you have 455 days after your previous year's audit end date to submit your self assessment to the CCADB. This can be done in conjunction with submitting your audit information in the CCADB using the same "Add/Update Root Request case" that you are using for updating your audit information.
Ben On Thu, Jul 27, 2023 at 9:38 AM Pedro Fuentes <pfuente...@gmail.com> wrote: > I got lost here "CA operators SHOULD submit the link to their > self-assessment at the same time as when they update their audit records > (within 455 calendar days after the CA operator's earliest appearing root > record's "BR Audit Period End Date" for the preceding audit period)." > > Typically we'd open an audit case to update the audit records, and then, > in parallel, we have 90 days to send the self-assessment, based on the end > date of the audit... I don't see then why you add the SHOULD to do it at > the same time. > > Maybe I missed something... > > El jueves, 27 de julio de 2023 a las 17:26:35 UTC+2, Ben Wilson escribió: > >> Thanks, Bruce, >> It would be based on the significance of revisions and compliance dates >> found in the Baseline Requirements and on when the template was updated and >> approved by the participating root stores. >> Ben >> >> On Thu, Jul 27, 2023 at 9:13 AM 'Bruce Morton' via >> dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote: >> >>> Looks good. There might be an issue with the version of the >>> self-assessment template as I don't think the CAs know when it will be >>> updated. Is there a schedule or is this random? >>> >>> On Thursday, July 27, 2023 at 11:01:17 AM UTC-4 Ben Wilson wrote: >>> >>>> Thanks again. >>>> >>>> How about this language? >>>> >>>> CA operators with CA certificates capable of issuing working TLS server >>>> certificates MUST submit a link to their annual [Compliance >>>> Self-Assessment](https://www.ccadb.org/cas/self-assessment) via the >>>> CCADB. The initial annual self-assessment must be completed and submitted >>>> to the CCADB within 90 calendar days from the CA operator's earliest >>>> appearing root record "BR Audit Period End Date" that is after December 31, >>>> 2022. CA operators SHOULD submit the link to their self-assessment at the >>>> same time as when they update their audit records (within 455 calendar days >>>> after the CA operator's earliest appearing root record's "BR Audit Period >>>> End Date" for the preceding audit period). CA operators SHOULD use the >>>> latest available version of the CCADB self-assessment template. CA >>>> operators MUST NOT use a version of the self-assessment template that has >>>> been superseded by more than 90 calendar days before their submission. >>>> >>>> Ben >>>> >>>> On Thu, Jul 27, 2023 at 8:54 AM 'Bruce Morton' via >>>> dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote: >>>> >>>>> Google policy states "The initial annual self assessment must be >>>>> completed and submitted to the CCADB within 90 calendar days from the CA >>>>> owner's earliest appearing root record “BR Audit Period End Date” that is >>>>> after December 31, 2022." You could use the same approach. >>>>> >>>>> Note, that for a CA to submit a root to CCADB, they must have a >>>>> self-assessment. Mozilla also needs a self-assessment for a root inclusion >>>>> request. So, in many cases the first self-assessment is already done. >>>>> >>>>> On Thursday, July 27, 2023 at 10:40:56 AM UTC-4 Ben Wilson wrote: >>>>> >>>>>> Thanks, Bruce. If we took that approach, then the language in MRSP >>>>>> section 3.4 might read, "Effective January 1, 2024, CA operators with CA >>>>>> certificates capable of issuing working TLS server certificates MUST >>>>>> submit >>>>>> their [Compliance Self-Assessment]( >>>>>> https://www.ccadb.org/cas/self-assessment) at least every 455 >>>>>> calendar days (i.e. one year and ninety days) after the CA operator's >>>>>> earliest appearing root record's "BR Audit Period End Date" for the >>>>>> preceding audit period. CA operators SHOULD submit the Compliance >>>>>> Self-Assessment to the CCADB at the same time as when they update their >>>>>> audit records. CA operators SHOULD use the latest available version of >>>>>> the >>>>>> CCADB self-assessment template. A CA operator MUST NOT use a version of >>>>>> the >>>>>> self-assessment template that has been superseded by more than 90 >>>>>> calendar >>>>>> days before its submission." >>>>>> >>>>>> But when should we make the first self-assessments due? Should they >>>>>> be due on or before January 1, 2024, and thereafter the proposed formula >>>>>> kicks in? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ben >>>>>> >>>>>> On Thu, Jul 27, 2023 at 6:55 AM 'Bruce Morton' via >>>>>> dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote: >>>>>> >>>>>>> Hi Ben, >>>>>>> >>>>>>> It would be great to get your feedback on my proposal above as I >>>>>>> would like to put this into a human process which is kind of analog. The >>>>>>> 365/366 proposal means we would need to do it, say every 330 days to >>>>>>> ensure >>>>>>> we stay compliant. This would mean the schedule would continue to move >>>>>>> to >>>>>>> the left. It is also frustrating that both Google and Mozilla have a >>>>>>> policy >>>>>>> on this requirement. In fact, I made a similar comment to Google and got >>>>>>> this response, *“Subsequent annual submissions must be made no >>>>>>> later than 455 calendar days (i.e., one year and ninety days) after the >>>>>>> CA >>>>>>> owner's earliest appearing root record's “BR Audit Period End Date” for >>>>>>> the >>>>>>> preceding audit period. CA owners should submit the self assessment to >>>>>>> the >>>>>>> CCADB at the same time as uploading audit reports.” * >>>>>>> >>>>>>> Perhaps a CCADB policy could be proposed to address this requirement >>>>>>> consistently. >>>>>>> >>>>>>> Thanks, Bruce. >>>>>>> >>>>>>> On Wednesday, July 26, 2023 at 5:35:19 PM UTC-4 Ben Wilson wrote: >>>>>>> >>>>>>>> All, >>>>>>>> For submission of self-assessments, what do people think about "at >>>>>>>> least every 366 days" instead of the original proposal of 365 days? >>>>>>>> That >>>>>>>> gives flexibility for leap years. >>>>>>>> Ben >>>>>>>> >>>>>>>> On Thu, Jun 29, 2023 at 9:48 PM Antti Backman <antti...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I concur to Bruce's consern, >>>>>>>>> >>>>>>>>> Albeit not directly conserning this discussion, we already have >>>>>>>>> this issue in our hands: >>>>>>>>> https://www.chromium.org/Home/chromium-security/root-ca-policy/#6-annual-self-assessments >>>>>>>>> >>>>>>>>> But yes, this will be moving target, I would propose that this >>>>>>>>> could be tight together with the end of audit period, which anyhow is >>>>>>>>> hardcoded date. And maybe then similarly to posting audit reports >>>>>>>>> having >>>>>>>>> some fixed amount of days after the end of audit period this should >>>>>>>>> (at >>>>>>>>> least and at latest) be submitted. >>>>>>>>> >>>>>>>>> Antti Backman >>>>>>>>> Telia Company >>>>>>>>> >>>>>>>>> torstai 29. kesäkuuta 2023 klo 22.36.32 UTC+3 Bruce Morton >>>>>>>>> kirjoitti: >>>>>>>>> >>>>>>>>>> The issue I have with "at least every 365 days" is that I like to >>>>>>>>>> put something on the schedule and do it the same month every year. >>>>>>>>>> We do >>>>>>>>>> this with our annual compliance audit. If we have to provide the >>>>>>>>>> self-assessment at least every 365 days, then each year it will be >>>>>>>>>> earlier >>>>>>>>>> to provide some insurance time to meet the requirement. Is there any >>>>>>>>>> way we >>>>>>>>>> can provide the requirement to stop this progression? Something like >>>>>>>>>> "on an >>>>>>>>>> annual basis, but not more longer than 398-days". >>>>>>>>>> >>>>>>>>>> On Friday, June 23, 2023 at 12:05:03 PM UTC-4 Ben Wilson wrote: >>>>>>>>>> >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>> Historically, Mozilla has required that CAs perform an annual >>>>>>>>>>> Self-Assessment of their compliance with the CA/Browser Forum's TLS >>>>>>>>>>> Baseline Requirements and Mozilla's Root Store Policy (MRSP). See >>>>>>>>>>> https://wiki.mozilla.org/CA/Compliance_Self-Assessment. While >>>>>>>>>>> there has not been any requirement that CAs submit their >>>>>>>>>>> self-assessments >>>>>>>>>>> to Mozilla, several CAs have had it a practice to do so. >>>>>>>>>>> >>>>>>>>>>> We would like to propose that the operators of TLS CAs (those >>>>>>>>>>> with the websites trust bit enabled) be required to submit these >>>>>>>>>>> self-assessments annually by providing a link to them in the Common >>>>>>>>>>> CA >>>>>>>>>>> Database (CCADB). Therefore, we are proposing a new section 3.4 in >>>>>>>>>>> the MRSP >>>>>>>>>>> to read as follows: >>>>>>>>>>> >>>>>>>>>>> ---- Begin Draft for MRSP----- >>>>>>>>>>> >>>>>>>>>>> 3.4 Compliance Self-Assessments >>>>>>>>>>> Effective January 1, 2024, CA operators with CA certificates >>>>>>>>>>> capable of issuing working TLS server certificates MUST complete a >>>>>>>>>>> [Compliance Self-Assessment]( >>>>>>>>>>> https://www.ccadb.org/cas/self-assessment) at least every 365 >>>>>>>>>>> days and provide the Common CA Database with the location where that >>>>>>>>>>> Compliance Self-Assessment can be retrieved. >>>>>>>>>>> >>>>>>>>>>> ----- End Draft for MRSP ----- >>>>>>>>>>> >>>>>>>>>>> The effective date of January 1, 2024, is not intended to result >>>>>>>>>>> in a huge batch of self-assessments being submitted that day. >>>>>>>>>>> Rather, we >>>>>>>>>>> would hope that CAs begin providing the locations of their >>>>>>>>>>> self-assessments >>>>>>>>>>> as soon as possible by completing the "Self-Assessment" section >>>>>>>>>>> under the >>>>>>>>>>> "Root Information" tab of an Add/Update Root Case in the CCADB >>>>>>>>>>> <https://www.ccadb.org/cas/updates>. (The field for this >>>>>>>>>>> information already exists in the CCADB under the heading >>>>>>>>>>> "Self-Assessment".) >>>>>>>>>>> >>>>>>>>>>> Please provide any comments or suggestions. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Ben and Kathleen >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>> 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/ac337060-ef9b-4fd4-b7af-500c7411635cn%40mozilla.org >>>>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ac337060-ef9b-4fd4-b7af-500c7411635cn%40mozilla.org?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> 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/a51dd5f6-245d-4cae-bebd-dada0c761f7en%40mozilla.org >>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a51dd5f6-245d-4cae-bebd-dada0c761f7en%40mozilla.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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/a4148e21-57e7-4826-acfe-1a1938987fc7n%40mozilla.org >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a4148e21-57e7-4826-acfe-1a1938987fc7n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZxE7UeJ6aJgVucMOmpdn7Ef8ULWx8PXcD4gyu4oZ6HDg%40mail.gmail.com.
