One potential approach would be to make it so that issuances after July 1,
2021 require a validation no more than 398 days old. The currently-proposed
wording ("verify that each dNSName or IPAddress is current and correct at
intervals of 398 days or less") lends itself to that interpretation, it
just needs to be applied to issuances rather than validations. I would
propose wording like:5. verify that all of the information that is included in SSL certificates remains current and correct at intervals of 825 days or less; 5.1. for SSL certificates issued on or after July 1, 2021, verify that each dNSName or IPAddress is current and correct at intervals of 398 days or less; Aaron On Wed, Dec 2, 2020 at 1:22 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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
