On Tue, Feb 23, 2016 at 12:05 PM, Andrew Ayer <a...@andrewayer.name> wrote:
> On Tue, 23 Feb 2016 18:57:41 +0000 > Gervase Markham <g...@mozilla.org> 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
