7 ms·

Justification: > The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is bec

Justification: > The ballot argues that shorter lifetimes are necessary for many reasons, the most prominent being this: The information in certificates is becoming steadily less trustworthy over time, a problem that can only be mitigated by frequently revalidating the information. > The ballot also argues that the revocation system using CRLs and OCSP is unreliable. Indeed, browsers often ignore these features. The ballot has a long section on the failings of the certificate revocation system. Shorter lifetimes mitigate the effects of using potentially revoked certificates. In 2023, CA/B Forum took this philosophy to another level by approving short-lived certificates, which expire within 7 days, and which do not require CRL or OCSP support. Personally I don't really buy this argument. I don't think the web sites that most people visit (especially highly-sensitive ones like for e-mail, financial stuff, a good portion of shopping) change or become "less trustworthy" that quickly.

gruez 1y ago
The "less trustworthy" refers to key compromise, not the e-shop going rogue and start scamming customers or whatever.
- throw0101a 1y ago
  Okay, the key is compromised: that means they can MITM the trust relationship. But with modern algorithms you have forward security, so even if you've sniffed/captured the traffic it doesn't help. And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry.
  - gruez 1y ago
    >And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry. By that logic, we don't really need certificates, just TOFU.
    - throw0101d 1y ago
      > By that logic, we don't really need certificates, just TOFU. It works fairly well for SSH, but that tends to be a more technical audience. But doing a "Always trust" or "Always accept" are valid options in many cases (often for internal apps).
      - tptacek 1y ago
        It does not work well for SSH. We just don't care about how badly it works.
        throw0101d 1y ago
        > It does not work well for SSH. We just don't care about how badly it works. How "should" it work? Is there a known-better way?
        tptacek 1y ago
        Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI).
        throw0101d 1y ago
        > Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI). I am aware of them. As someone in the academic sphere, with researchers SSHing into (e.g.) HPC clusters, this solves nothing for me from the perspective of clients trusting servers. Perhaps it's useful in a corporate environment where the deployment/MDM can place the CA in the appropriate place, but not with BYOD. Issuing CAs to users, especially if they expire is another thing. From a UX perspective, we can tie password credentials to things like on-site Wifi and web site access (e.g., support wiki). So SSH certs certainly have use-cases, and I'm happy they work for people, but TOFU is still the most useful in the waters I swim in.
        tptacek 1y ago
- xurukefi 1y ago
  Nobody forces you to change your key for renewals.

gruez 1y ago

The "less trustworthy" refers to key compromise, not the e-shop going rogue and start scamming customers or whatever.

throw0101a 1y ago
Okay, the key is compromised: that means they can MITM the trust relationship. But with modern algorithms you have forward security, so even if you've sniffed/captured the traffic it doesn't help. And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry.
- gruez 1y ago
  >And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry. By that logic, we don't really need certificates, just TOFU.
  - throw0101d 1y ago
    > By that logic, we don't really need certificates, just TOFU. It works fairly well for SSH, but that tends to be a more technical audience. But doing a "Always trust" or "Always accept" are valid options in many cases (often for internal apps).
    - tptacek 1y ago
      It does not work well for SSH. We just don't care about how badly it works.
      - throw0101d 1y ago
        > It does not work well for SSH. We just don't care about how badly it works. How "should" it work? Is there a known-better way?
        tptacek 1y ago
        Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI).
        throw0101d 1y ago
        > Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI). I am aware of them. As someone in the academic sphere, with researchers SSHing into (e.g.) HPC clusters, this solves nothing for me from the perspective of clients trusting servers. Perhaps it's useful in a corporate environment where the deployment/MDM can place the CA in the appropriate place, but not with BYOD. Issuing CAs to users, especially if they expire is another thing. From a UX perspective, we can tie password credentials to things like on-site Wifi and web site access (e.g., support wiki). So SSH certs certainly have use-cases, and I'm happy they work for people, but TOFU is still the most useful in the waters I swim in.
        tptacek 1y ago
xurukefi 1y ago
Nobody forces you to change your key for renewals.