Large quantities of SHA-1 certificates were issued in the weeks prior to the deadline as operators of systems not intended for primarily browser based consumption maximized their remaining compliant lifespan, Embedded physical deployment of devices that are not updated at browser speed runs the gamut from car dashboard systems for aGPS to media set top boxes to other purpose built appliances in closed communities. This device certificate lifespan extension flood created far more collision surface than the 9 certificates in question that will be produced by an invested applicant with presumably no malicious intent to create intentionally collision prone requests or public keys designed to produce specific hashes. Statistically the actual risk to the public trust community of these 9 certs is a fraction of the certs issued in the last two months of 2015. The CA's client missed one part of their environment or else these renewals would have occurred late last year and this thread wouldn't exist. In fact, they would have had certificates valid later in 2016 than the Mozilla proposal offers.
Publicly trusted roots were often used in non-browser situations because you put two quotes in front of the customer. Here's the cost to create and manage your own dedicated multitier PKI. Here's the cost to leverage our existing infra. Many customers chose to live within the existing public trust PKI as a simple financial situation. Kind regards, Steve On Tue, Feb 23, 2016, 6:42 PM Richard Barnes <[email protected]> wrote: > On Tue, Feb 23, 2016 at 12:05 PM, Andrew Ayer <[email protected]> > wrote: > > > On Tue, 23 Feb 2016 18:57:41 +0000 > > Gervase Markham <[email protected]> wrote: > > > > > Please comment on whether this proposal seems reasonable, being aware > > > of the short timelines involved. > > > > I am opposed. There is no telling how many other organizations are in a > > similar situation due to poor planning or "oversights" on their part, > > and who will also want special treatment. Granting this exception will > > set an expectation that exceptions will be granted in the future and > > therefore that deadlines and deprecations need not be taken seriously. > > That would have a negative effect on efforts to move the security of > > the Internet forward. > > > > Multiple mistakes were made by Worldpay (using public roots, leaving > > the transition to the last minute, and then forgetting to renew before > > the sunset) and Symantec (failing to make sure their customer was > > prepared). They had ample opportunity to avoid a crisis. It is not > > Mozilla's responsibility to dig them out of the hole they have dug for > > themselves, and doing so is contrary to Mozilla's interest in keeping > > the Internet secure. > > > > Additionally, none of the stipulations in the proposal mitigate the > > risk of SHA-1 issuance. Disclosure and revocation do no good if an > > undisclosed, unrevoked certificate (possibly with CA:TRUE) can be > > collided with the disclosed and revoked certificate. > > > > You're correct that disclosure and revocation requirements don't directly > address issues of collisions. In fact, the lifetime constraint could > exacerbate the issue by causing more certs to be issued if the transition > takes too long. However, I think there are a few factors that mitigate > risk here. > > First, we should keep in mind that all known attacks on the PKI (AFAIK) by > way of hash functions have been via attacks on collision resistance, via > chosen prefix attacks. Constraining this to cases where we know precisely > who the applicants are significantly reduces the risk of that avenue of > attack, making it mostly a question of second preimage resistance, and > AFAIK, there's been no progress on that dimension of SHA-1. > > Second, as pointed out elsewhere in this thread, even if we don't trust the > certificate applicant, we can reduce the chosen prefix risk by requiring a > higher minimum serial number entropy. The usage of the serial number for > OneCRL precludes is reuse anyway. > > And finally, I think the lifetime constraint is worthwhile because it > provides a concrete incentive to upgrade in a timely fashion. > > Net of the above considerations, I think we have a acceptable mitigations > to the collision risks. > > --Richard > > > > > > > Regards, > > Andrew > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
