[cabfpub] Questions about 2016 Microsoft Root Program Changes

[陳立群]

Dear Jody,

 

   Each CA in Microsoft Trusted Root Certificate Program should receive below Root Program Changes effective June 7, 2016. Would you mind discussing in the mailing list or in the Browser News section of the Bilbao F2F Meeting ?

 

1.      We suggest Microsoft clarify No. 7  as  below sentences (we add “new issues “ in red color).

 

Add a new technical requirement (4)(A)(14) to read

 

Effective February 1, 2017, all new issued end-entity certificates must contain the EKU for the purpose that the CA issued the certificate to the customer, and the end-entity certificate may not use “any EKU.”

 

2.      We suggest to delete No.5. As all the end-entity certificates contain the EKUs for one or more purposes for which the certified public key may be used in No.7 .  

There will be extra cost for an exist intermediate CA to separate to different intermediate CAs. (For example, Originally we outsource WebTrust series auditing for ePKI for three years in March. I don’t know if the auditor asked for additional audit report and Seal fee. As we have to separate the CA originally issues TLS/SSL certificates to organizations’ s servers and S/MIME certificates  to organizations. ) . Also if an intermediate CA can issue different end-entity certificates and following No. 7 and other rules without material risks, why does Microsoft add the rule of No.5 ?

 

      3. Also, please tell us how Microsoft will block those end-entity certificates without following with No.5 and No.7 rules in 2017. 

Microsoft is making the following changes to our root program policies and audit requirements. Unless otherwise stated, these requirements will be effective June 7, 2016. If you have any questions, please email rootcert at microsoft.com.


No.

Applies To

Proposed Change


1

 <http://aka.ms/rootcert> Prog. Rules

Add a new continuing program requirement 3.12 with the following language:

 

If Microsoft, in its sole discretion, identifies an Authenticode certificate as either containing a deceptive name or as being used to promote malware or unwanted software, Microsoft will contact the responsible CA and request that is revoke the certificate. The CA must either revoke the certificate within a commercially-reasonable timeframe, or it must request an exception from Microsoft within two (2) business days of receiving Microsoft’s request. Microsoft may either grant or deny the exception at its sole discretion. In the event that Microsoft does not grant the exception, the CA must revoke the certificate within a commercially-reasonable timeframe not to exceed two (2) business days.


2

Prog. Rules

Add a new continuing program requirement 3.13 with the following language:

 

If Microsoft, it its sole discretion, identifies a DV Server Authentication certificate is being used to promote malware or unwanted software, Microsoft will contact the responsible CA and request that it revoke the certificate. The CA must either revoke the certificate within a commercially-reasonable timeframe, or it must request an exception from Microsoft within two (2) business days of receiving Microsoft’s request. Microsoft may either grant or deny the exception at its sole discretion. In the event that Microsoft does not grant the exception, the CA must revoke the certificate within a commercially-reasonable timeframe not to exceed two (2) business days.


3

Prog. Rules

Add a new continuing program requirement 3.14 with the following language:

 

Effective February 1, 2017, any CA enrolled in the program that issues certificates capable of being used for code signing must adopt the CAB Forum Code Signing Baseline Requirements published by the CAB Forum Code Signing Working Group (available at  <http://aka.ms/csbr> http://aka.ms/csbr). Each CA must make the necessary changes to its CP/CPS documents and provide evidence to Microsoft that it has made the change and implemented the required process updates. 


4

Prog. Rules

Add a new technical requirement 4(A)(14) to read

 

A CA must either technically constrain an OCSP responder such that the only EKU allowed is OCSP Signing or it must not use SHA-1 to sign OCSP responses.


5

Prog. Rules

Amend 4(A)(11) to read

 

New intermediate CA certificates under root certificates submitted for distribution by the Program must separate Server Authentication, S/MIME, Code Signing and Time Stamping uses. This means that a single intermediate issuing CA must not be used to issue both server authentication, S/MIME, and code signing certificates. A separate CA must be used for each use case. Please note that this requirement does not apply to roots enrolled in the Program prior to July 1, 2015. Any root enrolled in the program before this date must comply with this requirement by January 1, 2017. 


6

 <http://aka.ms/auditreqs> Audit Reqs.

Add a note under 2(B) that reads

 

Microsoft will only accept ETSI-based audits from CAs that are located in the European Union. All other CAs must use the appropriate WebTrust audits.


7

Prog. Rules

Add a new technical requirement (4)(A)(14) to read

 

Effective February 1, 2017, all end-entity certificates must contain the EKU for the purpose that the CA issued the certificate to the customer, and the end-entity certificate may not use “any EKU.”

 

Sincerely Yours,

 

         Li-Chun CHEN

                    Senior Engineer

                    CISSP, CISA, CISM, PMP,

                    Information & Communication Security Dept.

                    Data Communication Business Group

                    Chunghwa Telecom Co. Ltd.

                    realsky at cht.com.tw

                    +886-2-2344-4820#4025

 



本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
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/20160511/f53664a0/attachment-0002.html>