Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
That you have to ask WoSign. The exact wording is "将增加一个产品选项，用户可以选购从新的沃通（WoSign）中级根证书下签发的支持所有浏览器（包括火狐浏览器）的SSL证书，在过渡期八折优惠。此中级根证书将由全球信任的其他CA根证书签发，支持所有浏览器和所有新老终端设备。此项产品升级计划一个月内完成并为广大用户提供证书服务；" My translation: [WoSign] will add a new product selection. Users can choose SSL certs signed by the new WoSign intermediate cert. The SSL certs will be trusted by all browsers(including firefox). The certs will be 20% off in this transition period. The certs will be signed by a publicly trusted CA which supports all browsers and all OS, older or new. This product upgrade is expected to be completed within a month and will serve our users the certificate service they need. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
On Tuesday, October 25, 2016 at 4:56:57 PM UTC-7, Nick Lamb wrote: > Is it possible for someone to write up the details of the non-compliant > issuances and so on ? I would find it much easier to comment on the > particulars of 1311200 if they were more specific. This doesn't seem relevant; that is, the specifics of 1311200 are irrelevant, so much as we're discussing BR non-compliance. Even if the issues are seen as technically trivial, we have an inconsistency the deserves some degree of guidance. > Unless I'm missing something, these constrained certificates pose a much > smaller risk under our expected threat model for SHA-1. I think you're missing a key purpose of the sunset date of 1/1/2016, which perhaps wasn't as clearly communicated outside the Forum. The purpose of having a date for no new issuance, and distinct from full distrust of SHA-1, was to allow a graduated fade-out without having a giant flag day of disruption, which would then also suffer from the first-mover problem due to browsers non-uniform schedules. That is, had we simply stated 1/1/2017 as the date SHA-1 was turned off, we would have seen continued issuance up to that day. As a result, turning it off would have broken huge numbers of sites - and for compatibility reasons, been re-enabled. This isn't theoretical either - we saw this both with attempts to deprecate MD5 (which lacked such a schedule) and with Mozilla's attempts to disable new SHA-1 certificates. So I think the remaining discussion of the technical details of a SHA-1 collision are largely immaterial, because the point I was making about it, and apologies for not being clearer on this, was that some of the things we deprecate in the CA/Browser Forum so that browsers can eventually remove support for the (insecure) thing, while minimizing disruption/breakage of sites. As a further example, consider the requirement that a subjectAltName field be present, and that the CN field, if present, contains a value represented in the SAN. The entire purpose of such a requirement is to ensure that the technical representation of authorized hosts uses an unambiguous representation (which dNSName and iPAddress are), rather than the ambiguous heuristic of CN. This goal itself was expressed as far back as 1999, in RFC 2818, but it still took 15 years after that (2014) before it actually became standard practice of CAs, and only then, because of the Baseline Requirements. In spite of this, we still see CAs issuing certs lacking a SAN, which potentially means applications still need to support these certs (for another ~3 years). While Mozilla has taken steps to phase this practice out, they're only doing it on the basis of a notBefore of *this* year, in order to minimize breakage. So we certainly know that Mozilla's policies are, in some ways, designed to minimize the number of errors that users are presented with, by allowing a gradual fade out of insecure or undesirable practices. A change in the BRs is, in theory, supposed to be fully reflected in all valid certificates within 39 months of the effective date, after which time, application software vendors can remove support. An interpretation that suggests TCSCs don't have to abide by these policies - which Mozilla policy implies, but the BRs prohibit - means that any such deprecations do not apply to TCSCs, and as a consequence, such things bear a greater compatibility risk when they are removed. If we imagine a world with millions of TCSCs - something that the TLS WG has expressed interest in, in the past - potentially means breakage for millions of sites, and means that the path of deprecating things via the CA/Browser Forum may no longer be a viable solution to minimizing user disruption. Does that more concretely express the concerns, which are more fundamental than specifics about commonNames or SHA-1? > Finally, as I understand it the hypothetical SHA-1 TSCSs would be revoked > along with any other still extant SHA-1 certificates by the issuing CA, > before the planned Firefox 51 public release. So I don't think this would > imperil the planned action in Firefox 51. Am I wrong about that ? Yes. There is no obligation or expectation, presently communicated, to revoke extant certificates. Indeed, CAs were adamantly opposed to such a requirement. So these certificates will still very much be valid. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
On Tuesday, 25 October 2016 21:16:36 UTC+1, Ryan Sleevi wrote: > The linked bug is a concrete example, where an unconstrained sub-CA was > revoked, due to non-compliance with the BRs, but has now been cross-certified > as a constrained sub-CA. All of these non-BR compliant certificates are now > valid, by utilizing the technically constrained path. From a Mozilla policy, > what are the implications of this new cross-certified constrained sub-CA? Is it possible for someone to write up the details of the non-compliant issuances and so on ? I would find it much easier to comment on the particulars of 1311200 if they were more specific. > A very concrete example of the implications of this relate to SHA-1 > certificates. If, prior to Dec 31, 2015, CAs had issued some N-million TCSCs, > signed with SHA-1, to all parties that wished to keep issuing SHA-1, could > these TCSCs have continued issuing SHA-1 certificates without violating the > Mozilla requirements? One interpretation is that yes, they could have, at > least from Mozilla policy. However, from the BRs, the answer is that no, they > couldn't have. Unless I'm missing something, these constrained certificates pose a much smaller risk under our expected threat model for SHA-1. We suppose a bad guy can (or will soon be able to) pull off a chosen prefix attack on SHA-1 enabling them to trick a CA into signing document A and then use its signature on document B successfully. Back when this happened for MD5, many CAs were issuing from roots, or at best from completely unconstrained intermediates, just because. The attack was used to produce a working unconstrained CA:TRUE certificate. One successful attack translated into unlimited issuing power across all of the Web PKI. It seem eminently reasonable to believe this one certificate might be extremely valuable to criminals with an effective plan to exploit it before any effective remedy is deployed, and everybody in the Web PKI (which is now basically everyone) is put at risk. In contrast for the TCSCs a successful attack would produce /at best/ another constrained intermediate, and in most cases I've seen not even a working CA:TRUE certificate but just some arbitrary wildcard end entity certificate for a subset of the constrained names. The attack must also be launched against infrastructure controlled by the very organisation the certificates will be used to impersonate, not some unrelated third party as with the MD5 attacks. Finally, as I understand it the hypothetical SHA-1 TSCSs would be revoked along with any other still extant SHA-1 certificates by the issuing CA, before the planned Firefox 51 public release. So I don't think this would imperil the planned action in Firefox 51. Am I wrong about that ? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
On 26/10/16 01:27, Percy wrote: > WoSign will roll out a globally trusted intermediate cert to sign new > certs with the existing WoSign system that had so many control > failures. > > Does Mozilla and this community accept such a work-around for WoSign? > If we do, then what's the point of distrust those WoSign root certs? > If not, then what's an appropriate response for WoSign's > announcement? Has WoSign publicly stated that this will be an intermediate certificate for which they hold the private key, or could this simply mean they'll act as a (kind of) white-label reseller for some other CA until they've completed the (re-)application process? I don't think Mozilla should allow WoSign to use a new cross-signed intermediate under their control until they've completed the application process, but I don't see the problem if they plan to act as a reseller for now to keep their business operational. If this is indeed Mozilla's policy on this issue (and not just my opinion), it might be worth thinking about communicating this to CAs to avoid trouble down the line. Hopefully WoSign will be able to comment on this and clarify their plans. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
StartCom on the other hand, issued no announcement (https://startssl.com/News) even under multiple explicit inquires from multiple users (https://forum.startcomca.com/viewforum.php?f=16=549011a08d3a081898f1e1542d3ecc10). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog
WoSign has posted an announcement regarding Mozilla's decision. In the announcement, WoSign stated WoSign actively cooperated with the investigation and has always fix all the issues immediately after the discovery and called Mozilla's decision "exceptionally severe". Certs issued by existing WoSign roots will be 90% off from Oct 22nd. WoSign will launch a new WoSign intermediate cert to continue to sell certs trusted by all browsers including Firefox. The intermediate cert will be signed by another trusted root CA. This is scheduled to launch within a month. - The full announcement is translated below. https://www.wosign.com/news/announcement_about_Mozilla_Action_20161024.htm Announcements about the Mozilla Incident Release Date: 2016-10-24 Mozilla on August 24 launched an investigation against WoSign CA, and published a list of questions ( Wiki ), lists all the issues from March 2015 to July 2016 period. WoSign addressed these issues with a careful investigation and released the investigation report , some issues have been clarified and all issues have been fixed immediately after their discovery. WoSign actively cooperated with the investigation and argued for the best interests of users, to ensure that the certificate issued previously will not be affected. Mozilla has released on the October 21, the final response to WoSign. WoSign has the following statement regarding this incident 1.the results of the incident Very sorry to see Mozilla decided from October 22 onwards no longer trust the four WoSign root certificate; After June 1, 2017, after satisfying Mozilla's 6-point operational requirements, WoSign CA can re-apply for the Mozilla root certification process, re-apply for a new root certificate inclusion. 2. the impact of the incident on the user All SSL certificates October 21 (including 21), before issuing are not affected, can normally be trusted by Mozilla Firefox browser ; after October 21 SSL certs from WoSign (WoSign) 4 root certificate will not be trusted by Firefox. All code-signing certificates, client certificates, and signature platforms (WoSignDoc) issued from the four WoSign roots are unaffected. 3. WoSign’s response measures after the incident Will update the digital certificate Store Buy website. From October 22, all SSL certificates from WoSign four root certificate will be 90% off; free SSL certificate service continue to be closed; Will add a product option, the user can choose to support all browsers SSL Certificates (including Firefox) under the new WoSign (WoSign) intermediate root certificates issued during the transitional period 20% Off! This intermediate root certificate will be issued by other CA root certificates that are trusted globally, supporting all browsers and all new and existing terminal devices. The product upgrade plan is scheduled to completed within one month and provide a certificate for the majority of users; Will be actively in accordance with the requirements of Mozilla-made 6 points for operation, for after June 1, 2017, as soon as possible to complete the new root certificate in the various browser system preset work; Has been and continue to conduct a comprehensive security audit of all systems and strengthen the upgrading, while improving the various internal control management system, the formation of international standards research team and internal audit team to ensure that all systems 100% meet international standards, all business operations in strict accordance with international standards. Require operation, strengthen the staff in strict accordance with the standard operation of the enforcement efforts, offenders will be severely punished. Mozilla's sanctions are exceptionally severe, but we will sincerely accept and carry out profound reflection and improvement, continue to improve system reliability, security and compliance, strict compliance with various international standards and various browser vendors designated security management strategy. We know that: as a Chinese CA's international road is still very long, but WoSign’s plan to build world-class PKI certificate service at the beginning will stay the same! We will continue to contribute to building a safe and trusted global Internet environment, and actively promote the PKI / CA-related Chinese standards and international standards system integration. Thank you very much for your continued trust in the majority of users and partners! It is with your support and companionship, WoSign has gone through ten years of wind and rain, and achieved SSL certificate in China market share of nearly 50% and the global market ranked sixth in the good results, we hope to continue with your towards the next more brilliant decade! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote: > That is, according to the BRs, the issuer of a technically constrained > subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to > the BRs and the issuing CA's policies and practices, as well as conduct a > sampling audit quarterly. My expection of this is that the CA (CA1) that issued such a constrained CA (CA2) is responsible for auditing CA2. when CA is then audited, part of that audit is that they check that the audits of CA2 have been done. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Technically Constrained Sub-CAs and the BRs
In https://bugzilla.mozilla.org/show_bug.cgi?id=1311200 , Kathleen suggested I bring the broader discussion to mozilla.dev.security.policy, so this is that thread. At present, there's an element of inconsistency between the BRs and Mozilla Policy that leads to some confusion. With respect to Mozilla's current policies, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ : 8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited. This wording implies that technically constrained sub-CAs, from a Mozilla Policy standpoint, are not required to adhere to the Baseline Requirements. However, the Baseline Requirements have a different set of criteria. In Section 8.1 of the BRs (v1.4.1, https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf ), it states: Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 7.1.5 and audited in line with section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section Section 8.7 reads: During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met. That is, according to the BRs, the issuer of a technically constrained subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to the BRs and the issuing CA's policies and practices, as well as conduct a sampling audit quarterly. The element of inconsistency is what the expectations of Mozilla are, if the issuing CA, which has a BR obligation to monitor their TCSCs, and which Mozilla expects to adhere to the BRs, does not perform this task, and the TCSC does not adhere to the issuing CA's (which is subject to Mozilla's requirements) policy. On one hand, this is a BR violation by the issuing CA, and Mozilla nominally cares about BR violations for CAs subject to its requirements. On the other hand, the root cause is due to a TCSC, for which Mozilla policy explicitly carves out. Given that the issuing CA may be subjected to a qualified audit finding, on the basis of the the actions of the TCSC, it may be useful to understand Mozilla's position on this, as well as determine what guidance, if any, should be provided to auditors and to the CA/Browser Forum about this apparent disagreement between Mozilla Policy and the Baseline Requirements. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Announcement: Chrome requiring Certificate Transparency in 2017
在 2016年10月25日星期二 UTC+8下午11:39:31，Nick Lamb写道： > On Tuesday, 25 October 2016 15:45:26 UTC+1, Han Yuwei wrote: > > Is there any timetable for enforcing CAs to support embedded CT or OCSP CT? > > Well, the effect of Google's policy is that if you're a subscriber looking to > obtain certificates a year from now you have three options > > 1. Don't care about Chrome (though of course this policy may spread to other > browsers). That option might be attractive if your certificates are from the > Web PKI but aren't usually examined by browsers. For example in a mail > server, or in some financial applications. Otherwise it looks like a bad > choice. > > 2. Arrange to implement the TLS SCT extension from your servers and obtain > SCTs for yourself to pass on to browsers. This does not require any new > effort from the CA. This would meet Chrome's requirement entirely and is very > flexible, but can mean significant disruption or even the need for new > software development. Most customers again will see this as an undesirable > choice. > > 3. Choose a CA that can deliver SCTs with your certificates or maybe via OCSP > and in the latter case ensure your server software is compatible with that. > > I expect option (3) to be overwhelmingly popular, so that Google need do > little or nothing in the way of "enforcing" this support. Indeed all the big > public CAs either already have, or are known to be developing this capability. > > > Obviously Google needs to communicate this clearly to subscribers, and to a > lesser extent to Chrome users. I think a simple announcement ought to be > enough at this stage for CAs themselves, if you're operating a public CA in > 2016 and don't know what Certificate Transparency is you're in the wrong > business. But for the other two groups effective communication is important > over the next 12-24 months. In the ideal world the CAs would take on some of > the burden of informing their subscribers, but I think the SHA-1 experience > shows that's not always a very reliable path. First, I care about CT and I desperately want CT depolyment. I have tried to implement TLS SCT extension to my nginx but failed and I dont't why. Because I deployed OCSP stapling successfully so I want a embedded CT (best for everyone) or a OCSP response CT. So I am willing that CA could do more because they have much more resources than us. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Announcement: Chrome requiring Certificate Transparency in 2017
On Tuesday, 25 October 2016 15:45:26 UTC+1, Han Yuwei wrote: > Is there any timetable for enforcing CAs to support embedded CT or OCSP CT? Well, the effect of Google's policy is that if you're a subscriber looking to obtain certificates a year from now you have three options 1. Don't care about Chrome (though of course this policy may spread to other browsers). That option might be attractive if your certificates are from the Web PKI but aren't usually examined by browsers. For example in a mail server, or in some financial applications. Otherwise it looks like a bad choice. 2. Arrange to implement the TLS SCT extension from your servers and obtain SCTs for yourself to pass on to browsers. This does not require any new effort from the CA. This would meet Chrome's requirement entirely and is very flexible, but can mean significant disruption or even the need for new software development. Most customers again will see this as an undesirable choice. 3. Choose a CA that can deliver SCTs with your certificates or maybe via OCSP and in the latter case ensure your server software is compatible with that. I expect option (3) to be overwhelmingly popular, so that Google need do little or nothing in the way of "enforcing" this support. Indeed all the big public CAs either already have, or are known to be developing this capability. Obviously Google needs to communicate this clearly to subscribers, and to a lesser extent to Chrome users. I think a simple announcement ought to be enough at this stage for CAs themselves, if you're operating a public CA in 2016 and don't know what Certificate Transparency is you're in the wrong business. But for the other two groups effective communication is important over the next 12-24 months. In the ideal world the CAs would take on some of the burden of informing their subscribers, but I think the SHA-1 experience shows that's not always a very reliable path. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Announcement: Chrome requiring Certificate Transparency in 2017
在 2016年10月25日星期二 UTC+8上午8:45:26，Ryan Sleevi写道： > [Note: This is cross-posted. The best venue for follow-up questions is the > public mailing list at ct-pol...@chromium.org or the post at > https://groups.google.com/a/chromium.org/d/msg/ct-policy/78N3SMcqUGw/ykIwHXuqAQAJ > ] > [Note: Posting wearing my Chrome hat. None of this reflects Mozilla policy, > but is useful for the Mozilla community to be aware of] > > This past week at the 39th meeting of the CA/Browser Forum, the Chrome team > announced plans that publicly trusted website certificates issued in October > 2017 or later will be expected to comply with Chrome’s Certificate > Transparency policy in order to be trusted by Chrome. > > The Chrome Team believes that the Certificate Transparency ecosystem has > advanced sufficiently that October 2017 is an achievable and realistic goal > for this requirement. > > This is a significant step forward in the online trust ecosystem. The > investments made by CAs adopting CT, and Chrome requiring it in some cases, > have already paid tremendous dividends in providing a more secure and > trustworthy Internet. The use of Certificate Transparency has profoundly > altered how browsers, site owners, and relying parties are able to detect and > respond to misissuance, and importantly, gives new tools to mitigate the > damage caused when a CA no longer complies with community expectations and > browser programs. > > While the benefits of CT are clear, we recognize that some CAs, browsers, or > site operators may have use cases they feel are not fully addressed by > Certificate Transparency, and so may have concerns over the October 2017 > date. We encourage anyone who feels this way to bring their concerns to the > IETF’s Public Notary Transparency WG (TRANS) so that these use cases can be > discussed and cataloged. The information for this WG, and the documents it > works on, is available at https://datatracker.ietf.org/wg/trans/charter/. > > Although the date is a year away, we encourage any participants that wish to > have their use cases addressed to bring them forward as soon as possible > during the next three months. This will ensure that the IETF, the CA/Browser > Forum, and the broader community at large have ample time to discuss the > challenges that may be faced, and find appropriate solutions for them. Such > solutions may be though technical changes via the IETF or via policy means > such as through the CA/Browser Forum or individual browsers’ root program > requirements. > > We will continue outreach to CAs in trust stores used by Chrome to ensure > that they are prepared and that there is minimal user disruption. > > To further support these investments in Certificate Transparency, the Chrome > team will be discussing a proposed new HTTP header at next month’s IETF > meeting that would allow sites to opt-in to having CT requirements enforced > in advance of this deadline. > > Similarly, we welcome and encourage all CAs to voluntarily request that > browsers enforce CT logging of their new certificates before this deadline. > Doing so enhances CT's ability to protect users, detect misissuance, and in > the unfortunate event that misissuance does occur, to confirm the scope of > misissuance. This may allow browsers to take more targeted steps to remediate > the problem than otherwise possible, thus minimizing any negative impact to > their users. Is there any timetable for enforcing CAs to support embedded CT or OCSP CT? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
