7 ms·

Google has recently imposed a rule that CA roots trusted by Chrome must be used solely for the core server-authentication use case, and can't also be used for o

Google has recently imposed a rule that CA roots trusted by Chrome must be used solely for the core server-authentication use case, and can't also be used for other stuff. They laid out the rationale here: https://googlechrome.github.io/chromerootprogram/moving-forward-together/#phase-out-multi-purpose-roots-from-the-chrome-root-store https://googlechrome.github.io/chromerootprogram/moving-forw... It's a little vague, but my understanding reading between the lines is that sometimes, when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-Web-PKI use cases with different cost-benefit profiles on security vs. availability, and the browser vendors want that to stop happening. Let's Encrypt could of course continue offering client certificates if they wanted to, but they'd need to set up a separate root for those certificates to chain up to, and they don't think there's enough demand for that to be worth it.

kej 9mo ago
>when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-Web-PKI use cases Do you (or anyone else) have an example of this happening?
- agwa 9mo ago
  After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates. They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of. The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong. A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/RHBHXJOG8Io/m/5_H_NzZhAQAJ https://groups.google.com/g/mozilla.dev.security.policy/c/RH... [2] https://groups.google.com/g/mozilla.dev.security.policy/c/yhq6QNhEQok/m/9sdadL9kFwAJ https://groups.google.com/g/mozilla.dev.security.policy/c/yh... [3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM9tkZR9mLM/m/ACBIRX7GAAAJ https://groups.google.com/g/mozilla.dev.security.policy/c/LM...
  - account42 9mo ago
    But this has nothing to do with clientAuth as in this case the payment processor uses a server certificate and terminal connect to the payment processor, not the other way around. So this change would not have prevented this and I don't see what browsers can do to prevent it - after all, the exact same situation would have happened if the payment processors used a HTTPS-based protocol.
    - sam_lowry_ 9mo ago
      I believe the explanation. The collateral damage is huge, but Google couldn't care less.
    - Ajedi32 9mo ago
      Yeah, the more I think about it the more futile this effort starts to look. The industry is investing tons of resources into building and maintaining an open, highly secure PKI ecosystem which allows any server on the public internet to cryptographically prove its identity, and Google wants to try to prevent anyone who's not a web browser from relying on that ecosystem? Seems impossible. The incentives are far too strong. Google is hoping that after this change other TLS clients will go off and build their own PKI entirely separate from the web PKI, but in reality that would take way too much redundant effort when the web PKI already does 99% of what they want. What will actually happen is clients that want to use web certs for client authentication will just start ignoring the value of the extendedKeyUsage extension. The OP says Prosody already does. I don't see how that's an improvement to the status quo.
      - sam_lowry_ 9mo ago
        European eIDs are knows to disallow encryption, only signature. If software like OpenSSL will starts to ignore intent... Good for us, the citizens.
      - vikkymelani 9mo ago
        [dead]
detourdog 9mo ago
I’m disappointed that a competitor doesn’t exist that uses longevity of IP routing as a reputation validator. I would think maintaining routing of DNS to a static IP is a better metric for reputation. Having unstable infrastructure to me is a flag for fly by night operations.
- ocdtrekkie 9mo ago
  Well, be prepared for certificates that change every 7 to 47 days, as the Internet formally moves to security being built entirely on sand.
  - webstrand 9mo ago
    I wonder if this is a potential "off switch" for the internet. Just hit the root ca so they can't hand out the renewed certificates, you only have to push them over for a week or so.
    - gus_massa 9mo ago
      People will learn to press all the buttons with scarry messages to ignore the wrong certificates. It may be a problem for credit cards and online shopping.
      - ocdtrekkie 9mo ago
        HSTS was specifically designed to block you from having any ignore buttons. (And Firefox refuses to implement a way to bypass it.) But this is also why the current PKI mindset is insane. The warnings are never truly about a security problem, and users have correctly learned the warnings are useless. The CA/B is accomplishing absolutely nothing for security and absolutely everything for centralized control and platform instability.
        blibble 9mo ago
        > The CA/B is accomplishing absolutely nothing for security and absolutely everything for centralized control and platform instability. is it their fault? with the structure of the browser market today: you do what Google or Apple tell you to, or you're finished as a CA the "forum" seems to be more of a puppet government
RobotToaster 9mo ago
Isn't LE used for half the web at this point? Calling Google's bluff and seeing if they would willingly cut their users off from half the web seems like an option here.
- bawolff 9mo ago
  That's not how this would work. Based on previous history where people actually did call google's bluff to their regret, what happens is that google trusts all current certificates and just stops trusting new certs as they are issued. Google has dragged PKI security into the 21st century kicking and screaming. Their reforms are the reason why PKI security is not a joke anymore. They are definitely not afraid to call CA companies bluff. They will win.
  - xg15 9mo ago
    How is "client certificates forbidden" in any way an improvement?
    - Avamander 9mo ago
      Not forbidden, just not going to be a part of WebPKI. It's one of those things that has just piggybacked on top of WebPKI and things just piggybacking is a bad idea. There have been multiple cases in the past where this has caused a lot of pain for making meaningful improvements (some of those have been mentioned elsewhere in this thread).
      - xg15 9mo ago
        What exactly do you mean with "WebPKI"? The PKI system was designed independently of the web and the web used to be one usecase of it. You're kind of turning that around here.
        Avamander 9mo ago
        The idea of a PKI was of course designed independently, there are many very large PKIs beyond WebPKI. However the one used by browsers is what we call WebPKI and that has its own CAs and rules. You're trying to make it sound like there has ever been some kind of an universal PKI that can be used for everything and without any issues.
xg15 9mo ago
This sounds a lot like the "increasing hostility for non-web usecases" line in the OP. In theory, Chrome's rule would split the CA system into a "for web browsers" half and a "for everything else" half - but in practice, there might not be a lot of resources to keep the latter half operational.
- Ajedi32 9mo ago
  In practice this might just mean that applications designed to use web PKI certs start ignoring the value of the extendedKeyUsage extension. OP says Prosody already does this.
  - ameliaquining 9mo ago
    Well, if libraries like OpenSSL check extendedKeyUsage by default but provide an option to disable this, then most apps benefit from more stringent security, but ones like Prosody with unusual use cases can continue to make those use cases work. That doesn't sound like the worst thing in the world, necessarily? (I'm not sure how Prosody actually implemented this, though, or whether OpenSSL actually works that way.)
ge0rg 9mo ago
It is really great how they write "TLS use cases" and in fact mean HTTPS use cases. CA/Browser Forum has disallowed the issuance of server certificates that make use of the SRVName [0] subjectAltName type, which obviously was a server use case, and I guess the only reason why we still are allowed to use the Web PKI for SMTP is that both operate on the server hostname and it's not technically possible to limit the protocol. It would be perfectly fine to let CAs issue certificates for non-Web use-cases with a different set of requirements, without the hassle of maintaining and distributing multiple Roots, but CA/BF deliberately chose not to. [0] https://community.letsencrypt.org/t/srvname-and-xmppaddr-support/96026/3 https://community.letsencrypt.org/t/srvname-and-xmppaddr-sup...
notepad0x90 9mo ago
Why can't Let's Encrypt push-back on this for their users' sake? What is Google going to do? distrust LE certs?
- agwa 9mo ago
  Google Chrome (along with Mozilla, and eventually the other root stores) distrusted Symantec, despite being the largest CA at the time and frequently called "too big to fail".
  - notepad0x90 9mo ago
    Given how ubiquitous LE is, I think people will switch browsers first. non-chrome browsers based on chrome are plenty as well, they can choose to trust LE despite Chrome's choices. Plus, they had a good reason with Symantec, a good reason to distrust them that is. This is just them flexing, there is no real reason to distrust LE, non-web-pki does not reduce security.
    - nightpool 9mo ago
      GP gave a very good reason that non-web-PKI reduces security, you just refused to accept it. Anybody who has read any CA forum threads over the past two years is familiar with how big of a policy hole mixed-use-certificates are when dealing with revocation timelines and misissuance.
      - account42 9mo ago
        There was no good reason given only a "trust me bro".
      - sam_lowry_ 9mo ago
        > non-web-PKI reduces security How exactly?
      - notepad0x90 9mo ago
        "it's complicated" is not the same as "it's insecure". Google feels like removing this complexity improves security for web-pki. Improving security is not the same as saying something is insecure. Raising security for web-pki is not the same as caliming non-web-pki usage is insecure or is degrading security expectations of web-pki users. It's just google railroading things because they can. You can improve security by also letting Google decide and control everything, they have the capability and manpower. But we don't want that either.
