Well, let's imagine that server
S provides a service to a given set of clients
C2 with secured cert-based authentication (think of
SSH or other similar services).
Scould use a trusted CA or create its own to let
C2know that he is the real
HTTPS, etc. do). This requires the CA cert to be pre-shared with each client.
Scould just present its certificate to
C2the first time the clients connect to it and the client would check whether this certificate is the one expected (what
Syncthing, etc. do).
The thing is:
- Some systems (*cough* android... *cough*) just add the custom CA directly into the global trust store (
p12format is pretty convenient, whereas
pemis dreadful for the user, yet we often don't have the choice (why are there 4 files? what's the key you were talking about? what's the private cert? why
ca.certdoes not work as my private cert?...).
- The users don't like/are not allowed to validate/type stuff on both server and clients to authenticate each other (
- Yet they can't be bothered to check a certificate hash thoroughly (
A (possibly dreadful) way to solve these problems (and create others) would be to directly use
S private key to sign
- No new CA to add to the system-wide trust store.
- Only one file to handle in both
- The user doesn't have to access
- The user doesn't have to check anything as long as he can trust the signed certificate given to him (through
SSH, etc.). NB: this trust problem is the same when you have to get the CA cert on each client.
The thing is that I have not heard of such a scheme before. I thinks it is mostly because it does not provide strong improvements over the CA-based scheme, but it could be because the approach is flawed.
So, are there bad security implications arising from using this kind of scheme?
PS: I am asking out of curiosity because I don't know any protocol using this scheme, yet it seems a bit simpler.