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

Reply via email to