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

Mon Mar 8 22:00:27 UTC 2021

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210308/6487200b/attachment-0001.html>