thayne 9mo ago
So that argues against including CAs that don't issue server authentication cerificates. That's somewhat reasonable, although it does put non-browser use cases in an awkward position, since there isn't currently a standard distribution channel for trusted CAs that is independent of browsers. But prohibiting certs from being marked for client usage is mostly unrelated to that goal because: 1. There are many non-web use cases for certificates that are only used for server authentication. And 2. There are use cases where it makes sense to use the same certificate used for web PKI as a client with mTLS to another server using web PKI, especially for federated communication.
account42 9mo ago
> Moving Forward, Together The title alone tells you that they are fully aware that they are fucking others over and don't care one bit. In a better world this kind of manipulative language would get you shamed and ostracized but somehow it's considered professional communication.
- deleted 9mo ago
  [deleted]
greatgib 9mo ago
Again, it is showing that Google is clearly having a too big monopoly and abusing it.
zarzavat 9mo ago
Sounds like a bunch of hot air. What is Google going to do, blacklist LE and break half of the web? I think LE could just ignore this.
philipwhiuk 9mo ago
> In some cases, this approach actively harms both subscribers and CA Owners. I do hate this vagueness. What cases? Identify at least one.
throw0101a 9mo ago
> Let's Encrypt could of course continue offering client certificates if they wanted to, but they'd need to set up a separate root for those certificates to chain up to, and they don't think there's enough demand for that to be worth it. Why an entire new root? Perhaps set up a ACME profile [1] where the requestor could ask for clientAuth if their use case would be helped; the default would be off. Google would be free to reject with-clientAuth HTTPS server certificates in their browser, but why should they care if a XMPP or SMTP server has a such a certificate if the browser never sees it? [1] https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/ https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/
- Ajedi32 9mo ago
  That's not allowed. > To qualify as a dedicated TLS server authentication PKI hierarchy under this policy: > All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an applicant root CA MUST: > [...] > when disclosed to the CCADB… > [...] > on or after June 15, 2025, include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. > [...] > NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values. https://googlechrome.github.io/chromerootprogram/policy-archive/policy-version-1-7/#421-applicant-pki-hierarchies https://googlechrome.github.io/chromerootprogram/policy-arch...
  - throw0101a 9mo ago
    > That's not allowed. According to Google. Why do they get to dictate this? Per the current (2.2.2) CAB requirements [1], §7.1.2.10.6, "CA Certificate Extended Key Usage": id-kp-clientAuth is a MAY. If I was (say) Let's Encrypt I would (optionally?) allow it and dare Google/Chrome to remove my root certificate. Letting bullies get away with this kind of non-sense only encourages them. [1] https://cabforum.org/working-groups/server/baseline-requirements/documents/ https://cabforum.org/working-groups/server/baseline-requirem...
- nightpool 9mo ago
  Have you been reading the thread? https://news.ycombinator.com/item?id=46952590 https://news.ycombinator.com/item?id=46952590 there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)

kej 9mo ago

>when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-Web-PKI use cases Do you (or anyone else) have an example of this happening?

agwa 9mo ago
After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates. They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of. The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong. A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/RHBHXJOG8Io/m/5_H_NzZhAQAJ https://groups.google.com/g/mozilla.dev.security.policy/c/RH... [2] https://groups.google.com/g/mozilla.dev.security.policy/c/yhq6QNhEQok/m/9sdadL9kFwAJ https://groups.google.com/g/mozilla.dev.security.policy/c/yh... [3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM9tkZR9mLM/m/ACBIRX7GAAAJ https://groups.google.com/g/mozilla.dev.security.policy/c/LM...
- account42 9mo ago
  But this has nothing to do with clientAuth as in this case the payment processor uses a server certificate and terminal connect to the payment processor, not the other way around. So this change would not have prevented this and I don't see what browsers can do to prevent it - after all, the exact same situation would have happened if the payment processors used a HTTPS-based protocol.
  - sam_lowry_ 9mo ago
    I believe the explanation. The collateral damage is huge, but Google couldn't care less.
  - Ajedi32 9mo ago
    Yeah, the more I think about it the more futile this effort starts to look. The industry is investing tons of resources into building and maintaining an open, highly secure PKI ecosystem which allows any server on the public internet to cryptographically prove its identity, and Google wants to try to prevent anyone who's not a web browser from relying on that ecosystem? Seems impossible. The incentives are far too strong. Google is hoping that after this change other TLS clients will go off and build their own PKI entirely separate from the web PKI, but in reality that would take way too much redundant effort when the web PKI already does 99% of what they want. What will actually happen is clients that want to use web certs for client authentication will just start ignoring the value of the extendedKeyUsage extension. The OP says Prosody already does. I don't see how that's an improvement to the status quo.
    - sam_lowry_ 9mo ago
      European eIDs are knows to disallow encryption, only signature. If software like OpenSSL will starts to ignore intent... Good for us, the citizens.
    - vikkymelani 9mo ago
      [dead]

