On Fri, 4 Nov 2016 10:30:00 +0000 Gervase Markham <g...@mozilla.org> wrote:
> We need to recall that currently, SHA-1 issuance is not banned > directly by Mozilla policy, but only by the BRs. And so we don't have > a route to object to certs not covered by the BRs. The March 2016 CA communication said[1]: "It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1." Therefore, CAs participating in the Mozilla program know that this practice is dangerous. Frankly, I'm disappointed that despite my efforts to draw attention to this issue in March, both in the context of non-serverAuth certificates[2] and OCSP responses[3], Mozilla took no further action, such as amending Mozilla policy or proposing a CABF ballot to plug this hole. > >> D) Small numbers (1 or 2) of SHA-1 certs issued in early January. > >> One could perhaps charitably say that the CA or their subCA made a > >> mistake, realised, has fixed it, and hasn't made it since. Now > >> it's November, is this worth chasing? (4 CAs) > >> > >> Also, does it make it better if the CA has already revoked the > >> certificate before we report it to them? > > > > No. Revocation doesn't help because the forged/collided cert need > > not share the same serial number. Revocation would only help if it > > were based on the SHA-1 hash of the TBSCertificate. > > We are not _just_ looking at SHA-1 issuance through the lens of > collision; it's also a compliance and competence issue. I think a CA > which issues a SHA-1 cert and doesn't notice seems less competent than > one which does notice and immediately revokes it and doesn't issue > another. If they had sent an incident report to Mozilla I would agree, but I do not think that CAs should be credited for noticing mistakes when they try to sweep them under the rug. This is particularly true in the case of SHA-1 misissuance, where revoking without broader notification demonstrates not competence but rather a lack of understanding of the risks. Regards, Andrew [1] https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o000000iHdtx [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/DEgLsxMfBAAJ [3] https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
