[cabfpub] Defining BR scope

Sigbjørn Vik sigbjorn at opera.com
Fri Jan 22 10:45:31 UTC 2016


On 22-Jan-16 00:04, Peter Bowen wrote:

> Based on concerns raised offlist about some cert profiles used for
> identity cards, I'll the following alternative:
> 
> "These Requirements apply to all Certificates with a Compliance Date of
> or after February 15, 2013 that include id_kp_serverAuth
> (1.3.6.1.5.5.7.3.1) in the extended key usage extension. 
> 
> Additionally, these Requirements apply to all Certificates with a
> Compliance Date of or after February 15, 2013 that that either do not
> include the extended key usage extension or include anyExtendedKeyUsage
> (2.5.29.37.0) in the extended key usage extension and:
> - do not include a subject alternative name extension or
> - include a subject alternative name extension containing one or more
> entries of type dNSName or iPAddress and 

The problem with excluding any certificates chaining to publicly trusted
roots from the BRs is that of collisions.

If a collision for any certificate chaining to a publicly trusted root
can be generated, then it is possible to generate certificates with
chosen values, including CA=True and changing EKU values. A weak
certificate generated for non-web usage can thus still endanger the web.
See for instance the MD5 attack[1], or look at the reasons for banning
SHA-1. Banning SHA-1 in the BRS is pointless, if SHA-1 certificates can
still be issued from trusted roots, and an attacker can "change" them
into trusted web certificates.

Signature methods will need to be updated with time, so even if the
latest user agents always check that the signature is strong, this will
always leave older user agents at risk. Today SHA-2 is strong, but user
agents shipped on Win 10 with SHA-2 today, would become vulnerable if
SHA-2 some time in the future becomes weak, as it cannot rely on
certificates remaining strong. I believe we should ensure that all
certificates chaining to trusted roots should be strong.

This proposal makes an additional requirement on user agents to ensure
that certificates are issued correctly, which seems the wrong place to
impose such a requirement. Currently, user agents are not required to
check if a new certificate uses SHA-1, as no certificates do this. With
this proposed change, the user agent must check this, to avoid collision
attacks.

There are plenty of use cases other than web for certificates, but apart
from historical reasons, I am not sure I see the reason for using the
same roots for web and non-web?

[1] http://www.win.tue.nl/hashclash/rogue-ca/

-- 
Sigbjørn Vik
Opera Software



More information about the Public mailing list