Re: Underscore domains?
On Fri, Dec 21, 2018 at 06:14:19PM -0800, Lewis Resmond via dev-security-policy wrote: > I have read the debate about the underscores and I understand that they were > never intended in the RFC. > But I wonder, does it now mean that people who have a domain name with > underscore will never be able to receive a certificate again? There are registered domains -- as in, actual eTLD+1 names -- that have underscores in them? - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Underscore domains?
Hello, I have read the debate about the underscores and I understand that they were never intended in the RFC. But I wonder, does it now mean that people who have a domain name with underscore will never be able to receive a certificate again? I'm just being curious. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Statement on the Sunset of Underscore Characters
On Fri, Dec 21, 2018 at 4:43 PM Jeremy Rowley wrote: > 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? > I mean, we can get pedantic if you want to get pedantic, but I don't think it really conflicts with any of the discussion here. I'll use WebTrust as an example here: - When a CA engages with an auditor, they specify the criteria to be used (i.e. http://www.webtrust.org/principles-and-criteria/item83172.aspx ). - If we assume a US-based auditor, then we're talking an auditor bound to AICPA with regards to attestation engagements against those criteria - The auditor may consider the perspective of Google and Mozilla in some regards, but those are secondary sources for them, and the auditor has professional obligations captured within AICPA's various codes that express what their expectations and interpretations are, as well as what they communicate, and no browser can override those - As a result, we can't tell you "You won't get a qualified audit" on that, because that's up to the auditor. Now, it's true that there are ways to change that calculus, by redefining the audit expectations - For example, if Mozilla or Google engaged the auditor, to audit a third-party (the CA), then Mozilla or Google could develop the criteria for that assessment in collaboration with the auditor (Agreed Upon Procedures), for which the auditor would then report on - But then you're no longer using those WebTrust criteria (or you may, with modified interpretations), and I'm sure if Don or Jeff from the WebTrust TF are lurking here, they'd probably chime in with a whole host of complications Now, the point of a CA getting audited is so that they can submit it to the Root Program that expects such audits. Such Root Programs can define whatever expectations they want - such as allowing anyone to perform the audit - with whatever the risks or tradeoffs that may come with. In the case of most root programs, you already see the acceptance of two audit criteria (WebTrust and ETSI), with sets of licensed auditors managed independently by those programs. Mozilla's policy, as the example you called out, specifically allows it to extend or reduce the set of auditors, but without respect to the criteria. Certainly, a root program can, upon receipt of a qualified audit, determine that no further action is warranted, or that the qualification is not a concern. But that does not absolve the auditor of their own duties (modulo if Mozilla were to appoint a random auditor or to directly negotiate the criteria, procedures, or reporting) The point being is that, short of directly developing the audit criteria or engaging directly with the auditor with respect to third-party audits using agreed-upon procedures, Root Programs - such as those operated by Google or Mozilla - don't really say whether or not something is or is not a qualification/non-conformity. That's the auditor, using fixed criteria, expressing their opinion based on the material facts. We do consider the auditor's opinion and expression of those facts, and they are relevant to Root Programs, but they don't somehow cause the auditor to say "Oh, my opinion doesn't matter, I'll do whatever they say" (Unless, again, that's what the engagement agreed to) This is all pedantry lost in the woods, because I don't think any CA can or should reasonably expect that the view of one browser (which is merely a consumer of the report, not the initiator) could declare something not-a-qualification. They might declare it not-relevant for their program, but that's an entirely different thing - that's part of the incident response process I described, which is fairly consistent among all programs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Statement on the Sunset of Underscore Characters
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 On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, December 21, 2018 2:22 PM To: Wayne Thayer Cc: mozilla-dev-security-policy 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 id
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 un
Statement on the Sunset of Underscore Characters
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
