I think it makes sense to separate out the date for domain validation expiration from the issuance of server certificates with previously validated domain names, but agree with Ben that the timeline doesn’t seem to need to be prolonged. What about something like this:
1. Domain name or IP address verifications performed on or after July 1, 2021 may be reused for a maximum of 398 days. 2. Server certificates issued on or after September 1, 2021 must have completed domain name or IP address verification within the preceding 398 days. This effectively stretches the “cliff” out across ~6 months (now through the end of August), which seems reasonable. Cheers! -Clint > On Feb 25, 2021, at 11:40 AM, Ben Wilson via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > Yes - I think we could focus on the domain validations themselves and allow > domain validations to be reused for 398 days (maybe even from December 6, > 2019), and then combine that with certificate issuance, but I'm not sure I > like pushing this out to Feb 1, 2022 or even Oct. 1, 2021. Maybe someone > else on the list has a suggested formula? > > On Thu, Feb 25, 2021 at 12:29 PM Doug Beattie <doug.beat...@globalsign.com> > wrote: > >> Ben, >> >> I'd prefer that we tie this to a date related to when the domain >> validations are done, or perhaps 2 statements. As it stands (and as others >> have commented), on July 1 all customers will immediately need to validate >> all domains that were done between 825 and 397 days ago, so a huge number >> all at once for web site owners and for CAs. >> >> I'd prefer that it says " Domain validations performed from July 1, 2021 >> may be reused for a maximum of 398 days ". I understand that this >> basically kick the can down the road for an extra year and that may not be >> acceptable, so, maybe we specify 2 dates: >> >> 1) Domain validations performed on or after July 1, 2021 may be reused >> for a maximum of 398 days. >> >> 2) for server certificates issued on or after Feb 1, 2022, each dNSName >> or IPAddress in a SAN must have been validated within the prior 398 days >> >> Is that a compromise you could consider? >> >> Doug >> >> >> -----Original Message----- >> From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> >> On Behalf Of Ben Wilson via dev-security-policy >> Sent: Thursday, February 25, 2021 2:08 PM >> To: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org> >> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name >> verification to 398 days >> >> All, >> >> I continue to move this Issue #206 forward with a proposed change to >> section 2.1 of the MRSP (along with an effort to modify section 3.2.2.4 or >> section 4.2.1 of the CA/B Forum's Baseline Requirements). >> >> Currently, I am still contemplating adding a subsection 5.1 to MRSP section >> 2.1 that would read, >> " 5.1. for server certificates issued on or after July 1, 2021, verify >> each dNSName or IPAddress in a SAN or commonName at an interval of 398 days >> or less;" >> >> See draft language here >> >> https://github.com/BenWilson-Mozilla/pkipolicy/commit/69bddfd96d1d311874c35c928abdfc13dc11aba3 >> >> >> Ben >> >> On Wed, Dec 2, 2020 at 3:00 PM Ben Wilson <bwil...@mozilla.com> wrote: >> >>> All, >>> >>> I have started a similar, simultaneous discussion with the CA/Browser >>> Forum, in order to gain traction. >>> >>> <http://goog_583396726> >>> >>> https://lists.cabforum.org/pipermail/servercert-wg/2020-December/00238 >>> 2.html >>> >>> Ben >>> >>> On Wed, Dec 2, 2020 at 2:49 PM Jeremy Rowley >>> <jeremy.row...@digicert.com> >>> wrote: >>> >>>> Should this limit on reuse also apply to s/MIME? Right now, the 825 >>>> day limit in Mozilla policy only applies to TLS certs with email >>>> verification of s/MIME being allowed for infinity time. The first >>>> draft of the language looked like it may change this while the newer >>>> language puts back the TLS limitation. If it's not addressed in this >>>> update, adding clarification on domain verification reuse for SMIME >>>> would be a good improvement on the existing policy. >>>> >>>> -----Original Message----- >>>> From: dev-security-policy >>>> <dev-security-policy-boun...@lists.mozilla.org> >>>> On Behalf Of Ben Wilson via dev-security-policy >>>> Sent: Wednesday, December 2, 2020 2:22 PM >>>> To: Ryan Sleevi <r...@sleevi.com> >>>> Cc: Doug Beattie <doug.beat...@globalsign.com>; Mozilla < >>>> mozilla-dev-security-pol...@lists.mozilla.org> >>>> Subject: Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain >>>> name verification to 398 days >>>> >>>> See my responses inline below. >>>> >>>> On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi <r...@sleevi.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy < >>>>> dev-security-policy@lists.mozilla.org> wrote: >>>>> >>>>>> See responses inline below: >>>>>> >>>>>> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie >>>>>> <doug.beat...@globalsign.com >>>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hi Ben, >>>>>>> >>>>>>> For now I won’t comment on the 398 day limit or the date which >>>>>>> you >>>>>> propose >>>>>>> this to take effect (July 1, 2021), but on the ability of CAs to >>>>>>> re-use domain validations completed prior to 1 July for their >>>>>>> full >>>>>>> 825 re-use period. I'm assuming that the 398 day limit is only >>>>>>> for those domain validated on or after 1 July, 2021. Maybe that >>>>>>> is your intent, but the wording is not clear (it's never been >>>>>>> all that >>>>>>> clear) >>>>>>> >>>>>> >>>>>> Yes. (I agree that the wording is currently unclear and can be >>>>>> improved, which I'll work on as discussion progresses.) That is >>>>>> the intent - for certificates issued beginning next July--new >>>>>> validations would be valid for >>>>>> 398 days, but existing, reused validations would be sunsetted and >>>>>> could be used for up to 825 days (let's say, until Oct. 1, 2023, >>>>>> which I'd advise against, given the benefits of freshness provided >>>>>> by re-performing methods in BR 3.2.2.4 and BR 3.2.2.5). >>>>>> >>>>> >>>>> Why? I have yet to see a compelling explanation from a CA about why >>>>> "grandfathering" old validations is good, and as you note, it >>>>> undermines virtually every benefit that is had by the reduction >>>>> until >>>> 2023. >>>>> >>>> >>>> I am open to the idea of cutting off the tail earlier, at let's say, >>>> October 1, 2022, or earlier (see below). I can work on language that >>>> does that. >>>> >>>> >>>>> >>>>> Ben, could you explain the rationale why this is better than the >>>>> simpler, clearer, and immediately beneficial for Mozilla users of >>>>> requiring new validations be conducted on-or-after 1 July 2021? Any >>>>> CA that had concerns would have ample time to ensure there is a >>>>> fresh domain validation before then, if they were concerned. >>>>> >>>> >>>> I don't have anything yet in particular with regard to a >>>> pros-cons/benefits-analysis-supported rationale, except that I expect >>>> push-back from SSL/TLS certificate subscribers and from CAs on their >>>> behalf. You're right, CAs could take the time between now and July >>>> 1st to obtain 398-day validations, but my concern is with the potential >> push-back. >>>> >>>> Also, as I mentioned before, I am interested in proposing this as a >>>> ballot in the CA/Browser Forum and seeing where it goes. I realize >>>> that this issue might come with added baggage from the history >>>> surrounding the validity-period changes that were previously defeated >>>> in the Forum, but it would still be good to see it adopted there >>>> first. Nonetheless, this issue is more than ripe enough to be resolved >> here by Mozilla as well. >>>> >>>> >>>> >>>>> >>>>> Doug, could you explain more about why it's undesirable to do that? >>>>> >>>>> >>>>>>> >>>>>>> Could you consider changing it to read more like this (feel free >>>>>>> to edit as needed): >>>>>>> >>>>>>> CAs may re-use domain validation for subjectAltName >>>>>>> verifications of dNSNames and IPAddresses done prior to July 1, >>>>>>> 2021 for up to >>>>>>> 825 days >>>>>> <in >>>>>>> accordance with domain validation re-use in the BRs, section >> 4.2.1>. >>>>>> CAs >>>>>>> MUST limit domain re-use for subjectAltName verifications of >>>>>>> dNSNames >>>>>> and >>>>>>> IPAddresses to 398 days for domains validated on or after July >>>>>>> 1, >>>> 2021. >>>>>>> >>>>>> >>>>>> Thanks. I am open to all suggestions and improvements to the >> language. >>>>>> I'll >>>>>> see how this can be phrased appropriately to reduce the chance for >>>>>> misinterpretation. >>>>>> >>>>> >>>>> As noted above, I think adopting this wording would prevent much >>>>> (any?) benefit from being achieved until 2023. I can understand >>>>> that >>>>> 2023 is better than "never", but I'm surprised to see an agreement >>>>> so quickly to that being desirable over 2021. I suspect there's >>>>> ample context here, but I think it would benefit from discussion. >>>>> >>>> >>>> The language needs to be worked on some more. As I note above, we >>>> should come up with a cutoff date that is before 2023. It seems that >>>> two years is too long to wait for the last 825-day validation to >>>> expire when there are domain validation methods that work in a matter >> of seconds. >>>> >>>> >>>>> >>>>> >>>>>>> From a CA perspective, I don't have any major concerns with >>>>>>> shortening >>>>>> the >>>>>>> domain re-use periods, but customers do/will. Will there be a >>>>>>> Mozilla >>>>>> blog >>>>>>> that outlines the security improvements with cutting the re-use >>>>>>> period >>>>>> in >>>>>>> half and why July 2021 is the right time? >>>>> >>>>>> >>>>>> >>>>>> Yes. I'll prepare a blog post that outlines the security >>>>>> improvements to be obtained by shortening the reuse period. (E.g., >>>>>> certificates should not contain stale information.) July 2021 was >>>>>> chosen because I figured April >>>>>> 2021 would be too soon. It also allows CAs to schedule any needed >>>>>> system work during Q2/2021. In my opinion, Oct. 2023 is a >>>>>> considerably long tail for this change, and existing >>>>>> domains/customers should not be affected until then. >>>>> >>>>> >>>>> Right, my concern is that it's "too long" a tail. There's no real >>>>> benefit in July 2021 - the benefits aren't really met until Oct 2023. >>>>> >>>> >>>> Other options for a cutoff, other than July 2021 or October 2022, >>>> could be December 1, 2021, January 31, 2022, or July 1, 2022. >>>> >>>> Ben >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
