[lamps] Re: TLS Client Certificates; a survey

[Alan DeKok <[e-mail]>]

On Mar 24, 2026, at 6:32 AM, Viktor Dukhovni <[e-mail]> wrote:
> The workaround is much simpler, the server operator opts in to enable
> the workaround, and then serverAuth-only certs presented by a client are
> validated as server certificates (in terms of EKU requirements), even
> though the peer's actual rôle is "client".

  i.e. All information about certificate authenticity and validity for multiple different use-cases has been narrowed down to a 1-bit signal: "good / bad".

  This seems wrong,  I had a long discussion a while ago (which I won't link here) about the reasons for this.

  The summary is that the modern CA framework is largely limited to the web / browser use-case.  When I pointed out that many sites used web certs with id-kp-serverAuth for non-web uses, the response was divided into two.  One was a practical acknowledgement of "Yes, that's what everyone does".  The other was to express shock and outrage at these mis-uses, along with the intention to revoke any certificate that was caught being used in a non-web context.

  All while the CAs were using web certs for non-web uses.

  We should admit that the CA infrastructure has failed us for nearly all use-cases.  Either the CA infrastructure is the web, and (despite the CA/B forum rules) it's OK to use web certs in non-web contexts.  Or, the CA infrastructure is more than the web, and we need to have new,, non-web CAs with rules outside of the CA/B forum.

  Either choice poses problems.  But if we don't admit that those are the choices we're making, we will continue to stumble around trying to patch a broken system, without ever talking about the root cause.

  My $0.02 is that there is a substantial need for a more robust CA framework.  That the certificates need to encode more than 1 bit of information about permitted use-cases.  Michael Richardson and I have a very high level draft of a problem statement and set of requirements.  But there isn't much interest in moving ahead if there's wide-spread opposition to the idea of fixing the CA infrastructure.

  Alan DeKok.