4 ms·

It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com. Now I get some random incomin

by xg15 9mo ago

It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com. Now I get some random incoming connection. How would I verify that this connection indeed originates from xmpp.bar.com? LE-assigned client certs sound like a good solution to that problem.

Avamander 9mo ago
Which is almost exactly why WebPKI doesn't want to support such use-cases. Just this EKU change alone demonstrates how it can hinder WebPKI changes.
- xg15 9mo ago
  Huh? The entire purpose of that EKU change was to disallow that usecase. How did that demonstrate problems for WebPKI?
  - Avamander 9mo ago
    This post here is the demonstration, that some non-WebPKI purpose is causing issues and complaints. This has happened before with SHA-1 deprecation. WebPKI does not want this burden and should not have this burden.
    - xg15 9mo ago
      Ok, so this is an official split of "WebPKI" and "everything else PKI" then? Last time I checked, Let's Encrypt was saying they provide free TLS certs, not free WebPKI certs. When did that change?
      - Avamander 9mo ago
        That's being overly pedantic. PKIs for different purposes have been separate for a while, if not from the start. LE is still giving you a "TLS cert".
      - bawolff 9mo ago
        You are being pedantic but also pedantically incorrect. Lets encrypt provides value by providing signed TLS certs that are enrolled in webPKI (i.e. trusted by browsers). If they were just provided a (not necessarily trusted) tls cert, like what anyone can generate from the command line, nobody would use them.
        ge0rg 9mo ago
        Let's Encrypt also provides value by providing signed TLS certificates that are enrolled in all major operating systems, and that can be used to authenticate any TLS server. This is a significant and important use case that's totally ignored by the "WebPKI" proponents, and there is no alternative infrastructure that would provide that value if WebPKI would e.g. decide to add certificate constraints limiting issued certificates to TCP/433.
- ge0rg 9mo ago
  Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?
  - Avamander 9mo ago
    Can you point out at which point in time exactly it was designed to serve every use-case?
    - ge0rg 9mo ago
      The public TLS PKI was never supposed to serve every use case and you know it. But let me point out when it was possible to get a public CA certificate for an XMPP server with SRVname and xmppAddr: Certificate: Data: Version: 3 (0x2) Serial Number: 1096750 (0x10bc2e) Signature Algorithm: sha256WithRSAEncryption Issuer: C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA Validity Not Before: May 27 16:16:59 2015 GMT Not After : May 28 12:34:54 2016 GMT Subject: C = DE, CN = chat.yax.im, emailAddress = hostmaster@yax.im X509v3 extensions: X509v3 Subject Alternative Name: DNS:chat.yax.im, DNS:yax.im, xmppAddr:chat.yax.im, dnsSRV:chat.yax.im, xmppAddr:yax.im, dnsSRV:yax.im Ironically, this was the last server certificate I obtained pre-LetsEncrypt.
      - Avamander 9mo ago
        So you understand that there are different purposes as well. Are you saying that you can't get a client auth certificate any more?
- account42 9mo ago
  Great circular reasoning there buddy.
bawolff 9mo ago
> It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com. If you already trust xmpp.foo.com, then you probably shouldn't be using PKI, as PKI is a complex system to solve the problem where you don't have preexisting trust. (I suppose maybe PKI could be used to help with rolling over certs)
- xg15 9mo ago
  No, the problem it was solving was "how do I verify that an incoming connection is actually from xmpp.foo.com and not from an impostor?" You could also solve this with API keys or plain old authentication, but all of those require effort on xmpp.foo.com's side to specifically support your server. Client certs seem better suited in that regard. A server can generate a trusted client cert once, and then everyone else can verify connections from that server without having to do any prior arrangements with it.

by xg15 9mo ago

Avamander 9mo ago

Which is almost exactly why WebPKI doesn't want to support such use-cases. Just this EKU change alone demonstrates how it can hinder WebPKI changes.

xg15 9mo ago
Huh? The entire purpose of that EKU change was to disallow that usecase. How did that demonstrate problems for WebPKI?
- Avamander 9mo ago
  This post here is the demonstration, that some non-WebPKI purpose is causing issues and complaints. This has happened before with SHA-1 deprecation. WebPKI does not want this burden and should not have this burden.
  - xg15 9mo ago
    Ok, so this is an official split of "WebPKI" and "everything else PKI" then? Last time I checked, Let's Encrypt was saying they provide free TLS certs, not free WebPKI certs. When did that change?
    - Avamander 9mo ago
      That's being overly pedantic. PKIs for different purposes have been separate for a while, if not from the start. LE is still giving you a "TLS cert".
    - bawolff 9mo ago
      You are being pedantic but also pedantically incorrect. Lets encrypt provides value by providing signed TLS certs that are enrolled in webPKI (i.e. trusted by browsers). If they were just provided a (not necessarily trusted) tls cert, like what anyone can generate from the command line, nobody would use them.
      - ge0rg 9mo ago
        Let's Encrypt also provides value by providing signed TLS certificates that are enrolled in all major operating systems, and that can be used to authenticate any TLS server. This is a significant and important use case that's totally ignored by the "WebPKI" proponents, and there is no alternative infrastructure that would provide that value if WebPKI would e.g. decide to add certificate constraints limiting issued certificates to TCP/433.
ge0rg 9mo ago
Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?
- Avamander 9mo ago
  Can you point out at which point in time exactly it was designed to serve every use-case?
  - ge0rg 9mo ago
    The public TLS PKI was never supposed to serve every use case and you know it. But let me point out when it was possible to get a public CA certificate for an XMPP server with SRVname and xmppAddr: Certificate: Data: Version: 3 (0x2) Serial Number: 1096750 (0x10bc2e) Signature Algorithm: sha256WithRSAEncryption Issuer: C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA Validity Not Before: May 27 16:16:59 2015 GMT Not After : May 28 12:34:54 2016 GMT Subject: C = DE, CN = chat.yax.im, emailAddress = hostmaster@yax.im X509v3 extensions: X509v3 Subject Alternative Name: DNS:chat.yax.im, DNS:yax.im, xmppAddr:chat.yax.im, dnsSRV:chat.yax.im, xmppAddr:yax.im, dnsSRV:yax.im Ironically, this was the last server certificate I obtained pre-LetsEncrypt.
    - Avamander 9mo ago
      So you understand that there are different purposes as well. Are you saying that you can't get a client auth certificate any more?
account42 9mo ago
Great circular reasoning there buddy.

bawolff 9mo ago

> It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com. If you already trust xmpp.foo.com, then you probably shouldn't be using PKI, as PKI is a complex system to solve the problem where you don't have preexisting trust. (I suppose maybe PKI could be used to help with rolling over certs)

xg15 9mo ago
No, the problem it was solving was "how do I verify that an incoming connection is actually from xmpp.foo.com and not from an impostor?" You could also solve this with API keys or plain old authentication, but all of those require effort on xmpp.foo.com's side to specifically support your server. Client certs seem better suited in that regard. A server can generate a trusted client cert once, and then everyone else can verify connections from that server without having to do any prior arrangements with it.