3 ms·

Shame LE didn't give people option to generate client and client+server auth certs

by PunchyHamster 9mo ago

forty 9mo ago
Yes, but then the lack of pragmatism shown by the XMPP community is a bit disconcerting
- superkuh 9mo ago
  It is not pragmatic to design your protocol for web use cases when it's not the web.
  - bawolff 9mo ago
    Unless im missing something, this is a poor design full stop. How are they validating SAN on these client certificates?
    - agwa 9mo ago
      XMPP identifiers have domain names, so the XMPP server can check that the DNS SAN matches the domain name of the identifiers in incoming XMPP messages. I've seen non-XMPP systems where you configure the DNS name to require in the client certificate. It's possible to do this securely, but I agree entirely with your other comment that using a public PKI with client certs is a recipe for disaster because it's so easy and common to screw up.
  - account42 9mo ago
    On the contrary, setting up a separate PKI for XMPP would be what is not pragmatic or even feasible at all. The pragmatic choice is to make use of the options available even if some people find them icky.
- SahAssar 9mo ago
  What is the lack of pragmatism you are talking about?
  - forty 9mo ago
    The refusal to accept server only certificate as client certificate for server
    - kokx 9mo ago
      The article literally talks about how one of the server implementations does exactly that: > Does this affect Prosody? > Not directly. Let’s Encrypt is not the first CA to issue server-only certificates. Many years ago, we incorporated changes into Prosody which allow server-only certificates to be used for server-to-server connections, regardless of which server started the connection. [...]
    - MattJ100 9mo ago
      There might be some confusion here, as there is no refusal at all. As stated in the blog post, we (Prosody) have been accepting (only) serverAuth certificates for a long time. However this is technically in violation of the relevant RFCs, and not the default behaviour of TLS libraries, so it's far from natural for software to be implementing this. There was only one implementation discovered so far which was not accepting certificates unless they included the clientAuth purpose, and that was already updated 6+ months ago. This blog post is intended to alert our users, and the broader XMPP community, about the issue that many were unaware of, and particularly to nudge server operators to upgrade their software if necessary, to avoid any federation issues on the network.
      - forty 9mo ago
        Sorry, I probably misunderstood, I thought there were resistance to update the corresponding specs. I understand that non XMPP specs might refuse to be updated, but at least this behavior could be standardized for XMPP specifically.

Shame LE didn't give people option to generate client and client+server auth certs

forty 9mo ago

Yes, but then the lack of pragmatism shown by the XMPP community is a bit disconcerting

superkuh 9mo ago
It is not pragmatic to design your protocol for web use cases when it's not the web.
- bawolff 9mo ago
  Unless im missing something, this is a poor design full stop. How are they validating SAN on these client certificates?
  - agwa 9mo ago
    XMPP identifiers have domain names, so the XMPP server can check that the DNS SAN matches the domain name of the identifiers in incoming XMPP messages. I've seen non-XMPP systems where you configure the DNS name to require in the client certificate. It's possible to do this securely, but I agree entirely with your other comment that using a public PKI with client certs is a recipe for disaster because it's so easy and common to screw up.
- account42 9mo ago
  On the contrary, setting up a separate PKI for XMPP would be what is not pragmatic or even feasible at all. The pragmatic choice is to make use of the options available even if some people find them icky.
SahAssar 9mo ago
What is the lack of pragmatism you are talking about?
- forty 9mo ago
  The refusal to accept server only certificate as client certificate for server
  - kokx 9mo ago
    The article literally talks about how one of the server implementations does exactly that: > Does this affect Prosody? > Not directly. Let’s Encrypt is not the first CA to issue server-only certificates. Many years ago, we incorporated changes into Prosody which allow server-only certificates to be used for server-to-server connections, regardless of which server started the connection. [...]
  - MattJ100 9mo ago
    There might be some confusion here, as there is no refusal at all. As stated in the blog post, we (Prosody) have been accepting (only) serverAuth certificates for a long time. However this is technically in violation of the relevant RFCs, and not the default behaviour of TLS libraries, so it's far from natural for software to be implementing this. There was only one implementation discovered so far which was not accepting certificates unless they included the clientAuth purpose, and that was already updated 6+ months ago. This blog post is intended to alert our users, and the broader XMPP community, about the issue that many were unaware of, and particularly to nudge server operators to upgrade their software if necessary, to avoid any federation issues on the network.
    - forty 9mo ago
      Sorry, I probably misunderstood, I thought there were resistance to update the corresponding specs. I understand that non XMPP specs might refuse to be updated, but at least this behavior could be standardized for XMPP specifically.