Re: [pkix] EKU for intermediate certificates

Hello sirs,

I have been facing this interoperability problem for many years.
Around 10 years ago, I found BIG-IP had this kind of implementation, but the user support said this implementation was come from Microsoft library.
Then, now, all major browsers have this implementation.
Even OpenSSL has.
I think this implementation is almost de facto standard.
If so, why RFC does not change the specification?

As for intermediate CA certificates, RFC 5280 says:
"In general, this extension will appear only in end entity certificates."
Can we change this paragraph like:
"If this extension appears in intermediate certificates, ..."?
We should think about which is better for the future interoperability, I think.

Regards,
Koichi Sugimoto.

-----Original Message-----
From: Carl Wallace [mailto:carl@redhoundsoftware.com] 
Sent: Friday, February 5, 2016 3:00 AM
To: Peter Bowen <pzbowen@gmail.com>; Santosh Chokhani <santosh.chokhani@gmail.com>
Cc: Koichi Sugimoto <koichi.sugimoto@globalsign.com>; <pkix@ietf.org> <pkix@ietf.org>
Subject: Re: [pkix] EKU for intermediate certificates

On 2/4/16, 12:17 PM, "Peter Bowen" <pzbowen@gmail.com> wrote:

>The CA/Browser Forum sets standards for Certification Authorities.  It 
>does not set requirements on implementers of path validation.

Does this mean there would be no issue with defining a flag to allow for EKU semantics to be selected, since we now have two? Else we will rely on folklore to know which implementations do what.

>
>That being said, many current web browsers and OS path validation 
>libraries do enforce such constraints.  This includes Microsoft and 
>Mozilla libraries, which underpin Internet Explorer, Edge, Firefox, and 
>Chrome/Opera on Windows.
>
>Thanks,
>Peter
>
>On Thu, Feb 4, 2016 at 7:56 AM, Santosh Chokhani 
><santosh.chokhani@gmail.com> wrote:
>> 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> on behalf of Koichi Sugimoto 
>> <koichi.sugimoto@globalsign.com>
>> Date: Thursday, February 4, 2016 at 8:08 AM
>> To: "pkix@ietf.org" <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 https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>