[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