ro...@comodo.com wrote, On 2008-12-26 03:28: > We have finished our initial investigation on the certificates > issued by Certstar. > > Of the 111 orders that had been placed through Certstar there remain > 13 orders for which we have still not been able to gather adequate > evidence of the applicant having domain control. We have therefore, > regrettably, revoked the certificates on those orders. > > Of those 13 orders, 2 were placed by Eddy, for startcom.org and > www.mozilla.com, as he has already described. As we previously > stated, the certificate for www.mozilla.com was revoked shortly after > it was issued. > > Of the remaining 11 orders we do not have any reason to believe that > any were placed fraudulently and had we not set such a short timescale > to effect the (re-)validation and had it not been over this Holiday > season we believe that we would have been able to achieve validation > of domain control for all 11. > > Certstar have passed to us all of their records for these customers > and we will ensure that they are contacted for 2 purposes: > a) to check if it would have been possible to complete the re-validation > b) to offer a replacement certificate. > Some of the orders have either been charged-back or refunded. We have > to accept the possibility that some of those customers will not assist > us in re-validation. > > Regards > Robin Alden > Comodo
Robin, Thanks for that report. Speaking for myself only, I think that the speed with which you and Comodo dealt with this issue, once it became publicly known, and the integrity you & Comodo showed by revoking 11 certs (~10%) whose veracity simply could not be determined in a timely fashion, is commendable. Issues remain, and will continue to be discussed about how this situation came to be, and what new measures should be taken, and by whom, to minimize the probability of it ever happening again. But one clear conclusion from this episode is that there is not a single clear line of separation of responsibilities between CAs and RAs that applies to all CAs. Clearly several participants in this discussion were surprised that a CA would delegate the duty of validating domain control to an RA, and some opined that a CA ought to perform that duty itself. I'm not convinced that's necessary, but it certainly does seem that a CA firm ought to be prepared to deal with the possibility that an RA makes a (potentially big) mistake without sacrificing the CA firm's entire business. The challenge, in the event of an RA error, is to restore/maintain confidence in the integrity of the CA's PKI overall, while mitigating the potential damage from dubious enrollments. In this case, it was feasible to examine the data for ~90% of the RA's 111 enrollments in a reasonably short time. If the RA had enrolled 10 or 100 times as many, a much larger number (and probably a larger percentage) of the enrollments might not have been verifiable in such a short time. I wonder if it would have been perceived as feasible to revoke all the unverified certs in such a case, and still remain in business. I personally received numerous requests (mostly privately) asking for ways for browser users to effectively disable the trust for the certs issued under the auspices of this particular RA, at least until the veracity of those certs could be sorted out. As you and I discussed in bug 470897, the only options available to users, which would effectively distrust the entire PositiveSSL CA cert (or the entire root with all its subordinate CAs), would have also effectively distrusted the certs issued under the auspices of numerous other RAs. Hence that solution would not have been a good fit for the scope of the problem. Nevertheless, a number of people expressed to me the view that disabling trust in the subordinate CA that issued certs for that RA, while too broad of a measure, was nonetheless preferable to leaving themselves vulnerable to the possibility of false certificates. I sensed that they wanted the ability to take action that fit the scope of the potential problem well, and also was potentially reversible if and when things were finally sorted out (as it now seems they are). Had there been a separate CA issuing certs for this RA, the ability to disable trust for that CA cert and the ability to restore that trust at a later time (such as now) would have been much more satisfying to many, I believe. So, I would like to suggest that Comodo consider modifying its practices somewhat, to reduce the mismatch of scope between subordinate CAs and RAs. I suggest that Comodo operate a separate subordinate CA for each RA to whom Comodo has delegated validation duties. I suggest that a new subordinate CA be created for each such RA, and that all new certs issued for those RAs be issued from those new single-RA CAs. I am aware of at least one other commercial CA that operates that way, operating a separate subordinate CA for each RA to whom they have delegated validation duties. I believe that is a sound way to minimize the "collateral damage" that might need to be inflicted, even temporarily, to restore/maintain PKI integrity in the event of a breach. This is only my view. I look forward to Frank's thoughts on this subject. Regards, /Nelson Bolyard _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
