Re: [TLS] Better TLS Client Authentication

Hi Phillip,
I'm not able to figure out the merits of your proposal, but I see one major obstacle: Google have a de-facto monopoly (80%) on browser technology and your proposal seems to require a rather substantial upgrade.

That is, unless Google buys into whatever you propose, it simply put gets nowhere.

As an example Google recently launched a payment authorization system which in spite of using state-of-the-art technology like FIDO, still requires you to handover card numbers in CLEAR to merchants (who do not need card numbers, but receipts from the payment network that they are/will be paid).

I early proposed that Google should consider using encryption and a "wallet" to keep virtual cards in (for getting away from physical cards altogether), like Apple Pay, but they did not even respond to this request.

Anders
https://github.com/mozilla/standards-positions/issues/570#issuecomment-972578433

On 2022-05-22 23:28, Phillip Hallam-Baker wrote:
> I am looking for people interested in discussing the following proposal to create a profile of TLS Client Authentication certificates to enable transparent Web Site authentication in Philadelphia:
> 
> I have a three step plan for eliminating Password Authentication
> 
> 1) Deploy an open standards based, E2E secure password vault
> 2) Transition Web sites to use of public key authentication
> 3) Deploy a 2FA type scheme to address 'ceremony' use cases
> 
> I don't want to get into detail here, but I believe the trick to eliminating passwords is to deploy a password management solution in phase 1 that creates a sufficiently large base of users whose devices are provisioned with the necessary private keys to make use of public key auth practical.
> 
> So, I had assumed that this was all about enabling FIDO. But when I look at what I want to achieve and what legacy deployments provide, I suddenly realized I can do everything I need using TLS client auth. The only question is what the BEST way to do it is going to be.
> 
> 
> So I have running code that can provision key pairs and credentials to every device Alice owns:
> 
> https://www.youtube.com/watch?v=zrBv717w8yY <https://www.youtube.com/watch?v=zrBv717w8yY>
> 
> It would not take a great deal of extra effort to provision certificates into the Windows/MAC/etc keystores so that IE, Edge, Firefox, Chrome, Safari, etc. etc. can all make use of the certificates. Its just a question of writing a script.
> 
> 
> I am pretty sure I can get 'something' to work. But I would appreciate some help from folk who are closer to the real-world implementations.
> 
> Reading through the specs, I think we can make it so that after an (optional) one time registration, Alice can just use the Web site without the need to ever log in ever again.
> 
> The only reason Alice would ever need to repeat registration is if the Web Site had some policy requiring Alice to affirm that yes, this really is her device and she agrees to terms. That is what I call 'ceremony' and it is not an authentication issue. I have another way of addressing that issue.
> 
> 
> As far as I can tell, all that I really need is to write a certificate profile for BTCA certificates.
> 
> The thing that I am dropping here is the notion that certificates are bound to anything other than a key. So all this is telling the site is that this is the same person who came to the site before. It is not providing the user credential PKIX is really all about.
> 
> I do have some questions though. In particular whether using X.448/Ed448 certs is practical.
> 
> The big downside to my current approach is that the certs that are used are going to be super-linking identifiers. But we are currently losing that fight.
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls