5 ms·

This CCADB vote provides the context missing from this link to a Chromium patch. After the CA issuers rejected 2017 and 2019 proposals (Ballot 185, Ballot SC22)

• altfredd 6y ago
  Sounds like CAs will be forced to keep shrinking cert length until everyone standardizes on 1 month. They no longer have any real power.
  • floatingatoll 6y ago
    A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.
    • waheoo 6y ago
      Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure. Short cert lives make certain decloaking much, kuch more difficult.
      • gpm 6y ago
        It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key. It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs. [1] https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/
        • tialaramex 6y ago
          However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange. That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...
      • nyanpasu64 6y ago
        I heard perfect forward secrecy is intended to prevent decrypting past traffic.
    • paranoidrobot 6y ago
      Less labour intensive for whom? Anyone using email validation now needs to click a link every month, or their cert goes away. I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains. Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.
  • Avamander 6y ago
    CAs are resting all and every changes because it's easier, it makes sense.
    • londons_explore 6y ago
      CA's are resisting because the only person to buy from them is someone who can't set up certbot and lets-encrypt. As soon as they cant issue for longer than a year, their market is being whittled away.
      • majewsky 6y ago
        > the only person to buy from [CAs] is someone who can't set up certbot and lets-encrypt Digicert is in the process of migrating their customers to ACME (the issuance protocol used by Let's Encrypt and certbot). Where's your god now? :)
        • Avamander 6y ago
          And that's two out of how many?
  • brnt 6y ago
    Will browsers start allowing self signed certificates though?
    • randall 6y ago
      No... web of trust is an important aspect to https.
      • AlexandrB 6y ago
        s/web of trust/centralization/
        • judge2020 6y ago
          s/centralization/validating ownership Without centralization I can MITM at the coffee shop and steal passwords.
          • yjftsjthsd-h 6y ago
            WoT would fix that, unless the other coffee shop patrons have (directly or indirectly) trusted you.
    • cpach 6y ago
      As long as you first create a root certificate then you can create how many certificates you want.
      • dingaling 6y ago
        Assuming non-chained root CAs remain trusted. I can forsee the browsers eventually treating self-created CAs like they currently treat self-signed certs. if they're not traceable to a trusted root CA then there's no accountability, from a browser perspective, in the event of abuse or breach.
        • chongli 6y ago
  • tptacek 6y ago
    Good!
• tialaramex 6y ago
  Nit: It's CA/B Forum (Certificate Authority / Browser Forum, a standing meeting between the major browser vendors - which are also roughly the set of major OS vendors except Mozilla stands in for the Free Unixes - and the major publicly trusted Certificate Authorities). The original purpose of this meeting was to find common ground between these two groups and this has borne considerable fruit over the years in the from of the Baseline Requirements. CCADB is a totally different service run by Mozilla and Microsoft (using Salesforce, I presume because they both agree this is terrible but neither can accuse the other of using their preferred pet technologies?) notionally open to other trust stores to track lots of tedious paperwork for the relationship with trusted CAs. Audit documents, huge lists of what was issued by who and to do what, when it expires, blah blah blah. Like a public records office it's simultaneously fascinating and a total snooze fest. Mozilla is using it in this case to conduct their routine survey of CAs to check they understand what they're obliged to do, they're not asleep at the wheel and so on.