Subject: Re: [pkix] EKU for intermediate certificates

From: Carl Wallace <[email-masked]>
Date: Thu, 04 Feb 2016 08:13:37 -0500

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 <[email-masked]> on behalf of Koichi Sugimoto
<[email-masked]>
Date:  Thursday, February 4, 2016 at 8:08 AM
To:  "[email-masked]" <[email-masked]>
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
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 4 Feb 2016 10:56:46 -0500

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:[email-masked]] On Behalf Of Carl Wallace
Sent: Thursday, February 4, 2016 8:14 AM
To: Koichi Sugimoto <[email-masked]>
Cc: [email-masked]
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 <[email-masked] <mailto:[email-masked]> > on behalf of Koichi Sugimoto <[email-masked] <mailto:[email-masked]> >
Date: Thursday, February 4, 2016 at 8:08 AM
To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: [pkix] EKU for intermediate certificates

Hello.

 

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

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

 

Please see below:

 

Regards,

Koichi Sugimoto.

_______________________________________________ pkix mailing list [email-masked] <mailto:[email-masked]>  https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Bowen <[email-masked]>
Date: Thu, 4 Feb 2016 09:17:04 -0800

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

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
<[email-masked]> 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.
>
>
>
> 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.
>
>
>
> This notation is very important because we can restrict the range of
> influence when end-entity certificates are
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Carl Wallace <[email-masked]>
Date: Thu, 04 Feb 2016 13:00:29 -0500

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

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

---

From: Peter Bowen <[email-masked]>
Date: Thu, 4 Feb 2016 10:11:44 -0800

> folklore to know which implementations do what.

If you are writing your own path validation code, I don't see why not.
You are welcome to code however you want.

Thanks,
Peter

---

From: Carl Wallace <[email-masked]>
Date: Thu, 04 Feb 2016 13:19:46 -0500

That rather misses the point, no? But you know that.

---

From: Peter Bowen <[email-masked]>
Date: Thu, 4 Feb 2016 11:01:56 -0800

I'm not sure what other kind of flag would work.  I guess you could
have something like the version field with:

flag EkuFlag DEFAULT unspecified

EkuFlag ::=  INTEGER  {  unspecified(0), direct(1), indirect(2)  }

Where direct means the EKU applies to use of the public key in the CA
certificate and indirect applies to use of the public keys down the
chain.

---

From: Koichi Sugimoto <[email-masked]>
Date: Fri, 5 Feb 2016 07:02:29 +0000

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:[email-masked]] 
Sent: Friday, February 5, 2016 3:00 AM
To: Peter Bowen <[email-masked]>; Santosh Chokhani <[email-masked]>
Cc: Koichi Sugimoto <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [pkix] EKU for intermediate certificates

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

>Mozilla libraries, which underpin Internet Explorer, Edge, Firefox, and 
>Chrome/Opera on Windows.
>
>Thanks,
>Peter
>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> combination of Extended Key Usage settings and Name Constraint 
>>settings to  limit the scope within which the
>>
>> (4.2.1.12)), however, Subordinate CAs MAY include the extension to 
>>further  protect relying parties until the
>>
>>Constrained,  the certificate MUST include an
>>
>>that  the Subordinate CA Certificate is
>>
>> Major browsers already support this specification, therefore, the 
>>next RFC  should reflect this notation, I think.
>>

---

From: 王文正 <[email-masked]>
Date: Sat, 6 Feb 2016 15:53:54 +0000

The original definition of the EKU field in the X.509 standard is to 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 field. The EKU filed should be used in the same fashion as the Key Usage Extension was used.

Indeed, the EKU field will generally appear only in end entity certificates. That does not means this field can not appear in CA certificates. However, if this field appeared in a CA certificate, I think it should be interpreted as to indicates the purpose for which the CA key may be used (similar to the case where the crlSign key usage bit is specified in the Key Usage Extension) rather than as a 'constraint'.

For example, if some organization define a key purpose OID, say id-kp-doSomeThing and the key purpose OID appears in a CA certificate, it should mean that the CA key can be used to do some thing.

It was unfortunately that some implementations misinterpreted the meaning of an EKU extension in a CA certificate. In their fashion of using the EKU extension as a 'constraint', if id-kp-doSomeThing appears in a CA certificate, it means that the CA key can be used to sign certificates of which associated subject keys can be used to do some thing. This obviously twist the original definition of the EKU field.

