Gervase Markham wrote: > If revoked certificates have to be listed even when expired, that means > that expired certificates have to be revoked if the private key is > compromised. Yes, I would suppose that. Or a private key has to be destroyed correctly in first place. > So, the certificate holder has to continue to keep the key > secure even after expiry. > Absolutely! First of all a private key can be reused many times over for new certificate requests. Actually you can use the same private key for hundreds of certificates (not common practice but still possible). If a private key is compromised after a certain certificate expired, than this key could be still misused...Or lets try it the other way around: Please publish the private key of the web site mozilla.com or microsoft.com after the certificate expires next time...will you please?
>> Revocation of a certificate is not something which should be taken >> lightly - it certainly isn't equivalent to expiration. >> > > No-one is saying it is. But it is also pretty unlikely that a > certificate would be revoked close to its expiration date. And what if it does happen? > If a certificate is issued incorrectly, for example, these sort of things > tend to be discovered rather quickly (like when the phisher sets up his > site). > And what if not? They will get smarter too perhaps, so phishers aren't interested in this..but some real crime would... > Can you give a plausible and specific scenario where keeping certs in > CRLs significantly past their expiration date would prevent some evil > activity? > Sure! 1.) Supposed the certificate was issued to a party not eligible for this type of certificates (i.e. a reason for revocation whatever the cause), the owner of the certificate can continue to use the certificate in question (after it expired). All a visitor will see is, that the certificate expired. Do you know how many computer savvy users continue to trust that certificate, not talking about the standard user who doesn't have a clue? The computer and Internet savvy will say: " Oh well...the certificate just expired a few month ago...that's fine, I can still trust it....after all it was issued by XYZ and even an EV certificate..." 2.) Supposed the private key was stolen from the owner (maybe by some disgruntled admin of the company or some criminal working at a hosting company perhaps)...Supposed this was recognized correctly, dutifully reported and the certificates was revoked. But as soon as it expires, it can be used again....all what would happen is a warning message that it expired...which isn't really the same! The fact that connections to expired certificates are allowed by most if not all browser vendors contributes to this problem, if this certificate is removed from the CRL...than it's just an expired certificate which was once valid, compared to a certificate which is actually revoked. > > You're never satisfied, are you, Eddy? <sigh> What happened at the > meeting was a big step forward towards allowing non-Webtrust auditors to > do EV readiness audits. > Well, I was also reading your "CAB Forum meeting report" and it's indeed a step into the right direction...But still, I think the principal question about the character of this organization just remains. Currently only webtrust accredited auditors can perform the EV audit if I understood correctly...(Correct me if I'm wrong). I can understand, that webtrust and its accredited auditors want to protect their investment, but our agenda is a different one and obviously I don't have to be satisfied with it. But what really surprises me is, that why such principal and important decisions about the type and nature of the proposed forum weren't made at its founding? Why weren't openness (in respect to participation, audits, etc) one of the key conditions for Mozilla? Crawling now back and trying to open it up is obviously much harder and I congratulate you for every success you achieve. -- 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
