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

[David Adrian <[e-mail]>]

> I would have rather more sympathy for the position of the browser
providers in 2018 if they had not been so intractably opposed to adding
support for SHA-2 back when I was pushing for that in 2002.

I'll be sure to let my 4th grade self know that the Chrome Root Program
made a bad decision in 2002, six years before Chrome was released.

On Tue, Mar 31, 2026 at 11:17 PM Phillip Hallam-Baker <[e-mail]>
wrote:

> On Tue, Mar 31, 2026 at 8:00 PM David Adrian <[e-mail]> wrote:
>
>
>> History has taught us that commingling PKI use cases causes more harm
>> than good. It is a consistent security problem when PKI hierarchies
>> intended for public web sites get entangled in non-web use cases. As an
>> example, such behavior slowed the deprecation of SHA-1 in 2018 because
>> payment card terminal implementations and their corresponding root stores
>> could not be updated.
>>
>
> The original concept of X.509v3/PKIX was that there were two types of
> certificate, certificate signing certificates and end entity certificates.
> While there are certainly very good arguments for cryptographic hygiene and
> use of separate private keys for separate applications, that only leads us
> to separation of concerns between end-entity certificates.
>
> I would have rather more sympathy for the position of the browser
> providers in 2018 if they had not been so intractably opposed to adding
> support for SHA-2 back when I was pushing for that in 2002. The transition
> from MD5 to SHA-1 had only been possible because the browsers already
> supported SHA-1 and it was clear that we would be in a mess if SHA-1 failed
> long before the 2005 RSA announcement which rather than spurring deployment
> of SHA-2 caused many to decide that we should instead wait for SHA-3.
>
> The problem we faced as CAs was that nobody would be able to make use of
> SHA-2 certificates until they were widely supported in the browsers so it
> really didn't make sense for the browser providers to block on CA support.
>
> In the event, a certain browser provider flipped from being non commital
> in their plans to add support to insisting the problem was so severe we had
> to do transition immediately. So no, I don't draw the same conclusions.
>
>
> As to applying the 'commingling' argument to roots, I am rather surprised
> because root certificates aren't really certificates at all in PKIX terms.
> While they are presented as self signed certificates, that is really just a
> syntactic convenience that avoided having to define a new structure. The
> signature on a root certificate doesn't have meaning after it has been
> installed in a root store so whether it is SHA-1, SHA-2 or MD4 makes little
> real difference.
>
> No, I cannot see a good argument for Web client and Web server
> certificates being separate applications not to be commingled.
>
>
>
>