The earliest implementation that treated an EKU extension in a CA certificate as a 'constraint' I had been aware of is Microsoft Crypto API (CAPI). As a result, certificate management software in Microsoft Windows Server and Microsoft IE all treated an EKU extension in a CA certificate as a 'constraint'. Unfortunately, some CA vendors believed that Microsoft's treating an EKU extension in a CA certificate as a 'constraint' is a correct interpretation or because they had no choice but to follow Micorsoft's interpretation because in that time Microsoft IE dominated the market and they want their certificates to be compatible with Microsoft IE. It was even unfortunately that other browser vendors also followed the wrong interpretation and treated an EKU extension in a CA certificate as a 'constraint'. In the end, that was why there were many browser vendors and CA vendors voted to add text such as "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" in the CA/Browser Forum Baseline Requirements.

I think it is a bad idea to twist the original definition of the EKU field. If the CA/Browser Forum want to use the EKU extension to specify a Subordinate CA is authorized to issue certificates for, the correct way is to define a new key purpose OID rather than adopt the existing PKIX  key purpose OIDs which are defined to be used in end-entity certificates. For example, it the CA/Browser Forum want to use the EKU extension to specify that a Subordinate CA is authorized to issue TLS/SSL certificates, the correct way is to define an CA/Browser key purse OID, say id-cabf-kp-signCertForServerAuth. It is not correct if we use the id-kp-serverAuth OID in a Subordinate CA certificate to specify that the Subordinate CA is authorized to issue TLS/SSL certificates. According to the the original definition of the EKU field in the X.509 standard, that actually means that the the Subordinate CA's key can be used for TLS/SSL server authentication.

Best Regards,
Wen-Cheng Wang

________________________________________
From: pkix [[email-masked]] on behalf of Koichi Sugimoto [[email-masked]]
Sent: Friday, February 05, 2016 3:02 PM
To: Carl Wallace; Peter Bowen; Santosh Chokhani
Cc: <[email-masked]>
Subject: Re: [pkix] EKU for intermediate certificates

Hello sirs,

Regards,
Koichi Sugimoto.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]]
Sent: Friday, February 5, 2016 3:00 AM
To: Peter Bowen <[email-masked]>; Santosh Chokhani <[email-masked]>
Cc: Koichi Sugimoto <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [pkix] EKU for intermediate certificates

>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

---

From: Koichi Sugimoto <[email-masked]>
Date: Tue, 9 Feb 2016 09:10:46 +0000

Umm..

I think we have to provide some solution towards this problem.
I propose 2 solutions.

1)     Change the definition of EKU

2)     Define a new extension and provide a way for transitioning to this new scheme.

If we cannot change the original definition, then, 2) will be a solution.
Anyway, we need a standard solution to restrict key usages of end-entity certificates.
For example,

define an new extension “keyConstraints”.

id-ce-keyConstraints OBJECT IDENTIFIER ::=  { id-ce xx }

   KeyConstraintsSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
   KeyPurposeId ::= OBJECT IDENTIFIER

The format is similar to extendedKeyUsages.

This extension may appear in CA certificates.
This extension will work as nested EKU scheme as follows.

Let {C(1),C(2),…,C(n)} be a set of certificate in certification path, where ‘C(1)’ means the trust anchor and ‘C(n)’ means the end-entity certificate.
Then,
C(i) means the i-th certificate in the certification path.
K(i) means the set of KeyPurposeId in the certificate C(i), especially, K(n) means existing EKU set in the end-entity certificate.

CALCULATE APPLICABLE EKU:

X::={}
For i::=2 to n do {
If C(i) has keyConstraints extension and all C(j) (j<i) does not have keyConstraints extension, then, X::=K(i).
X::=X AND K(i)
}

Finally we can calculate the applicable EKU as “X”.

How do you think of this?

This notation has nothing to do with CABF. I am neutral.

Regards,
Koichi Sugimoto.

From: pkix [mailto:[email-masked]] On Behalf Of 王文正
Sent: Sunday, February 7, 2016 12:54 AM
To: [email-masked]
Subject: Re: [pkix] EKU for intermediate certificates

