On 28/10/16 16:11, Patrick Figel wrote: > I found a number of SHA-1 certificates chaining up to CAs trusted by > Mozilla that have not been brought up on this list or on Bugzilla yet.
Using the handy crt.sh link posted by Rob, I have gone through the 2016 SHA-1 issuances known to crt.sh to filter out those which chain up to a root trusted by Mozilla. (Handily, crt.sh contains this information as well.) There are a distressingly large number of them :-( Based on Patrick's report, I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1313874 (Gov of Spain) https://bugzilla.mozilla.org/show_bug.cgi?id=1313872 (DigiCert) https://bugzilla.mozilla.org/show_bug.cgi?id=1313873 (DocuSign) and based on this additional research, I have filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1315019 (TeliaSonera) https://bugzilla.mozilla.org/show_bug.cgi?id=1315016 (Visa) https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 (GlobalSign) https://bugzilla.mozilla.org/show_bug.cgi?id=1315035 (T-Systems) There may be more in the future. I would be interested in the group's opinion on what to do about: A) SHA-1 precerts with no actual cert logged (1 CA) B) SHA-1 email certificates with no DNS names, although their lack of an EKU means they are valid for server auth (2 CAs) C) SHA-1 email certificates with EKU but no serverAuth (1 CA) 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? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
