[lamps] Re: [EXT] Re: [TLS] TLS Client Certificates; a survey

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

I agree with Viktor, and confirm that we use serverAuth and clientAuth with non-web non-browser apps. 

—

Regards,

Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On Mar 23, 2026, at 23:39, Phillip Hallam-Baker <[e-mail]> wrote:



What application domain are you considering using the client certs for? I have been trying to work out ways to make client certs work in an open PKI and have come to the conclusion that PKIX is just not the tool for the job. PKIX is a really

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

What application domain are you considering using the client certs for?

I have been trying to work out ways to make client certs work in an open PKI and have come to the conclusion that PKIX is just not the tool for the job. PKIX is a really good tool for deploying client certificates within an organization, that is what it is designed for, LRAs, hierarchies, that is what all that mechanism is for. Issuing certs for federal govt. workers, no problem.

The cadences of PKIX just don't work for the problem space. Most times I would spend more time updating my cert once a year than I did making use of encrypted or signed emails.

But I just could not get to a way to make it work for general Internet users and I really don't think Web o' Trust does either. Which is why I spent a decade working on the Mesh. The original plan being to give everyone a personal PKI.

And then I started looking at DNS handles and their use in BlueSky and I have a much simpler solution that I think addresses a lot of very interesting use cases and a part of it is already in CALEX.

So the starting point is, I want to put all my cryptographic contact information into my JSContact (VCard in JSON). So not just one public key, all the keys you would need to talk to me via any protocol whatsoever. OpenPGP, S/MIME, Signal, Git, Code Signing, everything that needs a key.

Next thing is to have a secure means of authenticating updates. So that once we exchange contact information, we can communicate securely via any application protocol I support at the time, including protocols not yet invented. This is a bit I need a bit of lobbying support on. The idea is simply wrap the JSContact in a simple binary envelope and sign it using JOSE.

Final thing is to provide mechanisms for exchanging contacts. And this is where I have a second very small bit of mechanism, a URI form that has a single key that is used to locate, decrypt and authenticate the content. This URI is essentially a bearer token for the signed JSContact blob and it can be exchanged in many different ways:

* Add it to every email as an SMTP header.

* Put a DNS handle on a business card (@http://phill.hallambaker.com" rel="nofollow">phill.hallambaker.com links to a TXT record _contact.http://phill.hallambaker.com" rel="nofollow">phill.hallambaker.com with the URI

* Encode it in a QR code and exchange the contact in person. In this case we mark the contact entry in the user's address book as directly verified.

Now none of that gets to the sort of Trusted Third Party credential validation that a CA provides, but a TTP could easily offer that service for signed JSContacts as the need arose. So certified JSContacts for doctors, or engineers or whatever, sure, can do that. But that is the special case, the rarity, not the one to require everyone to start with.

We can reinforce the trust infrastructure in various ways like Merkle tree authenticated logs and such, cross notarization and all the fancy stuff I built. But you get 90% of the value without any of that.

I have drafts and I have running code. I am just putting another project to bed right now and will be back on this next month.

Anyone interested in working on this with me?

On Mon, Mar 23, 2026 at 10:36 AM Salz, Rich <rsalz=[e-mail]> wrote:

Since WebPKI CA’s will not be able to issue TLS-Client certificates, what are the customers and CAs thinking of doing?

Replies to be will be summarized to both lists. Please be careful if you use reply-all.

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
Spasm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]