Best Regards,
Wen-Cheng Wang

Cc: <[email-masked]<mailto:[email-masked]>>

Hello sirs,

Regards,
Koichi Sugimoto.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]]
Sent: Friday, February 5, 2016 3:00 AM
To: Peter Bowen <[email-masked]<mailto:[email-masked]>>; Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Cc: Koichi Sugimoto <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] EKU for intermediate certificates

><[email-masked]<mailto:[email-masked]>> wrote:
>> To: Koichi Sugimoto <[email-masked]<mailto:[email-masked]>>
>> Cc: [email-masked]<mailto:[email-masked]>
>> From: pkix <[email-masked]<mailto:[email-masked]>> on behalf of Koichi Sugimoto
>> <[email-masked]<mailto:[email-masked]>>
>> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 9 Feb 2016 09:18:51 +0000

Just wondering...

> 1)     Change the definition of EKU

Do we have an existence proof that there is s/w deployed for
which such a change in definition would be a problem? I may
have missed that earlier in the thread but wanted to check.

Thanks,
S.

---

From: Koichi Sugimoto <[email-masked]>
Date: Tue, 9 Feb 2016 10:33:23 +0000

Hello Stephen,

I have not seen such implementation before...
I have met several implementations that support nested EKU scheme, and therefore I have been involved in troubles several times..

Regards,
Koichi Sugimoto.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, February 9, 2016 6:19 PM
To: Koichi Sugimoto <[email-masked]>; 王文正 <[email-masked]>; [email-masked]
Subject: Re: [pkix] EKU for intermediate certificates

Just wondering...

> 1)     Change the definition of EKU

Do we have an existence proof that there is s/w deployed for which such a change in definition would be a problem? I may have missed that earlier in the thread but wanted to check.

Thanks,
S.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 9 Feb 2016 10:39:56 +0000

The Certificate Policies extension can be used to restrict "the purposes 
for which the certificate may be used".  That's really what "nested EKU" 
is trying to achieve, isn't it?

So I wonder if, rather than define a completely new extension, we could 
just use the existing policy extensions: Certificate Policies, Policy 
Constraints, Inhibit anyPolicy and Policy Mappings.

Perhaps it would make sense to (re)use the RFC5280 EKU OIDs as Policy 
OIDs, and set some rules for when requireExplicitPolicy must be set.

(BTW, have I just reinvented Microsoft's "Application Policies" 
extension? ;-) )

