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