[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

王文正 wcwang at cht.com.tw
Wed Nov 5 01:24:30 UTC 2014


Dear All,



In terms of  providing a mechanism to support web browsers to check whether the CA conforms to the BRs and therefore certificates issued by that CA can be trusted for web usage, I suggest in the long term we should use CP OID "chaining" for that purpose instead of EKU "chaining". As mentioned in Gerv's proposal, EKU "chaining" is not standard. I believe that is why many CAs like us do not like to include an EKU extension in intermediate CA certificate. We CAs not only make efforts to conform to the BRs but also make our best to conform to PKIX standard (e.g., RFC 5280) as well as the original ITU-T X.509 standard. Unlike EKU "chainging", CP OID "chaining" is the core part of the certification path validation algorithm defined in RFC 5280 and ITU-T X.509 standard. Therefore, I think CP OID "chaining" is more suitable way for that purpose.



If we use CP OID "chaining", the rule for CAs is simple and uniform:

  1.  To issue DV SSL certificates, WebTrust for CAs audit and BR audit must be completed and the BR DV SSL OID must be present in the CP extension of both the intermediate certificate and SSL certificate.
  2.  To issue OV SSL certificates, WebTrust for CAs audit and BR audit must be completed and the BR OV SSL OID must be present in the CP extension of both the intermediate certificate and SSL certificate.
  3.  To issue EV SSL certificates, WebTrust for CAs audit, EV audit, and BR audit must be completed and the BR EV SSL OID (yes, we have to define a BR standard/reserved EV SSL OID) must be present in the CP extension of both the intermediate certificate and SSL certificate.
  4.  To issue EV Code Signing certificates, WebTrust for CAs audit, EV Code Signing audit, and BR audit must be completed and the BR EV Code Signing OID (yes, we have to define a BR standard/reserved EV Code Signing OID) must be present in the CP extension of both the intermediate certificate and SSL certificate.

Browsers can simply use the standard certification path validation algorithm to check whether the CA conforms to the BRs and therefore certificates issued by that CA can be trusted for web usage. If in the future, we define the requirements for issuing OV Code Signing certificates, similar CP OID "chaining" rule will apply.



In this way, the BRs should say that all non-root certs in a chain issued for SSL server use or Code Signing use, which were issued after <date>, should have an appropriate BR reserved CP OID in them. The <date> should be 60 months from the effective date of the new version of BR, because currently most CA does not use BR standard/reserved CP OIDs and the longest validity period for certificates allowed by the current BR is 60 months.



Wen-Cheng Wang



________________________________
寄件者: public-bounces at cabforum.org [public-bounces at cabforum.org] 代表 Gervase Markham [gerv at mozilla.org]
寄件日期: 2014年11月4日 下午 06:03
收件者: Brian Smith
Cc: CABFPub
主旨: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Hi Brian,

One of the (unstated, I guess) assumptions in my proposal is that
telling all the CAs to go out and reissue all or most of their
intermediates won't fly. Do you agree with that?

On 03/11/14 21:20, Brian Smith wrote:
> 1. Require all intermediate certificates that are NOT to be subject to
> the BRs to include an EKU extension which does NOT include
> ip-kp-serverAuth or anyExtendedKeyUsage.
>
> 2. Require the revocation of any intermediate certificates that do not
> have an EKU extension or have an EKU extension with anyExtendedKeyUsage
> and/or have an EKU extension with id-kp-serverAuth.

AIUI, most intermediate certificates don't have an EKU extension at the
moment. So this would be most intermediates, right?

> It is already clear: If the CA certificate can issue certificates that
> web browsers will trust for web usage, then that CA is required to
> conform to the BRs.

The trouble with this, I seem to remember from previous discussions, is
that it's at odds with reality. I think it's less so than it used to be
(when we accepted EE certs with no EKU, which we no longer do), but it
still is. For example, the intermediates which issue millions of
qualified certs to EU citizens are capable of issuing for SSL, but they
aren't subject to the BRs in practice.

This is the problem I'm trying to solve. It's not currently possible, as
I see it, to sanely define the scope of the BRs, and the scope of what
browsers can accept with a programmatic check, and make them match with
no loopholes.

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141105/5b784bea/attachment-0003.html>


More information about the Public mailing list