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

Ryan Sleevi sleevi at google.com
Fri Feb 3 21:10:49 UTC 2017


Kirk,

While I understand you have a different view of how browsers should work, I
think it might be more useful and productive to this discussion to
acknowledge that browsers (and to the broader extent, relying parties) have
disagreed your premise - and more generally, security practitioners outside
of the Antivirus Industry (in particular) recognize your approach to
security as flawed.

However useful this discussion, though, it might be more useful if CAs
could focus on specific reasons or challenges that the ballot would impose,
particularly considering the (many) benefits I outlined in my reply to Doug.

Concretely, I think there's an onus on CAs to show that these (considerable
and meaningful) benefits are somehow overshadowed by the cost. To date,
we've yet to see any evidence or counter-point that somehow users would be
_less_ secure with the proposal.

On Fri, Feb 3, 2017 at 12:07 PM, Kirk Hall via Public <public at cabforum.org>
wrote:

> 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> 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>
> 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
>
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> 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/fd9a51d6/attachment-0003.html>


More information about the Public mailing list