Gervase Markham wrote: > Like everything, it's a trade-off - keeping revoked certificates in CRLs > has a cost (download time and bandwidth, requirement to keep key secret) > vs. the potential gain of being able to send a stronger warning signal > in this rather rare case. > A revoked certificate is perhaps the most serious event in the PKI - never mind for which reason! In my opinion, there is no cost too high to prevent a user from a) knowing about its state and b) accessing such a site. In this case, the strongest signal must be sent, as it happens today (i.e. error message and denying access to the site). However soon after it expires it's "upgraded" to a...well, expired certificate.
But seriously, as you suggested by yourself, how many revocations will there actually be? If these are going to be rather rare cases, then I guess, that any CA issuing EV certificates can "afford" to keep these revoked certs on the list - which is a very small price to pay for preventing fraud! Since one of the intentions of EV is to prevent fraud by performing "extended validation", it would be a serious deflation in my opinion... > Indeed. For Firefox 3, we plan to treat revoked and expired equally, > preventing access in both cases. > > Does that address your concern? > Obviously this would solve the specific problem...is there an open bug concerning that? Has it been debated which impact such an implementation would have on all sides? Certainly for S/MIME, this is going to be very problematic and in my opinion we'll be back to square one, i.e. have revoked certificates not removed from the CRL. > > It's easy to say such things with the benefit of hindsight. Sure! And there is always something to learn after all... ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Phone: +1.213.341.0390 _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
