Timeline for Why client certificate at TLS handshake at all?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 20, 2018 at 3:16 | comment | added | Tankman六四 | There is no authority to sign it in the case of the blockchain. If you own a token from a smart-contract, the only thing to prove it is a Merkle path to the event, since the smart contract, with gives the "certificate", doesn't have its own private key. It's not a person and it has no secrets. | |
| Jun 20, 2018 at 3:11 | vote | accept | Tankman六四 | ||
| Jun 19, 2018 at 15:20 | comment | added | Steve Sether | It sounds like you're modifying the TLS protocol in some way to suit your own needs. Like others, I'm confused why you're bringing up blockchain technology here, so that leads me to believe you've gone outside of the normal TLS protocol. That's normally a bad idea. | |
| Jun 19, 2018 at 15:13 | answer | added | gowenfawr | timeline score: 4 | |
| Jun 19, 2018 at 9:43 | comment | added | CipherX | I'm not understanding why you are talking about Blockchain. Basically, you can use blockchain to define a set of authorities that releases X.509 certificates to their clients, and after that these clients could use these certificates to perform authentication, negotiate a key with other clients and so on. But use these certificates in TLS, it doesn't have a sense. | |
| Jun 19, 2018 at 8:26 | comment | added | Steffen Ullrich | I don't think you understand how TLS handshake works. By default the client does not authenticate itself (i.e. anonymous) and there is no need to use a random private key to achieve this. | |
| Jun 19, 2018 at 7:53 | history | edited | Tankman六四 | CC BY-SA 4.0 | added 41 characters in body |
| Jun 19, 2018 at 7:47 | history | edited | Tankman六四 | CC BY-SA 4.0 | edited body |
| Jun 19, 2018 at 7:47 | comment | added | forest | A blockchain public key for TLS? Huh? | |
| Jun 19, 2018 at 7:46 | history | asked | Tankman六四 | CC BY-SA 4.0 |