[cabfpub] Defining BR scope

[Peter Bowen]

> On Jan 22, 2016, at 2:45 AM, Sigbjørn Vik <sigbjorn at opera.com> wrote:
> 
> 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.

I don’t disagree with this assessment, but the current state of affairs, as I understand it, is that any end-entity certificate that is clearly not for server authentication is already excluded.  Many browsers (or should I say ASSes to be BR compliant?) already operate trust stores that recognize a single root to be trusted to issue various kinds of certificates.  Mozilla recognizes kp-emailProtection in addition to kp-serverAuth (and still includes kp-codeSigning for many roots), Microsoft recognizes six key purposes other than kp-serverAuth (and includes another four for many roots), and Apple seems to have many recognized key purposes.

It seems like you are suggesting that what is really needed is a “Baseline Requirements for Publicly Trusted Certification Authorities” which goes beyond just SSL certificates.  Theoretically that would allow the SSL BRs to be a very small document that is basically a certificate profile that further restricts.  I’m not against this, but it would be a big change.  Additionally, given the recent Code Signing vote, I’m not clear that it would be in scope for the CA/Browser Forum as it would be impacting non-browser certificates without any representation from non-browser relying parties or their proxies.

> 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.

I don’t see how this holds or changes anything.  Every client should be doing the checks required by TLS & PKIX (e.g. correct key usages and purposes and matching identity).  If you are worried about prefix attacks, then you need to check the hash algorithm anyway, as someone could pivot from a S/MIME certificate.

> 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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public