Re: [pkix] EKU for intermediate certificates

According the authors of the CABF criteria (I hope they will speak up), the intent of the language is not to make the enforcement of constraint on the certification path mandatory.

They simply want the issuer to indicate limitations it imposes on the CA.

I am generally sympathetic to enforcement of the constraint on the path, however this is a significant change to the semantics of the extension and path validation engine. 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Carl Wallace
Sent: Thursday, February 4, 2016 8:14 AM
To: Koichi Sugimoto <koichi.sugimoto@globalsign.com>
Cc: pkix@ietf.org
Subject: Re: [pkix] EKU for intermediate certificates

in the CAB Forum concept, if there any mechanism to indicate to a compliant validation engine that 5280 EKU semantics ought be used? Allowing a toggle probably beats simply changing the semantics of the extension for all cases. 

From: pkix <pkix-bounces@ietf.org <mailto:pkix-bounces@ietf.org> > on behalf of Koichi Sugimoto <koichi.sugimoto@globalsign.com <mailto:koichi.sugimoto@globalsign.com> >
Date: Thursday, February 4, 2016 at 8:08 AM
To: "pkix@ietf.org <mailto:pkix@ietf.org> " <pkix@ietf.org <mailto:pkix@ietf.org> >
Subject: [pkix] EKU for intermediate certificates

Hello.

I hope the following definition should be changed.

>4.2.1.12.  Extended Key Usage

> 

>   This extension indicates one or more purposes for which the certified

>   public key may be used, in addition to or in place of the basic

>   purposes indicated in the key usage extension.  In general, this

>   extension will appear only in end entity certificates.

Now CABF (CA Browser Forum) specified Extended Key Usage as:

P9:

Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses a

combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the

Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates.

P34:

** Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280

(4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the

use of the extension is consistent between Application Software Suppliers whose software is used by a

substantial portion of Relying Parties worldwide.

P38-39:

For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an

Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is

authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this

extension.

Major browsers already support this specification, therefore, the next RFC should reflect this notation, I think.

This notation is very important because we can restrict the range of influence when end-entity certificates are

unwillingly issued by attacks etc.

Please see below:

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.2.pdf

Regards,

Koichi Sugimoto.

_______________________________________________ pkix mailing list pkix@ietf.org <mailto:pkix@ietf.org>  https://www.ietf.org/mailman/listinfo/pkix 