[cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

Sigbjørn Vik sigbjorn at opera.com
Tue Oct 20 07:01:37 MST 2015

There is an additional threat, which while hard to quantify, seems at
least as significant. We operate in the trust business, and rely on
trust from users, companies and legislative bodies in order to operate.
Allowing insecure practices risks undermining that trust, so we wisely
decided to phase out SHA-1 a long time ago. If we were to extend
insecure practices, while faced with ample evidence of their weaknesses,
it would ensure the CAB Forum will be less trusted in the future. The
effect of this is subtle but real, it may be fragmentation of the market
(new trust systems appearing, local legislations), more costly
deployment of secure solutions (as relying on certificates might not be
sufficient), user confusion, and an even harder time to deprecate
insecure practices in the future. The entire ecosystem would suffer from
this. CAB Forum needs to build trust and enable secure communications,
not tear it down.

CAs are not prohibited from issuing other types of certificates. But for
roots under the BRs, all certificates may be used as browser
certificates. Certificates may be used for other purposes than those
intended by the CA, and weak certificates may be broken and used for
other purposes than technically allowed by the original certificate.
Roots that want a strong assurance, thus need to follow strict rules.
CAs are free to use other roots for other purposes. A CA could pull one
of its existing roots out of the BR, and use it to sign certificates for
non-browser purposes for as long as they want. In Istanbul there were
also discussions about creating a new intermediate, get it excepted and
blacklisted in root programs, and then issue SHA-1 certs from that one.

On 20-Oct-15 09:31, Gervase Markham wrote:
> how are the
> following two scenarios different? A) CA withdraws a root from the
> public root stores and then uses it to issue SHA-1. B) CA doesn't
> withdraw such a root, but all browsers refuse to accept the issued SHA-1
> certs. In both cases, the certs are not accepted by the browsers.

In case B, if an attacker succesfully attacks the certificate at
issuance time, he could change the certificate. E.g. to CA=True, and
not-before 2015.
Users of older browsers would also be significantly less protected in
case B).

Sigbjørn Vik
Opera Software

More information about the Public mailing list