> This fixing of the notAfter date in this style of certificate may > have been a sensible move to avoid accidentally issuing SHA-1 > certificates whose validity extends into 2017, which would also be a > BR violation.
This contradicts the "Issue D" section at https://wiki.mozilla.org/CA:WoSign_Issues which says that this issue was not a BR violation. > Many of the rest of the Macau certificates, which do not have an > embedded SCT to show when they were issued, have "matching" > SHA-256 versions issued at some point in 2016, with everything the > same except the issuing intermediate certificate, the hash algorithm > and the notBefore/notAfter dates. This hints at the possibility that > the two certificates were actually issued at the same time, and the > date in the SHA-256 version is the correct issue date for both. If > this is true, it shows misissuance continued until at least June 2016 > (*.zlbaba.com SHA-1, SHA-256). The two *.zlbaba.com certificates (https://crt.sh/?id=30773543 and https://crt.sh/?id=31103218) do not appear to be matching to me: their public keys and serial numbers are different. > Should StartCom/WoSign be permitted to re-apply using the same roots, > or would they need new roots? New roots. Considering the extent to which StartCom/WoSign have mismanaged things, there could be further misissued certificates chaining to their roots that we don't know about. The only way to protect the ecosystem from such certificates is to require new roots - roots that have only ever operated under the new audits that will be required by Mozilla. Regards, Andrew _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
