On Fri, Dec 21, 2018 at 1:54 PM Wayne Thayer via dev-security-policy < [email protected]> wrote:
> 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. > (In a Chrome capacity) Thanks for sharing this, Wayne. On behalf of Chrome, we want to echo our support for this statement and the expectations, and believe it is consistent with our expectations on the matter. To emphasize a few specific points here: Browsers are not capable of granting "exceptions" to the Baseline Requirements. We, Chrome, expect any violations identified by CA management or their auditors to be disclosed within their audit reports, management letters, and to the broader community, the principles of which are captured in our Root Certificate Policy [A]. We expect there to be a public incident report and discussion, to ensure that the information necessary to ensure that the scope of the issue has been identified, the cause of the issues, and that the plans for remediation are consistently executed upon and meaningfully address the causes. In all of this, we welcome public participation and transparency, and expect the CA, which is ultimately responsible for any incident, to be the primary party engaging on the incident. Similarly, we expect any information expected to be considered to be publicly shared and available, in order to support and achieve those goals. We do not condone intentional violations of the Baseline Requirements or Root Policies, just as we do not condone unintentional violations. In the very specific and sole case of underscore certificates, we view the present discussion around revocation timelines as an extension of what would have normally been discussion within an incident report resulting from their issuance in their first place, rather than as a request to condone intentional violations of the Baseline Requirements. This is specific to the discussion of SC12, and does not generalize to other violations of the Baseline Requirements. Given this, we're strongly supportive of the proposed course of action, which seeks to minimize ecosystem risk, improve transparency, and improve trustworthiness, which are fundamental goals and benefits of the public incident reporting process. [A] https://www.chromium.org/Home/chromium-security/root-ca-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
