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
