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

Mon Mar 8 21:05:40 UTC 2021

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