On Mon, Oct 28, 2013 at 12:28 PM, Jeremy Rowley <jeremy.row...@digicert.com> wrote: > There are lots of occasions: > 1) Where a server with a private key is missing but there isn't yet an > active attack > 2) Where the key was compromised > 3) Where an error occurred and the certificate information identified the > wrong entity > 4) Where the certificate was issued in accordance with the then-applicable > standards but standards have made the certificate untrustworthy (internal > names, 1024, SHA1) > 5) Where the certificate profile is incorrect (lacks the appropriate EKU or > requested with incomplete information) > > All of these are security concerns that don't have an active attacker and > where even a soft-fail revocation effectively mitigates the risk.
Those all seem like valid reasons to revoke a certificate. But, those aren't reasons for checking that a certificate has been revoked. In order for the revocation to actually matter to a normal Firefox user, the user must find himself in a scenerio like the one I previously described, right? Cheers, Brian > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla > .org] On Behalf Of Brian Smith > Sent: Monday, October 28, 2013 1:14 PM > To: Rick Andrews > Cc: dev-security-policy@lists.mozilla.org > Subject: Re: Netcraft blog, violations of CABF Baseline Requirements, any > consequences? > > On Mon, Oct 28, 2013 at 11:31 AM, Rick Andrews <r.andr...@computer.org> > wrote: >> Brian, you seem to be saying that revocation checking adds value only when > there's an attacker involved. If that's your point, I disagree. There are > cases in which a CA revokes a certificate because the site has > misrepresented itself, and revocation serves as a warning to the client. > > Thanks for the clarification. Could you give an example where such a > revocation would be useful to know about to a Firefox user to the extent > where the cost of doing the revocation checking is justified? > So far, I'm of the opinion when there's no attacker, there's no problem (no > harm, no foul). > > Cheers, > Brian > -- > Mozilla Networking/Crypto/Security (Necko/NSS/PSM) > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
