3 ms·

A public CA checks it one-time, when it's being issued. Most/all mTLS use-cases don't do any checking of the client cert in any capacity. Worse still, some API

by nickf 8mo ago

A public CA checks it one-time, when it's being issued. Most/all mTLS use-cases don't do any checking of the client cert in any capacity. Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to. If it's for auth, issue it yourself and don't rely on a third-party like a public CA.

xg15 8mo ago
> A public CA checks it one-time, when it's being issued. That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes". > Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to. Not an expert there, but isn't the point of EV that the CA verified the "real life entity" that requested the cert? So then it depends on what kind of access model the finance company was specifying for its API. "I don't care who is using my API as long as they are a company" is indeed a very stupid access model, but then I think the problem is deeper than just cert validation.
- bawolff 8mo ago
  > That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes". No it isn't, and that's not the reason why cert lifetimes are getting smaller. Cert lifetimes being smaller is to combat certs being stolen, not man in the middle attacks.
  - nickf 8mo ago
    Not really, no. There are a number of reasons for cert lifetimes being made shorter.
- account42 8mo ago
  > "I don't care who is using my API as long as they are a company" is indeed a very stupid access model, but then I think the problem is deeper than just cert validation It's not stupid if you reframe it as "you can only use my API if you give me a cryptographically verifiable trace to your legal identity".
  - xg15 8mo ago
    That's true if it worked, but I think there was the problem that EV names aren't always enough to trace back the legal entity? At least that's what I read, it might be wrong.
ge0rg 8mo ago
A federated ecosystem of servers that need to verify each other based on their domain name as the identity is the prime use-case for a public CA to issue domain-verified client certificates. XMPP happens to be this ecosystem. Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort, essentially redoing all the hard work of LetsEncrypt, but without the major funding, thus ending up with an insecure solution. We make use of the public CAs, that have been issuing TLS certificates based on domain validation, for quite a few years now, before the public TLS CAs have been subverted to become public HTTPS-only CAs by Google and the CA/Browser Forum.
- Avamander 8mo ago
  > Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort Rolling out a change that removes the EKU check would not be that much effort however.
  - xg15 8mo ago
    That's exactly what prosody is doing, but it's a weird solution. Essentially, they're just ignoring the missing EKU flag and pretend it would be there, violating the spec. It seems weird to first remove the flag and then tell everyone to update their servers to ignore the removal. Then why remove it in the first place?
    - Avamander 8mo ago
      I think you're confusing different actors here. The change was made by the CA/B Forum, the recommendation is just how it is if you want to use a certificate not for the purposes intended.
      - account42 8mo ago
        But it does mean that the CA/B requirement change has zero positive effect on security of anything and only causes pointless work and breakage. Or to put it another way, the pragmatic response of the XMPP community shows that the effect of the change is not to remove the clientAuth capability from any certs but to effectively add it to all serverAuth certs no matter what the certificate says.

by nickf 8mo ago

xg15 8mo ago

> A public CA checks it one-time, when it's being issued. That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes". > Worse still, some APIs (mainly for finance companies) require things like OV and EV, but of course they couldn't check the Subject DN if they wanted to. Not an expert there, but isn't the point of EV that the CA verified the "real life entity" that requested the cert? So then it depends on what kind of access model the finance company was specifying for its API. "I don't care who is using my API as long as they are a company" is indeed a very stupid access model, but then I think the problem is deeper than just cert validation.

bawolff 8mo ago
> That's the same problem we have with server certs, and the general solution seems to be "shorter cert lifetimes". No it isn't, and that's not the reason why cert lifetimes are getting smaller. Cert lifetimes being smaller is to combat certs being stolen, not man in the middle attacks.
- nickf 8mo ago
  Not really, no. There are a number of reasons for cert lifetimes being made shorter.
account42 8mo ago
> "I don't care who is using my API as long as they are a company" is indeed a very stupid access model, but then I think the problem is deeper than just cert validation It's not stupid if you reframe it as "you can only use my API if you give me a cryptographically verifiable trace to your legal identity".
- xg15 8mo ago
  That's true if it worked, but I think there was the problem that EV names aren't always enough to trace back the legal entity? At least that's what I read, it might be wrong.

ge0rg 8mo ago

A federated ecosystem of servers that need to verify each other based on their domain name as the identity is the prime use-case for a public CA to issue domain-verified client certificates. XMPP happens to be this ecosystem. Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort, essentially redoing all the hard work of LetsEncrypt, but without the major funding, thus ending up with an insecure solution. We make use of the public CAs, that have been issuing TLS certificates based on domain validation, for quite a few years now, before the public TLS CAs have been subverted to become public HTTPS-only CAs by Google and the CA/Browser Forum.

Avamander 8mo ago
> Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort Rolling out a change that removes the EKU check would not be that much effort however.
- xg15 8mo ago
  That's exactly what prosody is doing, but it's a weird solution. Essentially, they're just ignoring the missing EKU flag and pretend it would be there, violating the spec. It seems weird to first remove the flag and then tell everyone to update their servers to ignore the removal. Then why remove it in the first place?
  - Avamander 8mo ago
    I think you're confusing different actors here. The change was made by the CA/B Forum, the recommendation is just how it is if you want to use a certificate not for the purposes intended.
    - account42 8mo ago
      But it does mean that the CA/B requirement change has zero positive effect on security of anything and only causes pointless work and breakage. Or to put it another way, the pragmatic response of the XMPP community shows that the effect of the change is not to remove the clientAuth capability from any certs but to effectively add it to all serverAuth certs no matter what the certificate says.