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

Thu Mar 11 17:13:57 UTC 2021

We'll put this into ballot format then and introduce it.

On Mon, Mar 8, 2021 at 3:00 PM Ben Wilson via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Here is a link to the current redline.
> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation
>
> On Mon, Mar 8, 2021 at 2:05 PM Ben Wilson via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> It has been proposed that we add the following language to the end of the
>> third paragraph of BR section 4.2.1:  "Effective 2021-10-01, the CA SHALL
>> verify Domain Names and IP Addresses no more than 398 days prior to
>> Certificate issuance." Is this language clear enough?
>>
>> On Thu, Feb 25, 2021 at 11:55 AM Ben Wilson via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>> Hi Bruce,
>>>
>>> See my responses inline below.
>>>
>>> On Mon, Feb 22, 2021 at 2:17 PM Bruce Morton <Bruce.Morton at entrust.com>
>>> wrote:
>>>
>>>> Hi Ben,
>>>>
>>>>
>>>>
>>>> A couple of comments.
>>>>
>>>>
>>>>
>>>> The ballot does not address the “cliff” that CAs have stated will
>>>> occur.
>>>>
>>>
>>> I do not see a "cliff" - it is more like a small hump.
>>>
>>>
>>>> The thinking is that currently CAs are verifying domains, which can be
>>>> reused for 825-days (~27 months).
>>>>
>>>
>>> Agreed - currently CAs can reuse domain verification for 825-days (~27
>>> months). However, they should not be reusing FQDN and IP address
>>> verification for such a long period, especially for one-year certificates.
>>> There should only be a very small number of domains that are difficult to
>>> verify, and if they've verified once before, then customers and CAs should
>>> have procedures in place that can be re-performed.
>>>
>>> The new requirement implies that the domain verification can only be
>>>> reused for 398-days (~13 months).
>>>>
>>>
>>> The new requirement would apply to certificates issued on or after July
>>> 1, 2021.  This proposal does not require all certificate validations to be
>>> redone, and the most recent verifications are more likely to still be
>>> accurate.
>>>
>>>
>>>> This means that for CAs which reuse domain validation, there will be 14
>>>> months of validation which will expire on the effective date of the ballot.
>>>>
>>>
>>> Correct, but the 14 months of validation would be for those old
>>> validations that were performed nearly 3 years ago -- from approximately
>>> October 5, 2018 through December 6, 2109.
>>>
>>>
>>>> In many cases this may create a lot of work on the Subscriber and the
>>>> CA to revalidate these domains.
>>>>
>>>
>>> I disagree.  As stated above, there should be fewer reuse of validations
>>> performed. I don't know of any statistics supporting the amount of work
>>> that would need to be performed.  Shouldn't these processes be automated?
>>> Do you have data for the type of validations that were originally performed
>>> between October 5, 2018 and December 6, 2109, to indicate how many of those
>>> will be problematic?  Also, the July 1, 2021, date has been circulated by
>>> Mozilla for quite some time, and CAs should have been preparing for it.
>>>
>>>
>>>> Is it possible to have the ballot only address domains which are
>>>> validated after the effective date? The domains which are currently
>>>> validated can be reused per their current schedule.
>>>>
>>>
>>> We can discuss this more, but your request is just that new domains and
>>> IP addresses be validated - which would already be required with or without
>>> an amendment to policy.  I think the currently proposed amendment is the
>>> best approach.
>>>
>>>>
>>>>
>>>> Would it also be possible to push out the effective date by a quarter,
>>>> so October 1, 2021?
>>>>
>>>
>>> That might be a possibility, but doesn't that just move your "cliff".
>>> As I say above, CAs and customers should already be moving toward more
>>> frequent FQDN and IP Address verification.
>>>
>>>
>>>> This will give the CAs more time to implement the change and to advise
>>>> Subscribers of the impact. It will also give the Subscribers some time to
>>>> address the volume of domains which will have to be re-validated.
>>>>
>>>
>>> What is the volume of domains that will need to be revalidated?
>>> Two-year certificates were eliminated last year, but how many 2-year
>>> certificates would be coming up for renewal, and of those, how many had
>>> problematic domain validation procedures that would need to be re-performed
>>> or replaced with the currently allowed methods?
>>>
>>> Respectfully,
>>>
>>> Ben
>>>
>>>
>>>>
>>>>
>>>>
>>>> Thanks, Bruce.
>>>>
>>>>
>>>>
>>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
>>>> Of *Ben Wilson via Servercert-wg
>>>> *Sent:* Friday, February 19, 2021 2:14 PM
>>>> *To:* CA/B Forum Server Certificate WG Public Discussion List <
>>>> servercert-wg at cabforum.org>
>>>> *Subject:* [EXTERNAL] Re: [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.
>>>> ------------------------------
>>>>
>>>> Here is a preliminary, rough draft of Ballot SC42 for discussion and
>>>> comment.  Please let me know if you spot any deficiencies in required
>>>> content or procedure.
>>>>
>>>> In other words, this email is not intended to and does not begin the
>>>> discussion period on this ballot.  A separate, official email will be sent
>>>> out next week for that purpose.
>>>>
>>>> Name of Ballot:  398-Day Reuse
>>>>
>>>> Purpose of Ballot:
>>>>
>>>> This ballot changes validation reuse periods for FQDN and IP Address
>>>> validation in the Baseline Requirements and for all purposes in the EV
>>>> Guidelines. The ballot does not change the 825-day reuse period in section
>>>> 4.2.1. of the Baseline Requirements for Organizational Validation (OV)
>>>> information.
>>>>
>>>> Specifically:
>>>>
>>>> * It inserts in BR section 3.2.2.4 “For Certificates issued on or after
>>>> July 1, 2021, the CA SHALL verify that each FQDN is confirmed as permitted
>>>> by this section at intervals of 398 days or less.” It also requires that
>>>> the validation be completed within the 398 days preceding certificate
>>>> issuance and removes cross-references to BR section 4.2.1.
>>>>
>>>> * It modifies BR sections 3.2.2.4.3 and 3.2.2.4.6 to eliminate reuse of
>>>> FQDN validation performed under those sunsetted provisions.
>>>>
>>>> * It modifies BR section 3.2.2.4.7 to replace subsections i. and ii.
>>>> with a 30-day limit on reuse of the Random Value.
>>>>
>>>> * It inserts in BR section 3.2.2.5 “For Certificates issued on or after
>>>> July 1, 2021, the CA SHALL validate each IP address as permitted by this
>>>> section at intervals of 398 days or less.” It also requires that the
>>>> validation be completed within the 398 days preceding certificate issuance
>>>> and removes cross-references to BR section 4.2.1.
>>>>
>>>> * It clarifies BR section 4.2.1 by stating, “This 825-day period does
>>>> not apply to the validation of domain authorization or control performed
>>>> under [Section
>>>> 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or the
>>>> authentication of an IP address performed under [Section
>>>> 3.2.2.5](#3225-authentication-for-an-ip-address), which have a 398-day
>>>> reuse period.”
>>>>
>>>> * It replaces eight instances of “thirteen months/thirteen-month” in
>>>> EVG 11.14.3 with 398 days.
>>>>
>>>> The following motion has been proposed by Ben Wilson of Mozilla and
>>>> endorsed by Dimitris Zacharopoulos of HARICA and Chema Lopez of
>>>> Firmaprofesional.
>>>>
>>>> – MOTION BEGINS –
>>>>
>>>> This ballot modifies the “Baseline Requirements for the Issuance and
>>>> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
>>>> based on Version 1.7.3:
>>>>
>>>> MODIFY the Baseline Requirements as defined in the following redline:
>>>> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation
>>>> <https://urldefense.com/v3/__https:/github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfS1OrxQc$>
>>>> (GITHUB URL TO BE UPDATED)
>>>>
>>>> This ballot modifies the “Guidelines for the Issuance and Management of
>>>> Extended Validation Certificates” (“EV Guidelines”) as follows, based on
>>>> Version 1.7.4:
>>>>
>>>> MODIFY the EV Guidelines as defined in the following redline:
>>>> https://github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation
>>>> <https://urldefense.com/v3/__https:/github.com/sleevi/cabforum-docs/compare/2020-11-30_Pandocification...BenWilson-Mozilla:398-day-FQDN-validation__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfS1OrxQc$>
>>>> (GITHUB URL TO BE UPDATED)
>>>>
>>>> – MOTION ENDS –
>>>>
>>>> This ballot proposes two Final Maintenance Guidelines.
>>>>
>>>> The procedure for approval of this ballot is as follows:
>>>>
>>>> Discussion (7+ days)
>>>>
>>>> Start Time: TBD
>>>>
>>>> End Time: TBD
>>>>
>>>> Vote for approval (7 days)
>>>>
>>>> Start Time: TBD
>>>>
>>>> End Time: TBD
>>>>
>>>>
>>>>
>>>> On Mon, Feb 15, 2021 at 11:50 AM Ben Wilson via Servercert-wg <
>>>> servercert-wg at cabforum.org> wrote:
>>>>
>>>> See
>>>> https://github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464
>>>> <https://urldefense.com/v3/__https:/github.com/BenWilson-Mozilla/servercert/commit/26bd5a9f9f8bd2a251153a4cceb6226b859a3464__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfndkviR8$>
>>>>
>>>>
>>>>
>>>> On Mon, Feb 15, 2021 at 11:44 AM Ben Wilson <bwilson at mozilla.com>
>>>> wrote:
>>>>
>>>> I have created a GitHub branch to make changes in for this ballot.
>>>>
>>>>
>>>> https://github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs
>>>> <https://urldefense.com/v3/__https:/github.com/BenWilson-Mozilla/servercert/tree/398-day-FQDN-validation/docs__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfI2S_Sds$>
>>>>
>>>> I intend to replace "thirteen months" in section 11.14.3 of the EV
>>>> Guidelines with "398 days".
>>>>
>>>>
>>>>
>>>> On Tue, Feb 9, 2021 at 5:03 PM Ben Wilson via Servercert-wg <
>>>> servercert-wg at cabforum.org> wrote:
>>>>
>>>> All,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> Can someone propose alternative language that says what was intended
>>>> (i.e. "cached validation" as indicated by Ryan)?  Otherwise, in BR section
>>>> 3.2.2.4.7 (DNS Change) and BR section 3.2.2.5.1 (Agreed Upon Change to
>>>> Website), as part of this proposed ballot, I intend to limit use of the
>>>> Random Value to 30 days and delete the phrase "ii. if the Applicant
>>>> submitted the Certificate request, the timeframe permitted for reuse of
>>>> validated information relevant to the Certificate (such as in Section 4.2.1
>>>> of these Guidelines or Section 11.14.3 of the EV Guidelines)"  because it
>>>> makes no sense as currently worded. In any event, even the structure is bad
>>>> because it combines two unrelated conditions into one concept. In other
>>>> words, it wouldn't make sense to say the longer of (i) 30 days or (ii) 398
>>>> days for cached validations.  As proposed by the ballot, the 398-day limit
>>>> will apply to all methods of validation.
>>>>
>>>>
>>>>
>>>> I am still a little unclear on the intent of the language in (ii).
>>>> Would the intent have been better served if that second part had been
>>>> placed in a separate sentence? E.g., "The same Random Value may also be
>>>> used for submitting subsequent certificate requests for the same domain for
>>>> the timeframe permitted for reuse ...."
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>
>>>> Ben
>>>>
>>>> _______________________________________________
>>>> Servercert-wg mailing list
>>>> Servercert-wg at cabforum.org
>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>> <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfywc1So8$>
>>>>
>>>> _______________________________________________
>>>> Servercert-wg mailing list
>>>> Servercert-wg at cabforum.org
>>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>> <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!Pw5FPlsjcApvD6B-RB2ue9k4OrfoZk-pK2UyHBEE5gpaRDKbgxwu90dLVaBfywc1So8$>
>>>>
>>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
> _______________________________________________
> 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/20210311/0e2b4f15/attachment-0001.html>