[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Erwann Abalea erwann.abalea at opentrust.com
Fri Nov 7 11:10:56 UTC 2014


Bonjour,

Le 06/11/2014 11:35, Gervase Markham a écrit :
> On 05/11/14 18:21, kirk_hall at trendmicro.com wrote:
>> I asked our team, and they were doubtful about having to reserve
>> intermediates for SSL only – for example, they might want to use the
>> same intermediate for S/MIME, etc.
> That wouldn't be a problem. I'm not saying an intermediate should _only_
> have id-kpServerAuth, just that it must have it. It can also have other
> EKUs.

The "opt-in" proposal is better, IMO. It doesn't impose modifications of 
the code for software other than browsers.
EKU-chaining is non standard, don't impose it to other RPs. If a public 
root is used to issue certificates for other uses than the ones covered 
by browser members of CABForum (document signing, timestamping, ...) and 
a RP follows the standard, an intermediate having an EKU may be rejected 
(there's no OID for "certificateSign", for example).

As told by Wen-Cheng, CertificatePolicies chaining is the way to go. 
It's the only standardized mechanism to limit the scope of a certificate 
from the root to the end-user. Why don't browsers want to use and impose it?

-- 
Erwann ABALEA




More information about the Public mailing list