I am minded of the CRL entry reason "remove from CRL". Does NSS properly handle that reason-code?
If so, a temporary revocation of all unknown certificates might be a sound practice, removing them from the CRL as they're found and verified. We are running up against problems that are caused by absolute adherence to inflexible standards, and we're proposing mechanisms inside of the inflexible standards to deal with them. If there were a way to, say, have the CA include a unique, opaque code for the RA that submitted a CSR in the issued certificate, AND if there were a way to filter based on the content of an extension (rather than simply leaving it completely opaque, which leads to the current problem), then there would be no need for a separate CA for each RA. -Kyle H On Fri, Dec 26, 2008 at 5:38 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: > 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 > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
