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

[Phillip Hallam-Baker <[e-mail]>]

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 (@phill.hallambaker.com links to a
TXT record _contact.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]
>