[Yes, I am aware of the FIDO work and it is a completely different use case, does not apply to non web applications. TLS Client Auth is an IETF spec and thus within IETF scope.]
I have an infrastructure that makes private key management really simple for end users. They can manage private keys across devices without being aware they are doing it. This technology has obvious applications for existing public key authentication schemes including EAP, FIDO and TLS Client Auth. When looking at TLS client auth it seems to me that it is much closer to being a viable replacement for some uses of passwords than experience leads us to believe. In particular, I have maybe 5 accounts I might use a hardware token to secure but I have several hundred Web accounts that all use the same password because when it's not my asset and I am not being paid, I don't use my brain power to remember the password. So my basic idea here is that Alice connects all her devices to her personal Mesh and they are automatically provisioned with a device specific cert that is chained up to one of Alice's personal PKIX CAs. The CA in turn being (optionally) credentialed under Alice's personal Mesh via an extension if the goal is to establish that the 'Alice' visiting site A is the same as the Alice visiting site B. For cases where we want to prevent linkage, we develop a separate CA per site. This is not how PKIX is intended to work of course. But the deployed infrastructure supports PKIX and so that is the framework we have to work within. Looking at how TLS Client Auth works as deployed, a server sends a message back to a client saying 'client certificate required' and a list of distinguished names of CAs it will accept. So what I want to know is not 'should I do this', but 'what is the string I should send when I do'. That is, this is something I am planning to do and so I am asking what approach is least likely to have unintended effects. I see a need for two distinguished names: A) 'Self signed CA speaking to any relying party' B) 'Self signed CA speaking to a specific relying party' The server is going to check the certificate chain itself on the other end of course. And again, yes, I do fully understand the limitations of transport layer client auth. That is why I make use of my own authentication layer for Web Service transactions.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
