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

Tue Feb 7 03:34:38 UTC 2017

> * No, not really.  Expired certificates let you click-through while
revoked certificates are a hard fail, the way it should be (per Rob)

I don't think this (or Rob's original comment) are accurate as stated.

*If* revocation messages are presented, Firefox disallows clickthrough. But
Firefox doesn't fail on an absence of revocation data (which is what "hard
fail" means), and Chrome doesn't implement revocation for most situations
at all. IIRC, I don't believe that Safari or IE/Edge hard fail on
revocation errors either.

So during many kinds of attack, a revoked certificate *can* be silently
used, without generating any warnings at all. If the certificate is added
to OneCRL, crlset, or MS' disallowedcert list, that's a hard-fail, but
that's obviously not "revocation" at scale.

On the other hand, expired certificates will reliably generate
interstitials in all modern browsers. Some users may click through those
warnings. However, site owners can use HSTS to disallow clickthrough of all
warnings, including expired certificates. This is a major reason why the US
government requires HSTS of public-facing federal web services (
https://https.cio.gov).

Even without HSTS present, expired certificates *can**not* be silently used
in most attacks (a warning will be seen) -- and site owners have a way to
easily opt in to HSTS to prevent users from clicking through those warnings.

So yes, I would classify expiration as a much more effective way of ending
a certificate's utility than revocation, and I would not classify Firefox's
disabling of clickthrough for revoked certificates as "hard fail".

-- Eric

On Mon, Feb 6, 2017 at 5:25 PM, Doug Beattie via Public <public at cabforum.org
> wrote:

>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Friday, February 3, 2017 6:01 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of
> Certificates
>
>
>
> I'll try to simplify the replies, because it seems that giving a long list
> of reasons is causing too much confusion:
>
> * I agree, but I think there were some meaningful responses to the
> concerns you raised.  This long email may be better served via a
> collaborative document or wiki, then follow up at the F2F.  I’ll see what I
> can do, because there are valuable points that were dropped in this
> response.
>
>
>
> * Did you know that Google’s CAA record is not correct? – Google is
> issuing SSL certificates to their domains but google.com is not listed in
> the CAA record.  Am I misinterpreting CAA?
>
>   https://toolbox.googleapps.com/apps/dig/#ANY/google.com
>
>   *google.com <http://google.com>. 86399 IN CAA 0 issue "symantec.com
> <http://symantec.com>"*
>
> * Current CPS says you’re not checking CAA – as the proponent of CAA
> shouldn’t you be checking it, else how can you criticize CAs for dragging
> their feet?
>
> https://static.googleusercontent.com/media/pki.google.com/en
> //GIAG2-CPS-1.4.pdf
>
>
>
>
>
> 1) Do you acknowledge and agree that a shorter-lived certificate makes for
> a natural revocation?
>
> * No, not really.  Expired certificates let you click-through while
> revoked certificates are a hard fail, the way it should be (per Rob)
>
> * Phishing sites that have a 3 month certificate and that are identified
> on day 1 as being bad have a full 89 days to continue phishing without
> certificate expiration, so, there is no help with shorter validity period
> certificates there
>
> * Wouldn’t a WebPKI revocation system help more than shorter validity
> period certificates?
>
>
>
> 2) Do you acknowledge and agree that a shorter-lived certificate ensures
> that policies regarding new issuance can come in effect quicker than the
> current system?
>
> * Yes, but at I apparently place less value on this than you do.  Based on
> issuance date you know what policy it was issued under.  As I’ve said
> repeatedly, short validity certificate would have had no benefit to SHA-1
> deprecation because it was the relying party applications that needed to be
> updated.
>
>
>
> What real world benefit of recent changes would have we have realized if
> we had 1-year max validity period in the past 3 years?
>
>
>
> CT: The set of log servers is just getting to the point of being robust
> and stable and we’re all moving that way. Some CAs are ahead of others.
>
> CAA – Google isn’t even doing CAA for their CAs yet, so how important can
> it really be?
>
> SHA-1 – as I’ve said before, not related to short validity certificates
>
>
>
> So, what changes have we made or what changed do we envision needing to be
> applied to all active certificates in order for them to be trusted?  I
> suggested in the last email making DV short validity – can we at least try
> to build agreement on that before we boil the ocean?  I might even OK with
> warning users that receive certificates that are valid longer than 18+-
> months that they may need to reissue them to be trusted by browsers before
> they expire, if that helps get us to agreement.  What do you think of baby
> steps and making at least some progress forward?
>
>
>
>
>
>
>
> Your attempts to ignore the SHA-1 issue are surprising. I would have
> thought the data that Microsoft shared regarding their efforts to deprecate
> this - due to the security risk to their users - while minimizing impact -
> would have unquestionably shown why this was necessary. To recap and
> refresh - the significant challenge reported was due to the long-lived
> nature of the certificates meaning that disabling SHA-1 - thus protecting
> the ecosystem - would and did cause considerable impact.
>
> * The issue with SHA-1 deprecation came from the user base where
> applications and systems just didn’t support SHA-256 and not CAs. I keep
> saying this is a bad example of a policy change that would have benefited
> from shorter validity period certificates.  I hope we can agree on this and
> drop deprecation of SHA-1 as a reason for needing shorter validity
> certificates.
>
>
>
> The irony here of your objections to continuing the SHA-1 discussion is
> that, anticipating these problems, Google tried to help communicate to
> users and site operators the risk that CAs' repeated failures would cause,
> and the CA Security Council objected to this. So we have a situation where
> CAs are not actually trying to help the ecosystem (or their users) be more
> secure, we have ample evidence how the practice of long-lived certs
> prevents meaningful improvement, and CAs objecting to any and all efforts
> to improve the ecosystem to date that don't involve CRLs/OCSP, a set of
> unusable technologies in part due to CAs poisoning that well. That's not a
> healthy ecosystem.
>
>
>
> Let’s identify the problems that we want to solve and come up with
> solutions rather than forcing a solution on the industry and trying to
> justify it.  I don’t know about the other CAs, but GlobalSIgn is fine with
> short validity certificates as long as all of our customers are.  Changing
> the max validity period is trivial. What we keep missing here is that the
> consumers of SSL certificates need to be part of this discussion, in fact,
> they are THE key element and the solutions needs to align with their
> technical and business needs.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>

-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170206/c5aa34ad/attachment-0003.html>