Nick,
Thanks for the heads-up.
We agree that the certificates you found should have been revoked.
We revoked a body of certificates on 1st October 2016 in accordance with
7.1.4.2.1.
Regrettably a mistake was made when we created the list of certificates to
be revoked.
As a word of background we track replacement certificates within the
lifetime of a particular certificate order, in part to avoid unnecessary
certificate revocations and associated CRL bloat.
E.g. If a customer requests (and we issue) a certificate C1 for key k1 with
domains d1.dom, d2.com, and subsequently requests (and has issued) a
replacement certificate for C2 {k1, d1.com, d2.com, d3.com} we do not
automatically revoke the prior certificate - although we reserve the right
to do so.
Our error in creating the list of certificates to be revoked was in not
including in that list certificates for which a replacement certificate had
been requested.
We had two people independently, using different methods, produce the list
of certificates to be revoked today to increase confidence in the result.
This has led us to revoke 28 further certificates, including the 2 that you
brought to our attention.
Here are links to the certificates we have revoked today. All but 3 are
newly published today to CT.
https://crt.sh/?id=1246507
https://crt.sh/?id=1825806
https://crt.sh/?id=39425459
https://crt.sh/?id=74893260
https://crt.sh/?id=74893262
https://crt.sh/?id=74893264
https://crt.sh/?id=74893267
https://crt.sh/?id=74893270
https://crt.sh/?id=74893273
https://crt.sh/?id=74893275
https://crt.sh/?id=74893278
https://crt.sh/?id=74893281
https://crt.sh/?id=74893284
https://crt.sh/?id=74893286
https://crt.sh/?id=74893289
https://crt.sh/?id=74893292
https://crt.sh/?id=74893295
https://crt.sh/?id=74893297
https://crt.sh/?id=74893299
https://crt.sh/?id=74893301
https://crt.sh/?id=74893303
https://crt.sh/?id=74893305
https://crt.sh/?id=74893307
https://crt.sh/?id=74893308
https://crt.sh/?id=74893310
https://crt.sh/?id=74893312
https://crt.sh/?id=74893314
https://crt.sh/?id=74893317
Thank you for your diligence.
Regards
Robin Alden
Comodo
> -----Original Message-----
> From: dev-security-policy On Behalf Of Nick Lamb
> Sent: 06 January 2017 09:52
> To: [email protected]
> Subject: Re: Compliance with 7.1.4.2.1 (internal names revocation)
>
> Work continues. After the initial good news, to my surprise the second
> million or so certificates processed threw up some deviations from major
> public CAs
>
> Comodo
> https://crt.sh/?id=1246507
> https://crt.sh/?id=1825806
>
> Verisign / Symantec
> https://crt.sh/?id=1450883
>
> I would appreciate feedback, generally from m.d.s.policy participants
about
> whether they believe that for some reason these certificates did not need
to
> be revoked to achieve compliance with 7.1.4.2.1 and specifically from
> Comodo and Symantec on why the certificates weren't in fact revoked.
>
> I would also be interested in learning whether auditors would be expected
to
> identify and report this deviation.
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
