But this part isn't true "Browsers are not capable of granting 'exceptions' to the Baseline Requirements", at least for Mozilla. See the Mozilla auditor requirements for example. Perhaps better stated that they don't have to implement the standards they don't like?
-----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, December 21, 2018 2:22 PM To: Wayne Thayer <wtha...@mozilla.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Statement on the Sunset of Underscore Characters On Fri, Dec 21, 2018 at 1:54 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> 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://clicktime.symantec.com/a/1/ItcBh6JWraENfWUgKWLc5BsE0NvfRRFcR38ySDBvYgM=?d=5WiPL26b6jXJrcvOShi9OV64-60pDe0clJKywUYAymbJ3mHnbZxXo4NKOGHYWcShcPoez2QqSNBtF-Uo_nBgnlf9NTcGQ5BiKPk1dnvjyEmfkpnPrbXaqE86zL7tlNcoc1llzfdytUJ4olJ4Eb1h6ck1eQ3W9oqZicDps4RrqJEagPh5K2vxo24ZWOTUZPtTycfqAWwxYkEhdZb9eMkae7VNeARhIAUnr_nUM5Be1fqxd_nXPNUicZFrOQ6fyDyMzSNFABTi0K7g_L7XCzJMjZqo-Ar2c32I7RAPD9tagrucWFf6IQ1uhKZMRTko4d441GMZKqO13xBYL1Qbtu2BOlz-XRfx65eH2tWqyhvyQdcQ6lVzZZBWJK9rqlBACkar3AF7YirplEl2-C-F7UOXCLAObvT_lYhwblhK2_un6t5MeUGnVS4Q-Ss6KfzmmMnx9LcbXjnkd953fA%3D%3D&u=https%3A%2F%2Fwww.chromium.org%2FHome%2Fchromium-security%2Froot-ca-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/oBUi0N9oFQb5hQGTBUvqa9-bPOZ0hcQCSNJjs_wHgAc=?d=5WiPL26b6jXJrcvOShi9OV64-60pDe0clJKywUYAymbJ3mHnbZxXo4NKOGHYWcShcPoez2QqSNBtF-Uo_nBgnlf9NTcGQ5BiKPk1dnvjyEmfkpnPrbXaqE86zL7tlNcoc1llzfdytUJ4olJ4Eb1h6ck1eQ3W9oqZicDps4RrqJEagPh5K2vxo24ZWOTUZPtTycfqAWwxYkEhdZb9eMkae7VNeARhIAUnr_nUM5Be1fqxd_nXPNUicZFrOQ6fyDyMzSNFABTi0K7g_L7XCzJMjZqo-Ar2c32I7RAPD9tagrucWFf6IQ1uhKZMRTko4d441GMZKqO13xBYL1Qbtu2BOlz-XRfx65eH2tWqyhvyQdcQ6lVzZZBWJK9rqlBACkar3AF7YirplEl2-C-F7UOXCLAObvT_lYhwblhK2_un6t5MeUGnVS4Q-Ss6KfzmmMnx9LcbXjnkd953fA%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