On 09/02/16 09:10, Koichi Sugimoto wrote:
> 1)Change the definition of EKU
>
> 2)Define a new extension and provide a way for transitioning to this new
> scheme.
>
> Let {C(1),C(2),…,C(n)} be a set of certificate in certification path,
> where ‘C(1)’ means the trust anchor and ‘C(n)’ means the end-entity
> certificate.
>
> Then,
>
> K(i) means the set of KeyPurposeId in the certificate C(i), especially,
> K(n) means existing EKU set in the end-entity certificate.
>
> If C(i) has keyConstraints extension and all C(j) (j<i) does not have
> keyConstraints extension, then, X::=K(i).
>
> X::=X AND K(i)
>
> }
>
> *From:*pkix [mailto:[email-masked]] *On Behalf Of *王文正
> *Sent:* Sunday, February 7, 2016 12:54 AM
> *To:* [email-masked]
> *Subject:* Re: [pkix] EKU for intermediate certificates
>
> The original definition of the EKU field in the X.509 standard is to
> 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 field. The EKU
> filed should be used in the same fashion as the Key Usage Extension was
> used.
>
> Indeed, the EKU field will generally appear only in end entity
> certificates. That does not means this field can not appear in CA
> certificates. However, if this field appeared in a CA certificate, I
> think it should be interpreted as to indicates the purpose for which the
> CA key may be used (similar to the case where the crlSign key usage bit
> is specified in the Key Usage Extension) rather than as a 'constraint'.
>
> For example, if some organization define a key purpose OID, say
> id-kp-doSomeThing and the key purpose OID appears in a CA certificate,
> it should mean that the CA key can be used to do some thing.
>
> It was unfortunately that some implementations misinterpreted the
> meaning of an EKU extension in a CA certificate. In their fashion of
> using the EKU extension as a 'constraint', if id-kp-doSomeThing appears
> in a CA certificate, it means that the CA key can be used to sign
> certificates of which associated subject keys can be used to do some
> thing. This obviously twist the original definition of the EKU field.
>
> The earliest implementation that treated an EKU extension in a CA
> certificate as a 'constraint' I had been aware of is Microsoft Crypto
> API (CAPI). As a result, certificate management software in Microsoft
> Windows Server and Microsoft IE all treated an EKU extension in a CA
> certificate as a 'constraint'. Unfortunately, some CA vendors believed
> that Microsoft's treating an EKU extension in a CA certificate as a
> 'constraint' is a correct interpretation or because they had no choice
> but to follow Micorsoft's interpretation because in that time Microsoft
> IE dominated the market and they want their certificates to be
> compatible with Microsoft IE. It was even unfortunately that other
> browser vendors also followed the wrong interpretation and treated an
> EKU extension in a CA certificate as a 'constraint'. In the end, that
> was why there were many browser vendors and CA vendors voted to add text
> such as "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" in the CA/Browser
> Forum Baseline Requirements.
>
> I think it is a bad idea to twist the original definition of the EKU
> field. If the CA/Browser Forum want to use the EKU extension to specify
> a Subordinate CA is authorized to issue certificates for, the correct
> way is to define a new key purpose OID rather than adopt the existing
> PKIX  key purpose OIDs which are defined to be used in end-entity
> certificates. For example, it the CA/Browser Forum want to use the EKU
> extension to specify that a Subordinate CA is authorized to issue
> TLS/SSL certificates, the correct way is to define an CA/Browser key
> purse OID, say id-cabf-kp-signCertForServerAuth. It is not correct if we
> use the id-kp-serverAuth OID in a Subordinate CA certificate to specify
> that the Subordinate CA is authorized to issue TLS/SSL certificates.
> According to the the original definition of the EKU field in the X.509
> standard, that actually means that the the Subordinate CA's key can be
> used for TLS/SSL server authentication.
>
> Best Regards,
> Wen-Cheng Wang
>
> Cc: <[email-masked] <mailto:[email-masked]>>
> 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.
> To: Peter Bowen <[email-masked] <mailto:[email-masked]>>; Santosh
> Chokhani <[email-masked] <mailto:[email-masked]>>
> Cc: Koichi Sugimoto <[email-masked]
> <mailto:[email-masked]>>; <[email-masked]
> <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> EKU semantics to be selected, since we now have two? Else we will rely
> on folklore to know which implementations do what.
>
>>
>><[email-masked] <mailto:[email-masked]>> wrote:
>>> To: Koichi Sugimoto <[email-masked] <mailto:[email-masked]>>
>>> Cc:[email-masked] <mailto:[email-masked]>
>>> From: pkix <[email-masked] <mailto:[email-masked]>> on behalf of
> Koichi Sugimoto
>>> <[email-masked] <mailto:[email-masked]>>
>>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>>[email-masked] <mailto:[email-masked]>
>>>[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> *
> **本信件可能包含中華電信股份有限公司機密資訊**,**非指定之收件者**,**請勿
> 蒐集、處理或利用本信件內容**,**並請銷毀此信件**. **如為指定收件者**,**應
> 確實保護郵件中本公司之營業機密及個人資料**,**不得任意傳佈或揭露**,**並應
> 自行確認本郵件之附檔與超連結之安全性**,**以共同善盡資訊安全與個資保護責
> 任**.
> Please be advised that this email message (including any attachments)
> contains confidential information and may be legally privileged. If you
> are not the intended recipient, please destroy this message and all
> attachments from your system and do not further collect, process, or use
> them. Chunghwa Telecom and all its subsidiaries and associated companies
> shall not be liable for the improper or incomplete transmission of the
> information contained in this email nor for any delay in its receipt or
> damage to your system. If you are the intended recipient, please protect
> the confidential and/or personal information contained in this email
> with due care. Any unauthorized use, disclosure or distribution of this
> message in whole or in part is strictly prohibited. Also, please
> self-inspect attachments and hyperlinks contained in this email to
> ensure the information security and to protect personal information.*
>
>
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Koichi Sugimoto <[email-masked]>
Date: Tue, 9 Feb 2016 11:07:57 +0000

Hello Rob,

Unfortunately CABF Baseline Requirements already specified this "nested EKU" scheme.
And also several implementations support nested EKU..

How can we cope with that?

Regards,
Koichi Sugimoto.

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Tuesday, February 9, 2016 7:40 PM
To: Koichi Sugimoto <[email-masked]>; 王文正 <[email-masked]>; [email-masked]
Subject: Re: [pkix] EKU for intermediate certificates

The Certificate Policies extension can be used to restrict "the purposes for which the certificate may be used".  That's really what "nested EKU" 
is trying to achieve, isn't it?

So I wonder if, rather than define a completely new extension, we could just use the existing policy extensions: Certificate Policies, Policy Constraints, Inhibit anyPolicy and Policy Mappings.

Perhaps it would make sense to (re)use the RFC5280 EKU OIDs as Policy OIDs, and set some rules for when requireExplicitPolicy must be set.

On 09/02/16 09:10, Koichi Sugimoto wrote:
> 2)Define a new extension and provide a way for transitioning to this 
> new scheme.
>
> 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 field. The EKU filed should be used in the 
> same fashion as the Key Usage Extension was used.
>
> think it should be interpreted as to indicates the purpose for which 
> the CA key may be used (similar to the case where the crlSign key 
> usage bit is specified in the Key Usage Extension) rather than as a 'constraint'.
>
> using the EKU extension as a 'constraint', if id-kp-doSomeThing 
> appears in a CA certificate, it means that the CA key can be used to 
> sign certificates of which associated subject keys can be used to do 
> some thing. This obviously twist the original definition of the EKU field.
>
> but to follow Micorsoft's interpretation because in that time 
> Microsoft IE dominated the market and they want their certificates to 
> be compatible with Microsoft IE. It was even unfortunately that other 
> was why there were many browser vendors and CA vendors voted to add 
> text such as "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" in 
> the CA/Browser Forum Baseline Requirements.
>
> field. If the CA/Browser Forum want to use the EKU extension to 
> specify a Subordinate CA is authorized to issue certificates for, the 
> correct way is to define a new key purpose OID rather than adopt the 
> existing PKIX  key purpose OIDs which are defined to be used in 
> end-entity certificates. For example, it the CA/Browser Forum want to 
> use the EKU extension to specify that a Subordinate CA is authorized 
> to issue TLS/SSL certificates, the correct way is to define an 
> CA/Browser key purse OID, say id-cabf-kp-signCertForServerAuth. It is 
> not correct if we use the id-kp-serverAuth OID in a Subordinate CA 
> certificate to specify that the Subordinate CA is authorized to issue TLS/SSL certificates.
> 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.
> To: Peter Bowen <[email-masked] <mailto:[email-masked]>>; 
> Santosh Chokhani <[email-masked] 
> <mailto:[email-masked]>>
> 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.
>
>>
>>> Extended Key Usage (EKU) extension specifying all extended key 
>>>usages that the Subordinate CA Certificate is
>>>
> contains confidential information and may be legally privileged. If 
> you are not the intended recipient, please destroy this message and 
> all attachments from your system and do not further collect, process, 
> or use them. Chunghwa Telecom and all its subsidiaries and associated 
> companies shall not be liable for the improper or incomplete 
> transmission of the information contained in this email nor for any 
> delay in its receipt or damage to your system. If you are the intended 
> recipient, please protect the confidential and/or personal information 
> contained in this email with due care. Any unauthorized use, 
> disclosure or distribution of this message in whole or in part is 
> strictly prohibited. Also, please self-inspect attachments and 
> hyperlinks contained in this email to ensure the information security 
> and to protect personal information.*
>
>
>

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 9 Feb 2016 11:29:42 +0000

