On Mon, Jun 1, 2020 at 7:23 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> ** Sub Item 3.2 -- Limit re-use of domain name and IP address > verification to 398 days > (https://github.com/mozilla/pkipolicy/issues/206) > 19 CAs responded that they either do not re-use domain verification, or > that their re-use of domain verification is already less than 398 days. > 11 CAs indicated that they could implement the changes to their > processes and documentation to limit the re-use of domain name > verification to 398 days or less before 2020 Sep 30, 2020 > 9 CAs shared the sentiment that they would prefer that the re-use of > verification information be regulated by the CA/Browser Forum Baseline > Requirements. > A few CAs indicated that this requirement would cause extra work for > their customers, and requested a detailed security analysis of this > change which they could convey to their customers. > One CA noted: "If there is a change to reuse requirements, it should > only apply to data verified on or after the effective date of the > change. This change should not apply to data verified before the > effective date of the change to avoid creating a verification cliff for > the CAs and Subscribers. Note, if Mozilla requires that a domain name or > IP address is re-verified each time a TLS certificate is issued, then > this will reduce the effectivity of a number of verification > methodologies that can be used and could impact many ecosystems which > rely on TLS." It is interesting the degree to which this CA continues to do a disservice to their customers, and the ecosystem, with replies like this. There are only three validation methods which might (not will) have their effectivity reduced, and that is validation methods that require manual validation using less secure, less reliable methods of validation: namely, validation of DNS via a phone call, rather than DNS itself. The extent of ecosystem wide CA incidents in the past year has only highlighted the importance of strong technical controls for domain validation. Methods that rely on unstructured text (like WHOIS) or that are artificially constrained due to requiring manual steps continue to cause validation issues and impair the ability of CAs to respond effectively to security incidents. Mozilla’s own feedback on CA incidents has highlighted the critical importance of CA’s ability to support validation methods that can be done without requiring an error prone, high latency, non-scalable human approval, instead basing validation on the thing being validated, namely, DNS itself. It’s certainly true that there would be an impact, but it is undeniable when one examines the CA incidents, both in issuance and revocation, so say it be a much-needed positive impact towards ensuring robust and healthy ecosystems. Given how many CAs have already implemented this change, or could do so, I think we should be careful when giving it any substantive weight. I worry the inclusion here might be seen as legitimizing the feedback, rather than highlighting how divorced it is from the ecosystem and their peers. Given how much of the ecosystem has already moved positively in the right direction and taken steps to mitigate any issues and avoid any hypothetical cliffs, as shown by the feedback, I think we should view this specific CA’s feedback as a largely intransigent response focused on maintaining the status quo, rather than how best to serve the needs of relying parties who place trust in them. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
