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/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
