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

[Ben Wilson]

Hi Ryan,
Yes. I'd like help putting this on GitHub. I think I can do it, but I
wanted to make sure I was using the right repository/branch, etc. Can you
point me in the right direction?
On the replacement of "current and correct" we can drop that phrase and
just say "confirmed as permitted by this section" or something else.
Thanks,
Ben

On Mon, Feb 8, 2021 at 1:52 PM Ryan Sleevi <sleevi at google.com> wrote:

> 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/4e5ca2a3/attachment-0001.html>