8 ms·

Which server is running plain HTTP? What credentials are transmitted over plaintext? I'd suggest reading up a bit more about X.509 CSRs and Certificates before

Which server is running plain HTTP? What credentials are transmitted over plaintext? I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear. I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though.

Grimeton 2y ago
I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear. Nobody suggested that. But I said that it is said in the article that the UUID needs to be sent to the server to get the request signed and that the UUID is the only identifier while the server itself runs on HTTP, which is also said in the article. Now go and put 1&1 together. Btw, I read the RFCs, that's why I don't see the point in this setup. I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though. There is no misguided feedback here. You want to go back to the drawing board and read up about x.509 and think stuff through. All you do is overcomplicating things by using x.509 instead of the UUID directly being blinded by the idea of some kind of security.
- pcpuser 2y ago
  The UUID is "sent" to the server in the signed certificate. Not in the clear or over an app protocol like HTTP. There's no way to fake this UUID.
  - Grimeton 2y ago
    I'm talking about sending the CSR to the server that runs on http. Bifrost CA server is a plain HTTP server that responds to X.509 Certificate Signing Requests (CSRs) sent via POST requests. The server validates CSRs, signs them, and returns signed certificates to clients. *PLAIN* http server. and also mentioning how operators can secure access to the server. Also it says: Bifrost recognises clients by their ECDSA P-256 key pairs. A client’s UUID is the hash of the public key and the namespace. The namespace is any UUID that identifies a domain or application. When you send a CSR, the CSR contains the public key. You __REALLY__ need to read up on x.509.

Grimeton 2y ago

I'd suggest reading up a bit more about X.509 CSRs and Certificates before assuming that private credentials are being transmitted in the clear. Nobody suggested that. But I said that it is said in the article that the UUID needs to be sent to the server to get the request signed and that the UUID is the only identifier while the server itself runs on HTTP, which is also said in the article. Now go and put 1&1 together. Btw, I read the RFCs, that's why I don't see the point in this setup. I appreciate the somewhat misguided feedback because you did point out that the rationale isn't clear enough. The rest of it is questionable though. There is no misguided feedback here. You want to go back to the drawing board and read up about x.509 and think stuff through. All you do is overcomplicating things by using x.509 instead of the UUID directly being blinded by the idea of some kind of security.

pcpuser 2y ago
The UUID is "sent" to the server in the signed certificate. Not in the clear or over an app protocol like HTTP. There's no way to fake this UUID.
- Grimeton 2y ago
  I'm talking about sending the CSR to the server that runs on http. Bifrost CA server is a plain HTTP server that responds to X.509 Certificate Signing Requests (CSRs) sent via POST requests. The server validates CSRs, signs them, and returns signed certificates to clients. *PLAIN* http server. and also mentioning how operators can secure access to the server. Also it says: Bifrost recognises clients by their ECDSA P-256 key pairs. A client’s UUID is the hash of the public key and the namespace. The namespace is any UUID that identifies a domain or application. When you send a CSR, the CSR contains the public key. You __REALLY__ need to read up on x.509.