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.

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.

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.


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

As we saw with the last change to domain validation, there were a
significant number of CA incidents that resulted from this "grandfather"
approach. Happy to dig them up if it'd be helpful for review/discussion,
but it does seem like the public/Mozilla community has evidence of both it
not being in users best interest, as well as not leading to good compliance
adherence. If there's an argument for why this problematic approach is
still useful, I'm hoping folks can share why.

Equally, we know that once this date is set, there will likely be
substantial opposition from CAs to any further improvements/changes between
July 2021 through to October 2023, since they're "in the midst" of
transitioning. That equally seems a good reason to set an expectation and
with ample lead-time (e.g. 6 months), CAs can work with their customers to
obtain fresh manual validations that are needed, or, if they're security-
and customer- focused, work on automating validation such that such
transitions have zero effective impact on their Subscribers going forward.

I just can't see this approach working in 2020, knowing what we know now,
as well as knowing what the security goals are.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to