Re: [pkix] EKU for intermediate certificates

[王文正 <[e-mail]>]

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 [[e-mail]] on behalf of Koichi Sugimoto [[e-mail]]
Sent: Friday, February 05, 2016 3:02 PM
To: Carl Wallace; Peter Bowen; Santosh Chokhani
Cc: <[e-mail]>
Subject: 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:[e-mail]]
Sent: Friday, February 5, 2016 3:00 AM
To: Peter Bowen <[e-mail]>; Santosh Chokhani <[e-mail]>
Cc: Koichi Sugimoto <[e-mail]>; <[e-mail]> <[e-mail]>
Subject: Re: [pkix] EKU for intermediate certificates


On 2/4/16, 12:17 PM, "Peter Bowen" <[e-mail]> 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
><[e-mail]> 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:[e-mail]] On Behalf Of Carl Wallace
>> Sent: Thursday, February 4, 2016 8:14 AM
>> To: Koichi Sugimoto <[e-mail]>
>> Cc: [e-mail]
>> 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 <[e-mail]> on behalf of Koichi Sugimoto
>> <[e-mail]>
>> Date: Thursday, February 4, 2016 at 8:08 AM
>> To: "[e-mail]" <[e-mail]>
>> 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
>> [e-mail] https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>> _______________________________________________
>> pkix mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
>>


_______________________________________________
pkix mailing list
[e-mail]
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.