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.
On 03/11/16 18:09, Andrew Ayer wrote: >> B) SHA-1 email certificates with no DNS names, although their lack of >> an EKU means they are valid for server auth (2 CAs) > > The more pertinent question is the issuing CA's EKU. In one case, I have now noticed that the intermediate is revoked in OneCRL. (Still learning how to use crt.sh.) In the other case, there are two certificates with the issuing key, and neither has an EKU. >> C) SHA-1 email certificates with EKU but no serverAuth (1 CA) > > Ditto. 2 certs with the issuing key, no EKU in either. >> 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. > The common thread in all of these answers is that the forged/collided > certificate need not look anything like the data that the CA signed > with SHA-1. Any time a CA trusted for serverAuth signs > attacker-controlled data using SHA-1 there is a risk of a forged > serverAuth certificate. Right. But if a CA has signed a cert or two in January and none since, one could perhaps surmise that SHA-1 issuance has ceased (albeit a few days after it should have). Which is why I question whether pursuing such cases now adds much value. Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
