> 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 <[email protected]> wrote: > On Tue, Mar 31, 2026 at 8:00 PM David Adrian <[email protected]> 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. > > > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