detourdog 9mo ago

I’m disappointed that a competitor doesn’t exist that uses longevity of IP routing as a reputation validator. I would think maintaining routing of DNS to a static IP is a better metric for reputation. Having unstable infrastructure to me is a flag for fly by night operations.

ocdtrekkie 9mo ago
Well, be prepared for certificates that change every 7 to 47 days, as the Internet formally moves to security being built entirely on sand.
- webstrand 9mo ago
  I wonder if this is a potential "off switch" for the internet. Just hit the root ca so they can't hand out the renewed certificates, you only have to push them over for a week or so.
  - gus_massa 9mo ago
    People will learn to press all the buttons with scarry messages to ignore the wrong certificates. It may be a problem for credit cards and online shopping.
    - ocdtrekkie 9mo ago
      HSTS was specifically designed to block you from having any ignore buttons. (And Firefox refuses to implement a way to bypass it.) But this is also why the current PKI mindset is insane. The warnings are never truly about a security problem, and users have correctly learned the warnings are useless. The CA/B is accomplishing absolutely nothing for security and absolutely everything for centralized control and platform instability.
      - blibble 9mo ago
        > The CA/B is accomplishing absolutely nothing for security and absolutely everything for centralized control and platform instability. is it their fault? with the structure of the browser market today: you do what Google or Apple tell you to, or you're finished as a CA the "forum" seems to be more of a puppet government

RobotToaster 9mo ago

Isn't LE used for half the web at this point? Calling Google's bluff and seeing if they would willingly cut their users off from half the web seems like an option here.

bawolff 9mo ago
That's not how this would work. Based on previous history where people actually did call google's bluff to their regret, what happens is that google trusts all current certificates and just stops trusting new certs as they are issued. Google has dragged PKI security into the 21st century kicking and screaming. Their reforms are the reason why PKI security is not a joke anymore. They are definitely not afraid to call CA companies bluff. They will win.
- xg15 9mo ago
  How is "client certificates forbidden" in any way an improvement?
  - Avamander 9mo ago
    Not forbidden, just not going to be a part of WebPKI. It's one of those things that has just piggybacked on top of WebPKI and things just piggybacking is a bad idea. There have been multiple cases in the past where this has caused a lot of pain for making meaningful improvements (some of those have been mentioned elsewhere in this thread).
    - xg15 9mo ago
      What exactly do you mean with "WebPKI"? The PKI system was designed independently of the web and the web used to be one usecase of it. You're kind of turning that around here.
      - Avamander 9mo ago
        The idea of a PKI was of course designed independently, there are many very large PKIs beyond WebPKI. However the one used by browsers is what we call WebPKI and that has its own CAs and rules. You're trying to make it sound like there has ever been some kind of an universal PKI that can be used for everything and without any issues.

xg15 9mo ago

This sounds a lot like the "increasing hostility for non-web usecases" line in the OP. In theory, Chrome's rule would split the CA system into a "for web browsers" half and a "for everything else" half - but in practice, there might not be a lot of resources to keep the latter half operational.

Ajedi32 9mo ago
In practice this might just mean that applications designed to use web PKI certs start ignoring the value of the extendedKeyUsage extension. OP says Prosody already does this.
- ameliaquining 9mo ago
  Well, if libraries like OpenSSL check extendedKeyUsage by default but provide an option to disable this, then most apps benefit from more stringent security, but ones like Prosody with unusual use cases can continue to make those use cases work. That doesn't sound like the worst thing in the world, necessarily? (I'm not sure how Prosody actually implemented this, though, or whether OpenSSL actually works that way.)

ge0rg 9mo ago

It is really great how they write "TLS use cases" and in fact mean HTTPS use cases. CA/Browser Forum has disallowed the issuance of server certificates that make use of the SRVName [0] subjectAltName type, which obviously was a server use case, and I guess the only reason why we still are allowed to use the Web PKI for SMTP is that both operate on the server hostname and it's not technically possible to limit the protocol. It would be perfectly fine to let CAs issue certificates for non-Web use-cases with a different set of requirements, without the hassle of maintaining and distributing multiple Roots, but CA/BF deliberately chose not to. [0] https://community.letsencrypt.org/t/srvname-and-xmppaddr-support/96026/3 https://community.letsencrypt.org/t/srvname-and-xmppaddr-sup...

