Because it's easier for the client to decide what the client understands than it is for the server to decide what the client understands. Less complexity = less failures.
Note that this is how XP was handled for code signing. The Authenticode spec actually made it so if you did things in the right order, XP would only see the SHA-1 signature, while more recent operating systems would see both the SHA-1 and SHA-2 signatures, ignore the SHA-1 signature, and use the SHA-2 signature. This allowed doubly-signed binaries that worked both on XP and non-XP systems. Unfortunately the technical steps to do so weren't widely publicized, but I know some companies took advantage of it. However, servers are easier to upgrade than clients, which is why you see some of the server side support you mention. I know CloudFlare in particular helped a lot of people cope with communicating with clients who had different certificate capabilities. It isn't a bad thing that both approaches exist. -Tim > -----Original Message----- > From: Andrei Popov [mailto:andrei.po...@microsoft.com] > Sent: Friday, December 15, 2017 12:25 PM > To: Tim Hollebeek <tim.holleb...@digicert.com>; Ilari Liusvaara > <ilariliusva...@welho.com> > Cc: tls@ietf.org > Subject: RE: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in > general, and what we can do in TLS > > > Ideally, you'd want certificates to be able to have two signatures > > during the transition period, in order to support clients who have > > transitioned and those who have not. > > > Hosting multiple certificates and switching based on the client is > > feasible, but requires some technical wizardry and isn't possible in all > situations. > > For my understanding, why is the former (double-signed certs, where either > signature is trusted) better than the latter (multiple certs with different > algorithms)? > The latter is currently supported by some TLS servers. > > Cheers, > > Andrei
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
