Hi Kurt, On 26/09/16 23:45, Kurt Roeckx wrote: > In their report and the audit statement they talk about 392 > duplicate serial numbers, with links to the crt.sh page for those > serial numbers. > > But they in fact actually point to 393, the first group has 314 > and not 313 duplicates in it. This was already the case before > they published their new report. > > The last one in the group of 314 has the oldest SCT from September > the 7th. But the whole group was from 4 days during 2015 which we > were told were all send to the CT logs a week before that. This is > the one that was added later: https://crt.sh/?id=31258021
We don't know who sends certs to the log. It could be that WoSign sent this one in late, or it could be that someone else discovered it on the web somewhere. This might speak to WoSign not having complete track of all their certs, but without more evidence it's risky to speculate. > What is also not very clear from their report is that the > duplicates in the 314 group seem to have been from 2 different > issues. It seems there are also that belong to issue F: Yes, that seems to be the case. The time period of when Issue F was active matches up. > Looking at other cases for duplicate serial numbers, I also find > those not mentioned in the report: > > 2 for the same CA, but different URIs in it: > https://crt.sh/?serial=44807b207cf2052e8d3411770266d295&iCAID=1450 > > 2 for the same CA with order fields different, and different URIs: > https://crt.sh/?serial=3adec402270bf4ee9e892cc65e0ada21&iCAID=1450 Both of these are intermediates. Reissuing intermediates with new information but the same serial number and key AIUI does happen occasionally, although now I think about it, I guess it's as much an RFC violation as when CAs do it with EE certs. Do any PKI people want to chime in with views on this practice? Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
