Re: [TLS] [EXTERNAL] [lamps] Distinguished names for self certified TLS client authj

[Mike Ounsworth <[e-mail]>]

Hi Phillip,

What clients are you trying to use this with? Browsers? This almost feels like a user-agent question: "What CA DN do you want the server to prompt for so that you put up the right certs in the popup?". Is there a CA DN that you can specify that will cause FF / Chrome to show the user all their loaded certs?

Note: back in 2018 I was fiddling around with this for a stackexchange question and found that (by default) Firefox politely waits for you to select a client cert from the popup, whereas Chrome just starts spamming client certs at the server until it accepts one. I feel like user-agent behaviour is going to affect the viability of your idea here.

https://security.stackexchange.com/a/199518/61443

---
Mike Ounsworth
Software Security Architect, Entrust

From: Spasm <[e-mail]> On Behalf Of Phillip Hallam-Baker
Sent: June 14, 2022 2:58 PM
To: SPASM <[e-mail]>; [e-mail]
Subject: [EXTERNAL] [lamps] Distinguished names for self certified TLS client authj

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________________
[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.

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.