> How can we cope with that?

Koichi,

My last post simply suggested a possible alternative to your "2)Define a 
new extension..." proposal, which also doesn't "cope with" the 
prevalence of the "nested EKU" scheme.  The point I was trying to make 
was: Why define a new extension if there's an existing extension (or set 
of extensions) that can already do the job?

I agree that the prevalence of the "nested EKU" scheme cannot be ignored.

A few years ago I tried to convince Mozilla to _not_ adopt the "nested 
EKU" scheme.  I was unsuccessful.  Microsoft already did "nested EKU", 
and that made it a defacto standard that Mozilla wanted to follow.  And 
then CABForum followed Mozilla.

The ship has already sailed.  For better or worse, "nested EKU" is here 
to stay.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 09 Feb 2016 06:46:27 -0500

>have missed that earlier in the thread but wanted to check.

Yes there is code that does not implement the nested EKU scheme and yes
there are infrastructures that do not implemented the nested EKU scheme.
Hence my suggestion last week (and years ago I think) that we define a way
to select between the semantics in a validation implementation (IMO) to
try to unwind this situation.

Has CAB Forum ever defined the processing semantics in a spec? It's hard
to know the extent of the potential problem without one.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 9 Feb 2016 14:52:41 +0100

Enfin.

That's exactly what the CertificatePolicies is here for.

