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

Ryan Sleevi sleevi at google.com
Mon Feb 8 20:51:24 UTC 2021


Hi Ben,

Do you need help preparing this for GitHub? Happy to help, but since I
noticed it's the second proposal from you, I wasn't sure if it was
intentional, but happy to start something so that we can collaboratively
edit and discuss in context.

Further responses inline, below.

On Mon, Feb 8, 2021 at 3:03 PM Ben Wilson <bwilson at mozilla.com> wrote:

> Here are my initial thoughts:
>
> In BR Section 4.2.1, add a sentence -  *This does not apply to the
> validation of domain authorization or control performed under Section
> 3.2.2.4 or the authentication of an IP address performed under Section
> 3.2.2.5.*
>

So, if you want to go this route, 4.2.1 will need other updates, because
this section also has this phrase "Applicant information MUST include, but
not be limited to, at least one Fully-Qualified Domain Name or IP Address
to be included in the Certificate's subjectAltName extension".


> In BR Section 3.2.2.4 add, "*For Certificates issued on or after July 1,
> 2021, the CA SHALL verify that each FQDN is current and correct at
> intervals of 398 days or less*."
>
> In BR Section 3.2.2.5 add, "*For Certificates issued on or after July 1,
> 2021, the CA SHALL verify that each IP address is current and correct at
> intervals of 398 days or less.*
>

What is "current and correct"? This seems subject to significant issues in
interpretation, and I could easily drive a truck through possible
loopholes. So I'm probably missing something at the core: What was the
thinking that led to tackling it this way, versus other past efforts? Was
it simply to try and explicitly carve out the data with respect to 3.2.2.4
and 3.2.2.5? Or were their other considerations?


>
> Replace in both sections, "In all cases, the validation must have been
> initiated within the time period specified in the relevant requirement
> (such as Section 4.2.1 of this document) prior to Certificate issuance."
> with "*In all cases, the validation must have been completed within the
> 398 days preceding certificate issuance.*"
>
> Amend BR section 3.2.2.4.6 to remove any exception that would still allow
> CA to "continue to re-use information and validations for domains validated
> under this method per the applicable certificate data reuse periods."  (The
> Method 6 was deprecated June 3, 2020.)
>

If you're touching this (and I agree, it's reasonable to touch), then I
think we should also be touching the other places, like 3.2.2.4.3 (May 31,
2019)


> Amend BR section 3.2.2.5.1 and possibly make the Random Value valid for
> only 30 days or 60 days because what is meant by "if the Applicant
> submitted the certificate request"?  Otherwise, just editing out some of
> the existing language it would read something like, "If a Random Value is
> used, the CA SHALL provide a Random Value unique to the certificate request
> and SHALL not use the Random Value after the longer of (i) 30 days or (ii)
> if the Applicant submitted the certificate request, 398 days," but someone
> should explain how that makes any sense.
>

I seem to recall that harmonizing the Random Value (which, I agree, is also
a good change) touches a few other sections. In particular, we identified
previously that the (ii) is an anti-pattern; that is, that the Random Value
should be valid 30 days or less, and it's the cached validation that is
reused after that, rather than the Random Value itself. We updated several
of the places, but not all. That is, 3.2.2.4.7 also needs to be cleaned up


>
> Tie up any other loose ends.  For instance, do we leave the EV guidelines
> alone at thirteen months for Domain Names? See EVG section 11.14.3(1)(F).
>

Yes, I was going to say that anytime we've touched this, we've had to touch
both documents.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210208/3805c845/attachment.html>


More information about the Servercert-wg mailing list