[Servercert-wg] [EXTERNAL] Reducing Domain/IP Address Validation Reuse to 398 Days

Ryan Sleevi sleevi at google.com
Thu Dec 3 23:30:06 UTC 2020


This is a useful suggestion, but it doesn't really explain the rationale so
much as simply state something without much data.

Perhaps you could be more concrete in your explanation about why this is
important?

Concretely: If a CA hasn't validated a domain for 398 days, but has within
the past 825 days, what specifically is the challenge in validating that
domain again. And can you provide data to support it?

It seems that you're saying it will take a CA approximately one year to
revalidate domains, which would be sheer madness, so I'm suspecting there's
something very important or misunderstood about your proposal.

Recall that people were talking about 1 year validation periods 30 years
ago, when it was the norm, so concrete data explaining why that's
challenging now seems useful.

On Thu, Dec 3, 2020 at 5:02 PM Bruce Morton via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi Ben,
>
>
>
> I am thinking that solution could be that effective 1 July 2021, all new
> verifications could be reused for 398-days AND all previous verifications
> with reuse expiry periods greater than 398-days  would be reduced to
> 398-days of reuse. This would remove of 825-days of reuse and also allow
> the CAs 398-days to re-verify domains. Re-verification is important when
> the CA provides a service based on pre-validated data. The proposal would
> also mean that the full solution would be migrated in early August 2022.
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Ben
> Wilson via Servercert-wg
> *Sent:* Wednesday, December 2, 2020 4:55 PM
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL][Servercert-wg] Reducing Domain/IP Address
> Validation Reuse to 398 Days
>
>
>
> *WARNING:* This email originated outside of Entrust.
> *DO NOT CLICK* links or attachments unless you trust the sender and know
> the content is safe.
> ------------------------------
>
> I am loath to create this thread and to have two simultaneous discussions
> on the same topic in two different fora, but I want to see if the
> CA/Browser Forum is willing to incorporate substantially the same 398-day
> policy, as discussed below, in its Baseline Requirements and EV Guidelines.
>
>
>
> On the Mozilla Dev Security Policy (mdsp) list (
> https://groups.google.com/g/mozilla.dev.security.policy/c/7TeSlHFIk5U/m/2ojwLrslBQAJ)
> and in the Mozilla policy issues list on GitHub (
> https://github.com/mozilla/pkipolicy/issues/206), Mozilla is considering
> amending subsection 5 of section 2.1 of the Mozilla Root Store Policy
> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations>
> to reduce the reuse of the validation of DNS Names and IP addresses to 398
> days.
>
>
>
> Currently, Mozilla is looking at making this requirement effective as of
> July 1, 2021, with some type of phase-in period, to-be-determined.
>
>
>
> I intend to draft a ballot that would accomplish that same goal within BR
> section 4.2.1, and elsewhere as might be necessary in the Baseline
> Requirements and EV Guidelines.
>
>
>
> To prime the discussion here, one issue discussed on the mdsp list is the
> phase-in, if any, of this 398-day requirement. I have suggested that
> sunsetting 825-day DNS/IP validations through 2023 is too long, given the
> validation methods now available per BR 3.2.2.4 and 3.2.2.5.  Would it be
> simpler just to prohibit, as of 7/1/2021, any reuse of DNS/IP validations
> older than 398 days?
>
>
>
>
>
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201203/fa82371e/attachment-0001.html>


More information about the Servercert-wg mailing list