At CABF level, just require that the different OIDs 2.23.140.1.1,
2.23.140.1.2.1, 2.23.140.1.2.2 are found in the valid_policy_tree returned
by the normalized path validation algorithm when verifying a certificate.

No need to invent a new extension or change the validation algorithm.

2016-02-09 11:39 GMT+01:00 Rob Stradling <[email-masked]>:

> for which the certificate may be used".  That's really what "nested EKU" is
> trying to achieve, isn't it?
>
> (BTW, have I just reinvented Microsoft's "Application Policies" extension?
> ;-) )
>
> this email may be monitored by COMODO for operational or business reasons.
> Whilst every endeavour is taken to ensure that e-mails are free from
> viruses, no liability can be accepted and the recipient is requested to use
> their own virus checking software.
>
>

-- 
Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 9 Feb 2016 19:47:30 +0100

Regarding EKU and path validation, this isn't a new question. See:
https://www.ietf.org/mail-archive/web/pkix/current/msg06821.html
https://www.ietf.org/mail-archive/web/pkix/current/msg06803.html
https://www.ietf.org/mail-archive/web/pkix/current/msg06757.html
https://www.ietf.org/mail-archive/web/pkix/current/msg06726.html

And some good answers:
https://www.ietf.org/mail-archive/web/pkix/current/msg06785.html
https://www.ietf.org/mail-archive/web/pkix/current/msg06781.html

This topic is coming back from the attic :)

2016-02-09 14:52 GMT+01:00 Erwann Abalea <[email-masked]>:

>>> Chokhani <[email-masked] <mailto:[email-masked]
>>> >>
>>>> <[email-masked] <mailto:[email-masked]
>>>>> >>

-- 
Erwann.

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 Feb 2016 18:38:58 -0500

It is very unfortunate that the CABF has chosen to change the semantics of the Extended Key Usage (EKU) extension.  This extension was never intended to impact path validation.

If we were being asked how a root CA could impose EKU constraints on subordinates, I would have suggested a very different mechanism.  We have name constraints and policy constraints that offer design patterns.

So, how do we cope with the existing implementations and maximize interoperability?

Russ

---

From: Peter Bowen <[email-masked]>
Date: Tue, 9 Feb 2016 18:00:41 -0800

Russ,

> It is very unfortunate that the CABF has chosen to change the semantics of the Extended Key Usage (EKU) extension.  This extension was never intended to impact path validation.

This timeline is a little wrong.  The CABF only documented this
semantic after all the browsers had already set it.  I believe that
Microsoft's implementation has followed the EKU-as-constraint semantic
since ca. 2001, Mozilla had it as part of their policy since 2011, and
OpenSSL implemented EKU-as-constraint in 1999.  I don't have dates for
Apple, but I believe they implement the same semantic.

> So, how do we cope with the existing implementations and maximize interoperability?

This is the key question.  We know there is reliance on the
EKU-as-constraint semantic.  Is there reliance on the
EKU-as-CA-key-purpose semantic?

Thanks,
Peter

---

From: Peter Bowen <[email-masked]>
Date: Tue, 9 Feb 2016 18:12:18 -0800

> Apple, but I believe they implement the same semantic.

And now I realize that I missed Erwann's excellent email where he
points out that both Microsoft and Netscape had the EKU-as-constraint
implemented by November 2000.  I would posit that, more than 15 years
later, maybe it is time to document what has clearly been
independently implemented in an inter-operable manner many times.