notepad0x90 9mo ago

Why can't Let's Encrypt push-back on this for their users' sake? What is Google going to do? distrust LE certs?

agwa 9mo ago
Google Chrome (along with Mozilla, and eventually the other root stores) distrusted Symantec, despite being the largest CA at the time and frequently called "too big to fail".
- notepad0x90 9mo ago
  Given how ubiquitous LE is, I think people will switch browsers first. non-chrome browsers based on chrome are plenty as well, they can choose to trust LE despite Chrome's choices. Plus, they had a good reason with Symantec, a good reason to distrust them that is. This is just them flexing, there is no real reason to distrust LE, non-web-pki does not reduce security.
  - nightpool 9mo ago
    GP gave a very good reason that non-web-PKI reduces security, you just refused to accept it. Anybody who has read any CA forum threads over the past two years is familiar with how big of a policy hole mixed-use-certificates are when dealing with revocation timelines and misissuance.
    - account42 9mo ago
      There was no good reason given only a "trust me bro".
    - sam_lowry_ 9mo ago
      > non-web-PKI reduces security How exactly?
    - notepad0x90 9mo ago
      "it's complicated" is not the same as "it's insecure". Google feels like removing this complexity improves security for web-pki. Improving security is not the same as saying something is insecure. Raising security for web-pki is not the same as caliming non-web-pki usage is insecure or is degrading security expectations of web-pki users. It's just google railroading things because they can. You can improve security by also letting Google decide and control everything, they have the capability and manpower. But we don't want that either.

thayne 9mo ago

So that argues against including CAs that don't issue server authentication cerificates. That's somewhat reasonable, although it does put non-browser use cases in an awkward position, since there isn't currently a standard distribution channel for trusted CAs that is independent of browsers. But prohibiting certs from being marked for client usage is mostly unrelated to that goal because: 1. There are many non-web use cases for certificates that are only used for server authentication. And 2. There are use cases where it makes sense to use the same certificate used for web PKI as a client with mTLS to another server using web PKI, especially for federated communication.

account42 9mo ago

> Moving Forward, Together The title alone tells you that they are fully aware that they are fucking others over and don't care one bit. In a better world this kind of manipulative language would get you shamed and ostracized but somehow it's considered professional communication.

deleted 9mo ago
[deleted]

greatgib 9mo ago

Again, it is showing that Google is clearly having a too big monopoly and abusing it.

zarzavat 9mo ago

Sounds like a bunch of hot air. What is Google going to do, blacklist LE and break half of the web? I think LE could just ignore this.

philipwhiuk 9mo ago

> In some cases, this approach actively harms both subscribers and CA Owners. I do hate this vagueness. What cases? Identify at least one.

throw0101a 9mo ago

> Let's Encrypt could of course continue offering client certificates if they wanted to, but they'd need to set up a separate root for those certificates to chain up to, and they don't think there's enough demand for that to be worth it. Why an entire new root? Perhaps set up a ACME profile [1] where the requestor could ask for clientAuth if their use case would be helped; the default would be off. Google would be free to reject with-clientAuth HTTPS server certificates in their browser, but why should they care if a XMPP or SMTP server has a such a certificate if the browser never sees it? [1] https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/ https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/

Ajedi32 9mo ago
That's not allowed. > To qualify as a dedicated TLS server authentication PKI hierarchy under this policy: > All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an applicant root CA MUST: > [...] > when disclosed to the CCADB… > [...] > on or after June 15, 2025, include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth. > [...] > NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values. https://googlechrome.github.io/chromerootprogram/policy-archive/policy-version-1-7/#421-applicant-pki-hierarchies https://googlechrome.github.io/chromerootprogram/policy-arch...
- throw0101a 9mo ago
  > That's not allowed. According to Google. Why do they get to dictate this? Per the current (2.2.2) CAB requirements [1], §7.1.2.10.6, "CA Certificate Extended Key Usage": id-kp-clientAuth is a MAY. If I was (say) Let's Encrypt I would (optionally?) allow it and dare Google/Chrome to remove my root certificate. Letting bullies get away with this kind of non-sense only encourages them. [1] https://cabforum.org/working-groups/server/baseline-requirements/documents/ https://cabforum.org/working-groups/server/baseline-requirem...
nightpool 9mo ago
Have you been reading the thread? https://news.ycombinator.com/item?id=46952590 https://news.ycombinator.com/item?id=46952590 there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)