One major suggestion (based on past experience with Chrome doing it
wrong): Do not apply SHA-1 rejection to any of the following:
1. The self-signature on the root cert in a chain.
2. Cross-signatures/certs on a subject/public key combination which is
also present as a trusted root in its own right (example: GlobalSign
has long ago issued a cross-certificate where their old SHA-1 root cert
SHA-1 signed their new SHA-2 root).
3. Any situation where the server / e-mail signer / code signer
provides enough certs to form multiple trust chains and at least one
trusted chain can be formed by ignoring all the non-root SHA-1 certs
(this actually encompass cases 1 and 2 as special cases).
4. For file formats that can be signed with multiple certificates,
accept the good signature and ignore any SHA-1 signatures that might be
included for backward compatibility. This includes: Anything with a
PKCS#7/CMS signature (supports a "SET of SignerInfo"), Anything with
JAR style signatures (including .xpi files, the JAR signature format
spec allows an almost unlimited number of signature files in the .zip,
each of which is a PKCS#7/CMS signature itself), anything with
Microsoft Authenticode signatures (these are PKCS#7 but also allow
additional signatures in a special unauthenticated signature attribute).
By not rejecting these cases, servers/signers can provide alternative
signature chains that are trusted by older clients. For instance this
could be a good thing to to for the "download Firefox" page, since
people are likely to visit that using a woefully outdated browser.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.
https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct
+45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded