Since a number of questions and concerns have been raised regarding the sunset of underscore characters in dNSNames, I would like to summarize Mozilla’s position on the issue as follows:
In early November, the CA/Browser Forum passed ballot SC12 [1], creating a sunset period aimed at ending the practice of placing underscore characters (“_”) in the subjectAlternativeName (SAN) attribute of publicly-trusted TLS certificates. The ballot requires revocation of most existing certificates with underscore characters in SANs before 15-Jan 2019, but allows continued use of these certificates through April 2019 if they are valid for less than 30 days. A thorough review of RFC 5280 and its references shows that underscore characters have never been permitted in dNSNames in the SAN of compliant certificates. However, for many years this was a commonly accepted practice, and all major browsers currently ignore this requirement. In 2017, a ballot that attempted (among other things) to create an exception to RFC 5280 for these certificates [2] in the CA/Browser Forum Baseline Requirements was rejected [3], in-part due to objections to this exception. At that time, some CAs decided to stop issuing these certificates, while others continued. When the situation resurfaced earlier this year, there was spirited debate about how best to resolve the problem, and the compromise defined in ballot SC12 eventually emerged as the most viable approach. Mozilla has been asked by users of these certificates - primarily in the financial services industry - and their CAs to make exceptions to extend the revocation deadline until their systems can be updated. We don’t have the power to unilaterally change the Baseline Requirements (only the CA/Browser Forum can do that), but Mozilla can take a position on our plans to enforce them. However, simply granting CAs a “free pass” to ignore the revocation requirement is, we believe, not in the best interest of our users, fundamentally because it sets the expectation that the Baseline Requirements are negotiable. It is also: * unfair to CAs who voted in favor of ballot SC12 under the assumption that it would be enforced * unfair to the CAs who avoided this situation by ending this practice last year * unfair to the CAs (and their impacted customers) who will revoke all these certificates on time This doesn’t mean that we are insensitive to the potential disruption caused by the revocation of this type of certificate. We sincerely hope that affected organizations make every effort to meet the revocation deadline. If that is not possible for each and every certificate containing an underscore in the SAN, our expectation is for CAs to treat any failure to adhere to ballot SC12 as a policy violation. Should a CA choose not to revoke certificates with underscores in a SAN prior to 15-January 2019, we expect the individual circumstances that led to the decision for each Subscriber organization to be provided in a detailed incident report.[4] For this situation, we prefer for the incident report to be submitted immediately so that the Mozilla community can make our best effort to evaluate the information and identify any gaps or unmet expectations before the 15-January revocation deadline. We believe that this approach creates the best incentives to balance the various risks and to maximize disclosure, and in so doing helps us to improve the trustworthiness of the web PKI. - Wayne [1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/ [2] https://cabforum.org/pipermail/public/2017-July/011653.html [3] https://cabforum.org/pipermail/public/2017-July/011708.html [4] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
