All, I have started a similar, simultaneous discussion with the CA/Browser Forum, in order to gain traction.
<goog_583396726> https://lists.cabforum.org/pipermail/servercert-wg/2020-December/002382.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
