[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

[Kirk Hall]

Richard, I’ve always thought that if revocation checking worked in (say) 85% of OCSP or CRL queries and revealed to users that a bad cert had been revoked and a site should not be trusted, then we (CAs and browsers) were successfully protecting 85% of users who were visiting the bad site.  To me, that is a huge win.  If we can work to improve that figure to 98% or 99.9% over time or with new methods, even better.  But warning 85% of users of a revoked cert today is way better than warning 0% of users of a revoked cert as happens today when browsers don’t even bother checking for revocation.  (It’s like a highway commission saying “This guardrail won’t prevent 100% of accidents, so we won’t put up a guardrail at all” – if the guardrail stops 99% of accidents, it’s a good thing.)

If browsers always tell relying parties “Revocation checking doesn’t work”, then I guess that’s what relying parties will tend to believe over time – so no use asking what relying parties believe .  But if revocation checking works in the great majority of cases where it’s tried, then it is a major tool for user security that should be restored by browsers.

(And let’s not raise the issue “revocation checking can be blocked in a compromised environment, MITM, etc. so it’s never even worth trying in any environment” – that an extremely weak argument for giving up all revocation checking in the normal internet environment that the vast majority of users encounter, where revocation checking is not blocked and users can receive warnings of a revoked certificate.)

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Richard Barnes via Public
Sent: Friday, February 3, 2017 11:41 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Richard Barnes <rbarnes at mozilla.com>
Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

Is there anyone on the relying party side of the universe that believes revocation works?  Even among browsers that send OCSP requests, none of them hard-fail if it doesn't work, because in practice, OCSP servers are so awful that HTTPS would become unusable.  So OCSP is still, as AGL says, a seat belt that breaks when you crash.  Seems fair to call that broken.
Even if OCSP were magically to become usable, though, (or some replacement for it) this ballot would still be necessary for all the other reasons that have been discussed here.


On Fri, Feb 3, 2017 at 11:34 AM, Rich Smith via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
Ryan, since you're using your age old FUD "revocation doesn't work" (because certain browsers have chosen not to consult revocation information) as part of the reasoning as to why this ballot is necessary, I think it's quite germane to the discussion.

On 2/3/2017 11:38 AM, Ryan Sleevi via Public wrote:


On Fri, Feb 3, 2017 at 9:11 AM, Rob Stradling <rob.stradling at comodo.com<mailto:rob.stradling at comodo.com>> wrote:
Ryan, what targets (filesize/performance/reliability/reachability/etc) would CAs need to meet before it would become viable to reintroduce CRLs to the WebPKI (i.e., for Chrome to start checking CRLs and hard-failing if they're unobtainable)?

Happy to have that discussion at another time, but it's not germane to the discussion at hand, as I clearly indicated in the original message. It's necessary, but not sufficient, to have that, and we're not presently proposing addressing all the other necessary conditions. Baby steps.



_______________________________________________

Public mailing list

Public at cabforum.org<mailto:Public at cabforum.org>

https://cabforum.org/mailman/listinfo/public


_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170203/9b8b2c95/attachment-0003.html>