Re: [cabfpub] Voting Begins: Ballot Forum-9 - Bylaws and Server Certificate Working Group Charter Updates

[realsky(CHT) via Public]

Chunghwa Telecom votes yes on BallotForum-9, thanks.


 Li-Chun Chen

On Mon, May 13, 2019 at 11:59 AM Wayne Thayer  wrote:

> Purpose of Ballot: The Forum has identified and discussed a number of
> improvements to be made to the current version of the Bylaws to improve
> clarity and allow the Forum to function more effectively. Major changes
> include:
> * Formalize Subcommittees at the Forum level
> * Automatically grant Forum membership to CWG members
> * Move Forum membership requirements to the SCWG Charter and clarify them
> * Clarify CWG voting rules
> * Clarify process for CWG officer elections
>
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by Dimitris Zacharopoulos of HARICA and Tim Hollebeek of DigiCert
> to amend the Bylaws of the CA/Browser Forum and the Server Certificate
> Working Group Charter.
>
>
> — MOTION BEGINS –
>
> 1. Amendment to the Bylaws: replace the entire text of the Bylaws of the
> CA/Browser Forum with the following:
>
>
> https://github.com/cabforum/documents/blob/f749189752994b378fae2ca9b8f22f51fcc2e204/docs/Bylaws.md
>
>
> 2. Amendment to the SCWG Charter: replace the entire text of the Server
> Certificate Working Group Charter with the following:
>
> https://github.com/cabforum/documents/blob/f749189752994b378fae2ca9b8f22f51fcc2e204/docs/SCWG-charter.md
>
> — MOTION ENDS –
>
>
> *** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE
> OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>
> A comparison of the changes can be found at:
> https://github.com/cabforum/documents/compare/0616216..f749189?diff=split
>
>
> The procedure for approval of this ballot is as follows:
>
> Formal discussion period:  (14+ days)
>
> Start time:   April 26, 2019 19:00 UTC
>
> End Time:  May 13, 2019 19:00 UTC
>
> Vote for approval (7 days)
>
> Start time: May 13, 2019 19:00 UTC
>
> End time:  May 20, 2019 19:00 UTC
>
-- next part --
An HTML attachment was scrubbed...
URL: 


   

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


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Code Signing Working Group - Call for Participants

[realsky(CHT) via Public]

Dear Dean,

   Please add Chia-Hsien Lin and Tsung-Han Yang as the initial participants of 
Chunghwa Telecom in the Code Signing WG.
   
   I will e-mail you the e-mail addresses of the initlal particpants of 
Chunghwa Telecom. So later we can join the discussion list.

   Thank you.

Li-Chun 


-Original message-
From:realsky(CHT) 
To:CA/Browser Forum Public Discussion List 
Cc:Dean Coclin 
Date:Wed, 13 Mar 2019 05:42:49
Subject:Re: [cabfpub] Code Signing Working Group - Call for Participants

Chunghwa Telecom Co., Ltd. would like to to participate in the Code Signing WG.

The initial participants will be: Li-Chun Chen and Tsung-Min Kuo. 

However Chunghwa Telecom Co., Ltd. does not issue code-signing certs so we ask 
to be granted an invitation for Associate Member status first in this WG.

  Li-Chun Chen
  Chunghwa Telecom



-Original message-

On 03/12/2019 09:46 AM, Dean Coclin via Public wrote:
> In accordance with the CA/B Forum Bylaws and the Charter of said working
> group, the Interim Chair announces a call for Participants interested in
> joining the Code Signing Working Group.
> 
>  
> 
> Current CA/B Forum members should submit their names and company
> affiliations, as a formal declaration of their intent (or provide them
> at the face to face meeting).
> 
>  
> 
> Interested Parties are eligible to participate once they provide the
> signed IPR agreement to the Chair.
> 
>  
> 
> Here is the text from the ballot relevant to membership:
> 
>  
> 
> The CSCWG SHALL consist of two classes of voting members, Certificate
> Issuers and Certificate Consumers meeting the eligibility criteria below:
> 
>  
> 
> (1)  A Certificate Issuer eligible for voting membership in the
> CSCWG MUST have a publicly-available audit report or attestation
> statement in accordance with one of the following schemes:
> 
>  
> 
> *WebTrust for CAs v.2.0 or newer; or
> 
> *ETSI EN 319 411-1, which includes normative references to
> ETSI EN 319 401 (the latest version of the referenced ETSI documents
> should be applied); or
> 
> *If a Government Certificate Issuer is required by its
> Certificate Policy to use a different internal audit scheme, it MAY use
> such scheme provided that the audit either (a) encompasses all
> requirements of one of the above schemes or (b) consists of comparable
> criteria that are available for public review.
> 
>  
> 
> These audit reports must also meet the following requirements:
> 
>  
> 
> *They must report on the operational effectiveness of
> controls for a historic period of at least 60 days;
> 
> *No more than 27 months have elapsed since the beginning of
> the reported-on period and no more than 15 months since the end of the
> reported-on period; and
> 
> *The audit report was prepared by a Qualified Auditor.
> 
>  
> 
> In addition, the Certificate Issuer MUST actively issue code signing
> certificates that are accepted for use in computing platforms in which
> the platform supplier accepts code signing certificates issued by such
> Certificate Issuer.
> 
>  
> 
>  
> 
> (2)A Certificate Consumer (i.e. a platform supplier) eligible for
> voting membership in the CSCWG must produce a computing platform that
> accepts code signing certificates issued by third-party Certificate
> Issuers who meet criteria set by such Certificate Consumer.
> 
>  
> 
>  
> 
> 4.2.2 Membership Application/Declaration process
> 
>  
> 
> A.   An Applicant not already a member of the Forum SHALL
> provide the following information:
> 
>  
> 
> *Confirmation that the applicant satisfies at least one (1)
> of the membership eligibility criteria (and if it satisfies more than
> one (1), indication of the single category under which the applicant
> wishes to apply).
> 
> *The organization name, as they wish it to appear on the
> Forum Web site and in official Forum documents.
> 
> *URL of the applicant's main Web site.
> 
> *Names and email addresses of employees who will participate
> in the Working Group and Forum as Member representatives.
> 
> *Emergency contact information for security issues related
> to certificate trust.
> 
>  
> 
> Applicants that qualify as Certificate Issuers or Root Certificate
> Issuers must supply the following additional information:
> 
>  
> 
> *URL of the current qualifying audit report.
> 
> *The URL of at least one third party website that includes a
> certificate issued by the Applicant in the certificate chain.
> 
> *Links or references to issued end-entity certificates that
> demonstrate them being treated as valid by a Certificate Consumer Member.
> 
>  
> 
> Such Applicant SHALL become a Member once the CSCWG has determined by
> consensus among the Members during a CSCWG Meeting or Teleconference
> that the Applicant meets all of the requirements above 

Re: [cabfpub] Code Signing Working Group - Call for Participants

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. would like to to participate in the Code Signing WG.

The initial participants will be: Li-Chun Chen and Tsung-Min Kuo. 

However Chunghwa Telecom Co., Ltd. does not issue code-signing certs so we ask 
to be granted an invitation for Associate Member status first in this WG.

  Li-Chun Chen
  Chunghwa Telecom



-Original message-

On 03/12/2019 09:46 AM, Dean Coclin via Public wrote:
> In accordance with the CA/B Forum Bylaws and the Charter of said working
> group, the Interim Chair announces a call for Participants interested in
> joining the Code Signing Working Group.
> 
>  
> 
> Current CA/B Forum members should submit their names and company
> affiliations, as a formal declaration of their intent (or provide them
> at the face to face meeting).
> 
>  
> 
> Interested Parties are eligible to participate once they provide the
> signed IPR agreement to the Chair.
> 
>  
> 
> Here is the text from the ballot relevant to membership:
> 
>  
> 
> The CSCWG SHALL consist of two classes of voting members, Certificate
> Issuers and Certificate Consumers meeting the eligibility criteria below:
> 
>  
> 
> (1)  A Certificate Issuer eligible for voting membership in the
> CSCWG MUST have a publicly-available audit report or attestation
> statement in accordance with one of the following schemes:
> 
>  
> 
> *WebTrust for CAs v.2.0 or newer; or
> 
> *ETSI EN 319 411-1, which includes normative references to
> ETSI EN 319 401 (the latest version of the referenced ETSI documents
> should be applied); or
> 
> *If a Government Certificate Issuer is required by its
> Certificate Policy to use a different internal audit scheme, it MAY use
> such scheme provided that the audit either (a) encompasses all
> requirements of one of the above schemes or (b) consists of comparable
> criteria that are available for public review.
> 
>  
> 
> These audit reports must also meet the following requirements:
> 
>  
> 
> *They must report on the operational effectiveness of
> controls for a historic period of at least 60 days;
> 
> *No more than 27 months have elapsed since the beginning of
> the reported-on period and no more than 15 months since the end of the
> reported-on period; and
> 
> *The audit report was prepared by a Qualified Auditor.
> 
>  
> 
> In addition, the Certificate Issuer MUST actively issue code signing
> certificates that are accepted for use in computing platforms in which
> the platform supplier accepts code signing certificates issued by such
> Certificate Issuer.
> 
>  
> 
>  
> 
> (2)A Certificate Consumer (i.e. a platform supplier) eligible for
> voting membership in the CSCWG must produce a computing platform that
> accepts code signing certificates issued by third-party Certificate
> Issuers who meet criteria set by such Certificate Consumer.
> 
>  
> 
>  
> 
> 4.2.2 Membership Application/Declaration process
> 
>  
> 
> A.   An Applicant not already a member of the Forum SHALL
> provide the following information:
> 
>  
> 
> *Confirmation that the applicant satisfies at least one (1)
> of the membership eligibility criteria (and if it satisfies more than
> one (1), indication of the single category under which the applicant
> wishes to apply).
> 
> *The organization name, as they wish it to appear on the
> Forum Web site and in official Forum documents.
> 
> *URL of the applicant's main Web site.
> 
> *Names and email addresses of employees who will participate
> in the Working Group and Forum as Member representatives.
> 
> *Emergency contact information for security issues related
> to certificate trust.
> 
>  
> 
> Applicants that qualify as Certificate Issuers or Root Certificate
> Issuers must supply the following additional information:
> 
>  
> 
> *URL of the current qualifying audit report.
> 
> *The URL of at least one third party website that includes a
> certificate issued by the Applicant in the certificate chain.
> 
> *Links or references to issued end-entity certificates that
> demonstrate them being treated as valid by a Certificate Consumer Member.
> 
>  
> 
> Such Applicant SHALL become a Member once the CSCWG has determined by
> consensus among the Members during a CSCWG Meeting or Teleconference
> that the Applicant meets all of the requirements above or, upon the
> request of any Member of the CSCWG, by a Ballot among Members of the
> CSCWG. Acceptance by consensus shall be determined or a Ballot of the
> Members shall be held as soon as the Applicant indicates that it has
> presented all information required above and has responded to all
> follow-up questions from the CSCWG and the Member has complied with the
> requirements of Bylaw 5.5.
> 
>  
> 
> Certificate Issuer applicants that are not actively issuing code signing
> certificates but otherwise meet 

Re: [cabfpub] Voting has started on Ballot SC10 – Establishing the Network Security Subcommittee of the SCWG

[realsky(CHT) via Public]

Chunghwa Telecom votes YES on Ballot SC10.

Thanks!

   Li-Chun Chen



From: Public mailto:public-bounces at 
cabforum.org>> On Behalf Of Kirk Hall via Public
Sent: Thursday, September 27, 2018 5:26 PM
To: CABFPub mailto:public at cabforum.org>>
Subject: [cabfpub] Voting has started on Ballot SC10 – Establishing the Network 
Security Subcommittee of the SCWG

Voting ends on 4 October 2018 at 22:00 UTC.

From: Servercert-wg [mailto:servercert-wg-bounces at cabforum.org] On Behalf Of 
Dimitris Zacharopoulos via Servercert-wg
Sent: Thursday, September 20, 2018 9:02 AM
To: CA/B Forum Server Certificate WG Public Discussion List mailto:servercert-wg at cabforum.org>>
Subject: [Servercert-wg] Ballot SC10 – Establishing the Network Security 
Subcommittee of the SCWG
Ballot SC10 – Establishing the Network Security Subcommittee of the SCWG

Purpose of Ballot
The Network Security Working Group of the CA/Browser Forum expired on June 19, 
2018 under the terms of Ballot 203 which established the Working Group. The 
Server Certificate Working Group wishes to establish a Network Security 
Subcommittee pursuant to Bylaws 5.3.1(e).
The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Tim Hollebeek of DigiCert and Wayne Thayer of Mozilla.
--- MOTION BEGINS ---
The Server Certificate Working Group hereby establishes the Network Security 
Subcommittee as an official Subcommittee.

1. Mission: To improve security policies and practices for Certificate 
Management Systems encoded in the guidelines maintained by the SCWG.

2. End Date: This Subcommittee shall continue until it is dissolved by a vote 
of the SCWG
3. Deliverables: The Network Security Subcommittee shall propose ballots to the 
SCWG to improve the minimal security standards within the mission defined above 
This includes modifying the existing Network and Certificate System Security 
Requirements (NCSSR) or to create new requirements, guidelines, or best 
practices. Among other activities, the Network Security Subcommittee shall 
perform security analysis on typical CA Management Systems offering options to 
the Server Certificate Working Group for establishing minimal security 
standards. Risk analysis will also be used to provide a better understanding of 
threats and vulnerabilities in Certificate Management Systems. This process can 
be used to provide better reasoning and justification of existing or future 
security guidelines.
4. Participation: Any member of the SCWG is eligible and may declare their 
participation in the Network Security Subcommittee by requesting to be added to 
the mailing list.
5. Chair: Ben Wilson shall be the initial Chair of the Network Security 
Subcommittee.  The Subcommittee may change its Chair from time to time by 
consensus of the Members participating in the Subcommittee or by voting method 
chosen by the Members by consensus.
6. Communication: Subcommittee communications and documents shall be posted on 
mailing-lists where the mail-archives are publicly accessible, and the 
Subcommittee shall publish minutes of its meetings.
7. Effect of SCWG Charter or Forum Bylaws Amendment for Subcommittees: In the 
event the SCWG Charter or the Forum Bylaws is amended to add general rules 
governing Chartered Working Group Subcommittees and how they operate (“General 
Rules”), the provisions of the General Rules shall take precedence over this 
charter.
--- MOTION ENDS ---


The procedure for approval of this ballot is as follows:
Ballot SC10 – Establishing the Network Security Subcommittee of the SCWG


Start time (22:00 UTC)


End time (22:00 UTC)


Discussion (7 days)


20 September 2018


27 September 2018


Vote for approval (7 days)


27 September 2018


4 October 2018




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


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] Ballot SC6 v3 - Revocation Timeline Extensi on

[realsky(CHT) via Public]

Chunghwa Telecom  votes YES to Ballot SC6 v3. 




   Li-Chun Chen
 
From: Servercert-wg On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: fredag 31. august 2018 21:52
To: CA/B Forum Server Certificate WG Public Discussion List 

Cc: CA/Browser Forum Public Discussion List 
Subject: [Servercert-wg] Ballot SC6 v3 - Revocation Timeline Extension
 
Here is version 3 of this ballot, incorporating changes to v2 suggested by 
Bruce and Ryan (thanks!).

 

I noticed that our current bylaws have reverted back to a fixed-length 
discussion period, so I have changed this version to comply.


==
Ballot SC6 version 3: Revocation Timeline Extension

 

Purpose of Ballot:
Section 4.9.1.1 of the Baseline Requirements currently requires CAs to revoke a 
Subscriber certificate within 24 hours of identifying any of 15 issues 
affecting the certificate. In cases where there is not an immediate threat of 
misuse of the certificate, this requirement can cause undue harm to a 
Subscriber that isn't capable of replacing the certificate prior to revocation. 
This ballot makes a number of improvements to the revocation rules imposed by 
the Baseline Requirements:
* Primarily, it creates a tiered timeline for revocations. The most critical 
"reasons" still require revocation within 24 hours, but for many others 24 
hours becomes a SHOULD and the CA has 5 days before they MUST revoke.
* A new "reason for revocation" was added to address the fact that there is 
currently no requirement for CAs to revoke a certificate when requested by the 
domain name registrant. After considering some more specific language that 
required CAs to follow 3.2.2.4 to validate domain control, I settled on the 
following more general "reason": "The CA obtains evidence that the validation 
of domain authorization or control for any Fully-Qualified Domain Name or IP 
address in the Certificate should not be relied upon."
* Reason #10 states "The CA determines that any of the information appearing in 
the Certificate is inaccurate or misleading;" This ballot removes "or 
misleading" because that is a subjective judgement that could effectively be 
used to justify censorship, as discussed at length in relation to the "Stripe, 
Inc of Kentucky" EV certificates.
* Current reasons #11 and #13 were removed from the section on subscriber 
certificates because they address cases where the intermediate and/or root must 
be revoked, so there isn't much sense (and some possible harm) in requiring 
revocation of all the leaf certs.
* It requires CAs to disclose their problem reporting mechanisms in a standard 
location: CPS section 1.5.2.
* Within 24 hours of receiving a problem report, the CA is now required to 
report back to both the entity reporting the problem and the Subscriber on the 
CA's findings, and to work with the reporter and Subscriber to establish a date 
by which the CA will revoke the certificate.

The following motion has been proposed by  Wayne Thayer of Mozilla and endorsed 
by Tim Hollebeek of DigiCert and Dimitris Zacharopoulos of Harica.


--- MOTION BEGINS ---

This ballot modifies the “Baseline Requirements for the 
Issuance and Management of Publicly-Trusted Certificates” as follows, based on 
Version 1.6.0:



 

** Modify the definition of Key Compromise as follows: **

Key Compromise: A Private Key is said to be compromised if its value has been 
disclosed to an unauthorized person or an unauthorized person has had access to 
it.
 

** Modify Section 4.9.1 to read as follows: **



 

4.9.1.1 Reasons for Revoking a Subscriber Certificate

 

The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs:

1. The Subscriber requests in writing that the CA revoke the Certificate;
2. The Subscriber notifies the CA that the original certificate request was not 
authorized and does not retroactively grant authorization;
3. The CA obtains evidence that the Subscriber's Private Key corresponding to 
the Public Key in the Certificate suffered a Key Compromise; or
4. The CA obtains evidence that the validation of domain authorization or 
control for any Fully-Qualified Domain Name or IP address in the Certificate 
should not be relied upon.

The CA SHOULD revoke a certificate within 24 hours and MUST revoke a 
Certificate within 5 days if one or more of the following occurs:
1. The Certificate no longer complies with the requirements of Sections 6.1.5 
and 6.1.6;
2. The CA obtains evidence that the Certificate was misused;
3. The CA is made aware that a Subscriber has violated one or more of its 
material obligations under the Subscriber Agreement or Terms of Use;
4. The CA is made aware of any circumstance indicating that use of a 
Fully-Qualified Domain Name or IP address in the Certificate is no longer 
legally permitted (e.g. a court or arbitrator has revoked a Domain Name 
Registrant's right to use the Domain Name, a relevant licensing or services 
agreement between the 

Re: [cabfpub] [cabfquest] Wrong reference in BRGs, chapter 8.4

[realsky(CHT) via Public]

Dear Ben,

  I just found Rufus is not a member. So what about discussion in Policy 
reviewing WG to propose a ballot to solve the issue. Besides, I suggest to 
confirm from Jeff or Don of CPA and ETSI, which definition is better:
 Qualified Auditor: An independent public accounting firm that meets the 
auditing qualification requirements as defined in Section 8.3 of the Baseline 
Requirements
or 
 Qualified Auditor: A natural person or Legal Entity that meets the auditing 
qualification requirements as defined in Section 8.3 of the Baseline 
Requirements
 Are there any case a natural person to conduct WebTrust for CA audit or 
ETSI audit now? or An independent public accounting firm or Legal Entity is 
better.

 I am sorry that now the teleconference time of Policy reviewing WG is at 
1:00 AM to 2:00  in Taipei. Because it is sleeping time that I can't join. But 
I can join the discussion in CP WG List or Public List.

Sincerely Yours,

 Li-Chun
 Deputy Senior Engineer  CISSP, CISA, CISM, PMP
  Chunghwa Telecom 
  Taiwan  

-Original message-
From:realsky(CHT)
To:Barry 
Kilborn,public,questions
Cc:realsky
Date: Wed, 07 Feb 2018 22:41:32
Subject: Re: [cabfquest] Wrong reference in BRGs, chapter 8.4
Dear  Rufus,

 Besides, In writing BR assessment, I found there is another wrong 
reference in the Section 1.6 of BR. The defitinon of "Qualified Auditor" is 
read as Qualified Auditor : A natural person or Legal Entity that meets the 
requirements of Section 8.3. It should be   "Qualified Auditor : A natural 
person or Legal Entity that meets the requirements of Section 8.2."  I think 
the wrong reference is from the conversion of BR V1.2.5 or earlier version  to 
RFC 3647 verison of BR. (Version 1.3.0/ Version 1.2.5 :Qualified Auditor: A 
natural person or Legal Entity that meets the requirements of Section 8.3 
(Auditor Qualifications).) . Please see attached file or 
https://cabforum.org/baseline-requirements-documents/ 

If you read EVGL, then the defition of Qualified Auditor is correct. 
Qualified Auditor: An independent public accounting firm that meets the 
auditing qualification requirements specified in Section 17.6 of these 
Guidelines.

And you will see section 17.6 as 
17.6. Auditor Qualification
A Qualified Auditor (as defined in Section 8.2 of the Baseline Requirements) 
MUST perform the CA’s audit.

If you propose these amendment, I will endorse the ballot. 
 
Sincerely Yours, 


  Li-Chun Chen
  Deputy Senior Engineer
  CISSP, CISA, CISM, PMP
  Chunghwa Telecom 
  Taiwan

-Original message-
From:Buschart, Rufus
To:questi...@cabforum.org
Cc:Barry Kilborn
Date: Mon, 05 Feb 2018 19:05:01
Subject: [外部郵件] [cabfquest] Wrong reference in BRGs, chapter 8.4
Dear CA/B forum members!
 
It appear there is a wrong reference in the BRGs, chapter 8.4 “Topics covered 
by assessment”. This chapter includes the statement “The audit MUST be 
conducted by a Qualified Auditor, as specified in Section 8.3.”. This should 
most probably read “as specified in Section 8.2” which describes 
“Identity/qualifications of assessor”. Section 8.3 is empty.
 
I would propose, this should be changed in one of the upcoming ballots. I would 
post this directly to the mailing list, but as not being a member, I’m 
prohibited from posting.
 
Best regards
 
Rufus
 

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nnberg, Deutschland
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; 
Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, 
Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Sitz der Gesellschaft: 
Berlin und Mchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 
12300, Mchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322

___
Questions mailing list
questi...@cabforum.org
https://cabforum.org/mailman/listinfo/questions




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

Re: [cabfpub] Voting begins: Ballot 218 version 2

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. Votes “No”  on Ballot 218. 


   Li-Chun Chen




From: Public[mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveenvia Public
Sent: Friday, February 02, 2018 8:52 PM
To: Tim Hollebeek; CA/Browser Forum Public Discussion List
Subject: [外部郵件]Re: [cabfpub] Voting begins: Ballot 218 version 2
 
Buypass votes NO.
 
There are use cases and scenarios where animproved version of method #1 for 
proving ownership of a domain would beappropriate. Method #1 is only to be used 
for OV/EV and as such theauthorization to issue the certificate must be given 
by an authoritativerepresentative of the applicant. If we can prove that the 
applicant is equal tothe domain owner in a proper way, we consider this to be 
sufficient to issuethe certificate. The validation and issuance of OV/EV must 
be based on bothverifying the Applicant’s identity and domain ownership (with 
or without thetechnical demonstration of domain control). 
 
BR 3.2.2.4 says ‘defines the permittedprocesses and procedures for validating 
the Applicant’s ownership or control ofthe domain’. The concept of validating 
an Applicant’s ownership is mostimportant for OV/EV as this is a scenario where 
the Applicant always must beverified. Then it is possible to verify domain 
ownership based on a properlyverified identity and address of the Applicant. 
All other methods focus ondomain control and we can’t see that the concept of 
domain ownership is wellcovered by any of these methods. 
 
We understand that domain control isconsidered to be very important, but we 
would like to emphasize that weconsider the concept of ‘domain control’ and 
‘domainownership’ to be two different concepts - atleast seen in relation to 
the issuance of OV/EV. If we really mean to includeboth concepts in the domain 
validation methods, this should be made moreexplicit. 
 
We are concerned that a switch of focustowards domain control also for OV/EV 
might result in less focus on domainownership and thus giving any actor who 
controls the domain a possibility toget an OV/EV for that domain. I would hate 
to see e.g. the DNS provider ofBuypass AS being able to get an EV certificate 
with the identity of the DNSprovider and the domain buypass.no based on domain 
control only. 
 
It is difficult to evaluate the quality ofmethod #1 on itself without at the 
same time evaluate the parts of BR (and EVG)relevant for using the method - for 
OV (BR 3.2.2.1 and 3.2.5) and similar inEVG for EV.
 
We are not convinced that all the othermethods based on domain control in all 
cases necessarily provides a higherlevel of assurance than an improved method 
#1 for OV/EV certificates. We agreewith Dimitris that it is important to get a 
better understanding of thevulnerabilities and threats for each of the domain 
validation methods and thisshould be analyzed independently for DV and OV/EV.
 
Regards
Mads
 
 

From: Public  on behalf of Tim Hollebeek via 
Public 
Reply-To: Tim Hollebeek , CA/Browser Forum Public 
Discussion List 
Date: Monday, 29 January, 2018 at 17:07 
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting begins: Ballot 218 version 2

 

 

I’m highly skeptical that discussing this for another month will change 
anybody’s minds.  It has already been discussed for over a month, including at 
three validation working group meetings and once on the management call, with 
extensive discussion on this list as well.

 

There have been a number of clever attempts to distract from the matter at 
hand.  Everybody seems to agree that methods #1 and #5 as currently written are 
insufficient to validate certificates, and efforts to improve method #1 have 
all either been shown to be similarly weak, or have turned the validation 
method into one of the other existing validation methods.  In fact, this 
demonstrates an obvious transition path for CAs currently using method #1: use 
method #2 or method #3.

 

Since methods #1 and #5 do not sufficiently validate certificates, they should 
not be used, and six months should be more than enough time to cease using them.

 

Here is the final version of the ballot, with voting times.  A redlined 
document is attached (I encourage other proposers to post ballot redlines, even 
if it isn’t required).

 

-Tim

 

- Ballot 218 version 2: Remove validation methods #1 and #5 -

 

Purpose of Ballot: Section 3.2.2.4 says that it “defines the permitted 
processes and procedures for validating the Applicant’s ownership or control of 
the domain.”  Most of the validation methods actually do validate ownership and 
control, but two do not, and can be completed solely based on an applicant’s 
own assertions.

 

Since these two validation methods do not meet the objectives of section 
3.2.2.4, and are actively being used to avoid validating domain control or 
ownership, 

Re: [cabfpub] Ballot 214: CAA Discovery CNAME Errata

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. Votes Yes on Ballot 214

Li-Chun Chen

De: Public [mailto:public-boun...@cabforum.org] En nombre de Jacob 
Hoffman-Andrews via Public
Enviado el: miércoles, 13 de septiembre de 2017 23:31
Para: CABFPub
Asunto: [cabfpub] Ballot 214: CAA Discovery CNAME Errata
 
Kicking off the official discussion period for ballot 214 today per discussion 
with Phillip.
 

The following motion has been proposed by Phillip Hallam-Baker of Comodo Group 
Inc. and endorsed by Gervase Markham of Mozilla and Mads Egil Henriksveen of 
Buypass.

-- MOTION BEGINS --

In the Baseline Requirements v1.4.9 Section 3.2.2.8. CAA Records
 
Strike:
 
As part of the issuance process, the CA MUST check for a CAA record for each 
dNSName in the subjectAltName extension of the certificate to be issued, 
according to the procedure in RFC 6844, following the processing instructions 
set down in RFC 6844 for any records found. If the CA issues, they MUST do so 
within the TTL of the CAA record, or 8 hours, whichever is greater.
 
Replace with:
 
As part of the issuance process, the CA MUST check for CAA records and follow 
the processing instructions for any records found, for each dNSName in the 
subjectAltName extension of the certificate to be issued, as specified in RFC 
6844 as amended by Errata 5065 (Appendix A). If the CA issues, they MUST do so 
within the TTL of the CAA record, or 8 hours, whichever is greater.
 

In the Baseline Requirements ADD an Appendix A that reads:

Appendix A -- RFC6844 Errata 5065

The following errata report has been held for document update for RFC6844, "DNS 
Certification Authority Authorization (CAA) Resource Record".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5065

--
Status: Held for Document Update
Type: Technical

Reported by: Phillip Hallam-Baker  Date Reported: 
2017-07-10 Held by: EKR (IESG)

Section: 4

Original Text
-
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and R(A(X)) is not empty, then R(X) =
  R(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

Corrected Text
--
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record chain specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
  CAA(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

  Thus, when a search at node X returns a CNAME record, the CA will
  follow the CNAME record chain to its target. If the target label
  contains a CAA record, it is returned.

  Otherwise, the CA continues the search at
  the parent of node X.

  Note that the search does not include the parent of a target of a
  CNAME record (except when the CNAME points back to its own path).

  To prevent resource exhaustion attacks, CAs SHOULD limit the length of
  CNAME chains that are accepted. However CAs MUST process CNAME
  chains that contain 8 or fewer CNAME records.

--Motion Ends--

The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

BALLOT 214 Status:   Final Maintenance GuidelineStart time (22:00 UTC)
End time (22:00 UTC)

Discussion begins now and ends September 20, 2017 22:00 UTC (7 days)

Vote for approval begins September 20, 2017 22:00 UTC and ends September 27, 
2017 22:00 UTC (7 days)

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created. If no Exclusion Notices filed, ballot becomes effective at end of 
Review Period.Upon filing of Review Notice by Chair 30 days after filing of 
Review Notice by Chair

From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines. Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in 

Re: [cabfpub] Voting has started on Ballot 190

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. votes “Yes”


Li-Chun Chen


-Original message-
From:Peter Miškovič via Public
To:'Kirk Hall','CA/Browser Forum Public 
Discussion List'
Date: Tue, 19 Sep 2017 23:00:30
Subject: [外部郵件] Re: [cabfpub] Voting has started on Ballot 190
Disig votes „YES“.
 
Regards
Peter Miskovic
 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Kirk Hall via 
Public
Sent: Wednesday, September 13, 2017 12:23 AM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Voting has started on Ballot 190

 
Voting has started on Ballot 190 as proposed on Sept 5 (see bottom of this 
message, and attachments), as amended by my email from Sept. 11 (see 
immediately below).  Voting runs through Sept. 19 at 18:00 UTC.
 
Entrust votes yes.
 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Kirk Hall via 
Public
Sent: Monday, September 11, 2017 6:01 AM
To: CA/Browser Forum Public Discussion List 
Subject: [EXTERNAL][cabfpub] Two amendments to Ballot 190

 
The proposer and endorsers are making two minor amendments to Ballot 190 as 
follows.
 
1) In BR 3.2.2.4.6 "Agreed-Upon Change to Website", the current draft Version 8 
still has the typo "Request Value" that crept in sometime around BR 1.4. It 
should be "Random Value". Accordingly, BR 3.2.2.4.6 in Ballot 190 is changed to 
read as follows:
 
3.2.2.4.6 Agreed-Upon Change to Website
 
Confirming the Applicant's control over the FQDN by confirming one of the 
following under the "/.well-known/pki-validation" directory, or another path 
registered with IANA for the purpose of Domain Validation, on the Authorization 
Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port:
 
1.  The presence of Required Website Content contained in the content of a 
file. The entire Required Website Content MUST NOT appear in the request used 
to retrieve the file or web page, or
 
2.  The presence of the Request Token orRequest Random Value contained in 
the content of a file where the Request Token or Random Value MUST NOT appear 
in the request. ***
 
2) In Version 8 of BR 3.2.2.4.7, "DNS Change", the current language says:
 
"Confirming the Applicant's control over the FQDN by confirming the presence of 
a Random Value or Request Tokenfor either in a DNS CNAME, TXT or CAA record for 
either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that 
is prefixed with a label that begins with an underscore character." 
 
Note that "for either" appears twice in the sentence, and we think the first 
occurrence should be deleted. Accordingly, BR 3.2.2.4.7 in Ballot 190 is 
changed to read as follows:
 
3.2.2.4.7  DNS Change
Confirming the Applicant's control over the FQDN by confirming the presence of 
a Random Value or Request Tokenfor either in a DNS CNAME, TXT or CAA record for 
either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that 
is prefixed with a label that begins with an underscore character.
 
Voting on Ballot 190 will begin tomorrow, and the text has been changed as 
shown above.
***
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Kirk Hall via 
Public
Sent: Tuesday, September 5, 2017 10:52 AM
To: CA/Browser Forum Public Discussion List 
Subject: [EXTERNAL][cabfpub] Ballot 190 - Discussion Period is starting
 
As agreed on our CABF teleconference last week, we are starting the formal 
discussion period for Ballot 190 (in this case, v8).  I have attached the 
ballot in two formats and in three modes.
 
The title of the actual ballot to be voted on uses all capital letters “BALLOT 
190 v8 (9-5-2017)”.  I also attach a version that includes some explanatory 
comments, and a “clean” version showing how the BRs will read if Ballot 190 v8 
is adopted “Ballot 190 v8 (9-5-2017) (showing BRs if adopted)”.
 
The discussion period ends Sept. 12 at 18:00 UTC, and the voting period runs 
Sept. 12-19.
 
This version 8 is based on the prior version 7, but includes a limited number 
of changes as outlined in emails among me, Ryan, and Doug on Aug. 29-30. 
 
We are almost there!  Thanks to everyone who has worked on this effort over the 
past two years.  Assuming Ballot 190 passes, the Validation Working Group can 
then start work on further amendments as outlined in my prior emails.
 

___
Public mailing list
Public@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, 

Re: [cabfpub] Ballot 204: Forbid DTPs from doingDomain/IP Owners hip Validation

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd.  votes  “yes” on Ballot 204.

  Li-Chun Chen
 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Gervase Markham 
via Public
Sent: Monday, June 26, 2017 8:18 AM
To: CABFPub 
Subject: [cabfpub] Ballot 204: Forbid DTPs from doing Domain/IP Ownership 
Validation

 
Ballot 204: Forbid DTPs from doing Domain/IP Ownership Validation
Purpose of Ballot: At the moment, CAs are permitted to delegate the process of 
domain and IP address validation. However, permitting such delegations is 
problematic due to the way audits work - the auditing of such work may or may 
not be required and, if it is, those audit documents may not make it back to 
root programs for consideration. Although the audit situation also needs 
fixing, domain validation is an important enough component of a CA's core 
competencies that it seems wiser to remove it from the larger problem and 
forbid its delegation. The purpose of this ballot is to ensure that CAs or 
their Affiliates are always the ones performing domain/IP address ownership 
validation for certificates that CA is responsible for.
The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Mike Reilly of Microsoft:
-- MOTION BEGINS -- 

This motion modifies the Baseline Requirements.

 

0) In section 1.6.1, augment the definition of "Delegated Third Party" as 
follows:

Delegated Third Party: A natural person or Legal Entity that is not the CA, and 
whose activities are not within the scope of the appropriate CA audits, but is 
authorized by the CA to assist in the Certificate Management Process by 
performing or fulfilling one or more of the CA requirements found herein.
1) In section 1.3.2, replace the following sentence: 

"The CA MAY delegate the performance of all, or any part, of Section 3.2 
requirements to a Delegated Third Party, provided that the process as a whole 
fulfills all of the requirements of Section 3.2."

 

with:

 

"With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the 
performance of all, or any part, of Section 3.2 requirements to a Delegated 
Third Party, provided that the process as a whole fulfills all of the 
requirements of Section 3.2." 

 

2) In sections 3.2.2.4, replace the paragraph beginning "The CA SHALL confirm 
that" with the following:

 

"The CA SHALL confirm that, as of the date the Certificate issues, the CA has 
validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate 
using at least one of the methods listed below, or is within the Domain 
Namespace of a Fully-Qualified Domain Name (FQDN) that has been validated using 
at least one of the methods listed below (not including the method defined in 
section 3.2.2.4.8)."

 

3) In section 3.2.2.4.6, remove the words "or Delegated Third Party".

 

4) In section 3.2.2.4.11 (if still present in the text at the time the ballot 
passes), replace the following text:

 

"either the CA or a Delegated Third Party"

 

with:

 

"the CA"

 

5) In section 8.4, remove the paragraph beginning: "If a Delegated Third Party 
is not currently audited...".

 

6) In section 8.4, replace the following text:

 

"If the CA is not using one of the above procedures and the Delegated Third 
Party is not an Enterprise RA, then"

 

with:

 

"For Delegated Third Parties which are not Enterprise RAs, ".
-- MOTION ENDS --
 
The procedure for approval of this Final Maintenance Guideline ballot is as 
follows:
 
BALLOT 204
Status: Final Maintenance Guideline
Start time (23:00 UTC)
End time (23:00 UTC)

Discussion (7 to 14 days)
27 June
4 July

Vote for approval (7 days)
4 July
11 July

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Upon filing of Review Notice by Chair
30 days after filing of Review Notice by Chair

 
From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines.  Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).
 
Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a 

Re: [cabfpub] Ballot 201 - .onion Revisions

[realsky(CHT) via Public]

Chunghwa Telecom  votes Abstain.


   
Li-Chun Chen
 
 
From: Public  on behalf of Ben Wilson via Public 

Reply-To: CA/Browser Forum Public Discussion List 
Date: Thursday, 25 May, 2017 at 15:50 
To: CABFPub 
Cc: Ben Wilson 
Subject: [cabfpub] Ballot 201 - .onion Revisions

 

Ballot 201 - .Onion Revisions 
This ballot is meant to cure any potential problems with Ballot 198, which may 
have been invalid due to ambiguities in what was presented to the Forum for 
vote. This Ballot 201 attempts to clarify Appendix F of the EV Guidelines 
concerning the Tor Service Descriptor Hash extension and that inclusion of the 
extension in the TBSCertificate is required. 
The following motion has been proposed by Jeremy Rowley of DigiCert and 
endorsed by Ryan Sleevi of Google and Wayne Thayer of GoDaddy to introduce new 
Final Maintenance Guidelines for the "Guidelines for the Issuance and 
Management of Extended Validation Certificates" (EV Guidelines). 
Attached is a PDF with a redline showing how Appendix F of the current EV 
Guidelines will be amended.
-- MOTION BEGINS -- 
Part 1: 
The CA/Browser Forum, recognizing that Ballot 198 did not include a redline 
version against the current Final Maintenance Guidelines, thereby constitutes 
an invalid Ballot. As a consequence, the Forum agrees that the changes shall 
not be made to the appropriate Final Maintenance Guideline, and as such, no IPR 
Review Notice is in force for Ballot 198: 
Part 2: 
Revise Appendix F, Section 1, to read as follows: 
Appendix F – Issuance of Certificates for .onion Domain Names 
A CA may issue an EV Certificate with .onion in the right-most label of the 
Domain Name provided that issuance complies with the requirements set forth in 
this Appendix: 
1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) 
The CA MUST include the CAB Forum Tor Service Descriptor Hash in the 
TBSCertificate to convey hashes of keys related to .onion addresses. The CA 
MUST include the Tor Service Descriptor Hash extension using the following 
format: 
cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 } 
SEQUENCE ( 1..MAX ) of TorServiceDescriptorHash 
TorServiceDescriptorHash:: = SEQUENCE { 
onionURI UTF8String 
algorithm AlgorithmIdentifier 
subjectPublicKeyHash BIT STRING 
} 
Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) 
performed over the DER-encoding of an ASN.1 SubjectPublicKey of the .onion 
service and SubjectPublicKeyHash is the hash output. 
--Motion Ends-- 
The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement): 
BALLOT 201 Status: Final Maintenance GuidelineStart time (22:00 
UTC)   End time (22:00 UTC) 
Discussion (7 to 14 days)   
May 25, 2017June 1, 2017 
Vote for approval (7 days)  
   June 1, 2017  June 8, 2017 
If a vote of the Forum approves this ballot, the Chair will initiate a 30-day 
IPR Review Period by sending out an IPR Review Notice. 
After 30 days of announcing the IPR Review period by the Chair:
If Exclusion Notice(s) are filed, this ballot approval is rescinded and a PAG 
will be created; or If no Exclusion Notices are filed, this ballot becomes 
effective at end of the IPR Review Period. From Bylaw 2.3: If the Draft 
Guideline Ballot is proposing a Final Maintenance Guideline, such ballot will 
include a redline or comparison showing the set of changes from the Final 
Guideline section(s) intended to become a Final Maintenance Guideline, and need 
not include a copy of the full set of guidelines. Such redline or comparison 
shall be made against the Final Guideline section(s) as they exist at the time 
a ballot is proposed, and need not take into consideration other ballots that 
may be proposed subsequently, except as provided in Bylaw Section 2.3(j). 
Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/ 
In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor. Quorum is half of the number of 
currently active Members, which is the average number of Member organizations 
that 

Re: [cabfpub] Ballot 200 - Amendment of Bylaws to add Code of Co nduct

[realsky(CHT) via Public]

 
Chunghwa Telecom Co., Ltd.  votes “Yes”  for Ballot 200 - Amendment of Bylaws 
to add Code of Conduct


 Li-Chun Chen

 
Van: Public [mailto:public-boun...@cabforum.org]Namens Virginia Fournier via 
Public
Verzonden: dinsdag 16 mei 2017 22:55
Aan: CA/Browser Forum Public Discussion List
CC: Virginia Fournier
Onderwerp: [cabfpub] Ballot 200 - Amendment of Bylaws to add Code of Conduct

 
 
Ballot 200

 

Purpose of Ballot:  To amend the CAB Forum Bylaws to add a Code of Conduct.

 

The following motion has been proposed by Virginia Fournier of Apple and 
endorsed by Gervase Markham of Mozilla and Tarah Wheeler of Symantec.

 

—MOTION BEGINS—

 

1.  A new Section 6.4 will be added to the Bylaws of the CAB Forum, and will 
read in its entirety as follows:

 

“Section 6.4

 

All Members shall abide by the CAB Forum Code of Conduct, which is attached to 
these Bylaws as Exhibit C.”

 

2.  A new Exhibit C will be added to the Bylaws, and will read in its entirety 
as follows:

 

“Exhibit C




CAB Forum Code of Conduct (the “Code")

The CAB Forum (the “Forum") is comprised of a global group of professionals 
with differences in language, skills, expertise, experience, and backgrounds.  
To maintain a professional and productive environment, it is necessary for 
Members of the Forum to follow the letter and spirit of this Code.  This Code 
applies to all official Forum activities, such as meetings, teleconferences, 
mailing lists, conferences, and other Forum functions.  The Forum is committed 
to maintaining a professional and respectful environment.

All Member representatives are expected to behave in a collegial and 
professional manner in accordance with this Code.  Members will familiarize 
their representatives with this Code and require them to comply with the letter 
and spirit of this Code.

I.  Conduct.  The Forum is committed to providing a friendly, safe, and 
welcoming environment for all, regardless of gender, gender identity and 
expression, sexual orientation, disability, personal appearance, body size, 
race, ethnicity, age, religion, nationality, or other similar characteristic.  
The Forum recognizes and appreciates that its participants have diverse 
languages, backgrounds, experience, and expertise, and expects that all 
participants will be treated with respect by all other participants.

(a)  In connection with official Forum activities, all Forum participants shall:
Be polite, kind, and courteous to other participants, refraining from insulting 
remarks on the perceived intelligence or ability of others.Treat fellow Forum 
participants with respect, professionalism, courtesy, and reasonableness.  
Respect that people have differences of opinion, and that there is seldom 
unanimous agreement on a single “correct" answer.  Be willing to compromise and 
agree to disagree.  



(b)  In connection with official Forum activities, all Forum participants shall 
refrain from conduct such as:  
Threatening violence towards anyone.  Discriminating against anyone on the 
basis of personal characteristics or group membership.Harassing or bullying 
anyone verbally, physically, or sexually.Launching barbs at others.  [Note:  a 
“barb” is an obviously or openly unpleasant or carping remark.]Touching another 
person in a physically inappropriate way. Deliberately intimidating or stalking 
another person (in-person, online, or by other means).Inappropriately 
disrupting or impeding official Forum events, including meetings, talks, and 
presentations.  For purposes of this Code, "inappropriate disruption" would 
include aggressive, violent, and abusive conduct that prevents an official 
Forum event from occurring or proceeding.Spamming, trolling, flaming, baiting, 
and other similar behavior inappropriately directed towards an 
individual.Advocating for, or encouraging, any of the above behavior.



(c)  All Forum participants should promote the rules of this Code and take 
action to bring discussions back into compliance with the Code whenever 
violations are observed.




(d)  Forum participants should stick to ideological, conceptual discussions and 
avoid engaging in offensive or sensitive personal discussions, particularly if 
they're off-topic; such personal discussions can lead to unnecessary arguments, 
hurt feelings, and damaged trust. 




II.  Moderation.  These are the policies for upholding the Code.




(a) Resist the urge to be defensive.  Remember that it's your responsibility to 
clearly communicate your message to your fellow participants. Everyone wants to 
get along and we are all in the Forum first and foremost because we want to 
talk about standards and everything that involves. Other participants will be 
eager to assume good intent and forgive as long as you have earned their trust.

 

(b)  Participants should inform the Chair, Vice Chair, and/or a Working Group 
Chair immediately if they feel they have been, or are being, harassed or made 
uncomfortable by a 

[cabfpub] Ballot 197 – Effective Date of Ballot 193 Provisions

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. Votes Yes 

Li-Chun

-Original message-

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Wednesday, April 19, 2017 8:03 PM
To: Kirk Hall via Public 
Cc: Kirk Hall 
Subject: [cabfpub] Ballot 197 – Effective Date of Ballot 193 Provisions

Ballot 197 – Effective Date of Ballot 193 Provisions

Recent Ballot 193 reduced the maximum period for certificates and for reuse of 
vetting data for DV and OV certificates from 39 months to 825 days.  The 
effective date for reducing the maximum validity period of certificates was 
specified as March 1, 2018, but no effective date was specified for when the 
reduction of the maximum period for reuse of vetting data becomes effective.

It was the intention of the authors of Ballot 193 that the effective date for 
reducing the maximum period for reuse of vetting data under BR 4.2.1 would also 
be March 1, 2018.  This ballot is intended to clarify that intention.  The 
ballot also makes these changes retroactive to the effective date of Ballot 193 
so there is no gap period.

Ballot 193 is in the Review Period (which will end on April 22, 2017), and has 
not yet taken effect.  Bylaw 2.3 states that Ballots should include a “redline 
or comparison showing the set of changes from the Final Guideline section(s) 
intended to become a Final Maintenance Guideline” and that “[s]uch redline or 
comparison shall be made against the Final Guideline section(s) as they exist 
at the time a ballot is proposed”.

To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1 will 
be presented two ways: (1) a comparison of the changes to BR 4.2.1 as it 
existed before Ballot 193 (which is as BR 4.2.1 exists at this time this ballot 
is proposed), and also (2) a comparison of the changes to BR 4.2.1 as it will 
exist after the Review Period for Ballot 193 is completed (assuming no 
Exclusion Notices are filed).

The following motion has been proposed by Chris Bailey of Entrust Datacard and 
endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to introduce 
new Final Maintenance Guidelines for the "Baseline Requirements Certificate 
Policy for the Issuance and Management of Publicly-Trusted Certificates" 
(Baseline Requirements) and the "Guidelines for the Issuance and Management of 
Extended Validation Certificates" (EV Guidelines).

-- MOTION BEGINS --

Ballot Section 1

BR 4.2.1 is amended to read as follows:

[Ballot amendments shown against BR 4.2.1 as it currently exists without the 
changes adopted in Ballot 193]

BR 4.2.1. Performing Identification and Authentication Functions

The certificate request MAY include all factual information about the Applicant 
to be included in the Certificate, and such additional information as is 
necessary for the CA to obtain from the Applicant in order to comply with these 
Requirements and the CA’s Certificate Policy and/or Certification Practice 
Statement. In cases where the certificate request does not contain all the 
necessary information about the Applicant, the CA SHALL obtain the remaining 
information from the Applicant or, having obtained it from a reliable, 
independent, third‐party data source, confirm it with the Applicant. The CA 
SHALL establish and follow a documented procedure for verifying all data 
requested for inclusion in the Certificate by the Applicant.

Applicant information MUST include, but not be limited to, at least one 
Fully‐Qualified Domain Name or IP address to be included in the Certificate’s 
SubjectAltName extension.

Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY 
use the documents and data provided in Section 3.2 to verify certificate 
information, provided that: the CA obtained the data or document from a source 
specified under Section 3.2 no more than thirty‐nine (39) months prior to 
issuing the Certificate.

(1) Prior to March 1, 2018, the CA obtained the data or document from a source 
specified under Section 3.2 no more than 39 months prior to issuing the 
Certificate; and

(2) On or after March 1, 2018, the CA obtained the data or document from a 
source specified under Section 3.2 no more than 825 days prior to issuing the 
Certificate.

The CA SHALL develop, maintain, and implement documented procedures that 
identify and require additional verification activity for High Risk Certificate 
Requests prior to the Certificate’s approval, as reasonably necessary to ensure 
that such requests are properly verified under these Requirements.

If a Delegated Third Party fulfills any of the CA’s obligations under this 
section, the CA SHALL verify that the process used by the Delegated Third Party 
to identify and further verify High Risk Certificate Requests provides at least 
the same level of assurance as the CA’s own processes.


[Ballot amendments shown against BR 4.2.1 as it existed after Ballot 193 was 
approved]

BR 4.2.1. Performing Identification and 

Re: [cabfpub] Ballot 194 - Effective Date of Ballot 193 Provisio ns is in the VOTING period (ends April 16)

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. Votes Yes

Li-Chun

-Original message-
From:Curt Spann via Public
To:CA/Browser Forum Public Discussion List
Cc:Curt Spann
Date: Sat, 15 Apr 2017 09:01:14
Subject: [外部郵件] Re: [cabfpub] Ballot 194 - Effective Date of Ballot 193 
Provisions is in the VOTING period (ends April 16)
Apple votes ABSTAIN.

Curt

On Apr 9, 2017, at 4:29 PM, Kirk Hall via Public  wrote:
Reminder: Ballot 194 -  Effective Date of Ballot 193 Provisions is in the 
voting period (ends April 16)
 
Ballot 194 – Effective Date of Ballot 193 Provisions
 
Purpose of Ballot: Recent Ballot 193 reduced the maximum period for 
certificates and for reuse of vetting data for DV and OV certificates from 39 
months to 825 days.  The effective date for reducing the maximum validity 
period of certificates was specified as March 1, 2018, but no effective date 
was specified for when the reduction of the maximum period for reuse of vetting 
data becomes effective.
 
It was the intention of the authors of Ballot 193 that the effective date for 
reducing the maximum period for reuse of vetting data under BR 4.2.1 would also 
be March 1, 2018.  This ballot is intended to clarify that intention.  The 
ballot also makes these changes retroactive to the effective date of Ballot 193 
so there is no gap period.
 
Ballot 193 is in the Review Period (which will end on April 22, 2017), and has 
not yet taken effect.  Bylaw 2.3 states that Ballots should include a “redline 
or comparison showing the set of changes from the Final Guideline section(s) 
intended to become a Final Maintenance Guideline” and that “[s]uch redline or 
comparison shall be made against the Final Guideline section(s) as they exist 
at the time a ballot is proposed”.
 
To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1 will 
be presented two ways: (1) a comparison of the changes to BR 4.2.1 as it 
existed before Ballot 193 (which is as BR 4.2.1 exists at this time this ballot 
is proposed), and also (2) a comparison of the changes to BR 4.2.1 as it will 
exist after the Review Period for Ballot 193 is completed (assuming no 
Exclusion Notices are filed).
 
The following motion has been proposed by Chris Bailey of Entrust Datacard and 
endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to introduce 
new Final Maintenance Guidelines for the "Baseline Requirements Certificate 
Policy for the Issuance and Management of Publicly-Trusted Certificates" 
(Baseline Requirements) and the "Guidelines for the Issuance and Management of 
Extended Validation Certificates" (EV Guidelines).
 
-- MOTION BEGINS --
 
Ballot Section 1
 
BR 4.2.1 is amended to read as follows:
 
[Ballot amendments shown against BR 4.2.1as it currently exists without the 
changes adopted in Ballot 193]
 
BR 4.2.1. Performing Identification and Authentication Functions
 
The certificate request MAY include all factual information about the Applicant 
to be included in the Certificate, and such additional information as is 
necessary for the CA to obtain from the Applicant in order to comply with these 
Requirements and the CA’s Certificate Policy and/or Certification Practice 
Statement. In cases where the certificate request does not contain all the 
necessary information about the Applicant, the CA SHALL obtain the remaining 
information from the Applicant or, having obtained it from a reliable, 
independent, third‐party data source, confirm it with the Applicant. The CA 
SHALL establish and follow a documented procedure for verifying all data 
requested for inclusion in the Certificate by the Applicant.
 
Applicant information MUST include, but not be limited to, at least one 
Fully‐Qualified Domain Name or IP address to be included in the Certificate’s 
SubjectAltName extension.
 
Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY 
use the documents and data provided in Section 3.2 to verify certificate 
information, provided that: the CA obtained the data or document from a source 
specified under Section 3.2 no more than thirty‐nine (39) months prior to 
issuing the Certificate.
 
(1) Prior to March 1, 2018, the CA obtained the data or document from a source 
specified under Section 3.2 no more than 39 months prior to issuing the 
Certificate; and
 
(2) On or after March 1, 2018, the CA obtained the data or document from a 
source specified under Section 3.2 no more than 825 days prior to issuing the 
Certificate. 
 
The CA SHALL develop, maintain, and implement documented procedures that 
identify and require additional verification activity for High Risk Certificate 
Requests prior to the Certificate’s approval, as reasonably necessary to ensure 
that such requests are properly verified under these Requirements.
 
If a Delegated Third Party fulfills any of the CA’s obligations under this 
section, the CA SHALL verify that the process used 

Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Base line Requirements

[realsky(CHT) via Public]

 Chunghwa Telecom Co., Ltd. votes Yes to ballot 189.

  Li-Chun Chen


-Original message-
From:Peter Miškovič via Public
To:CA/Browser Forum Public Discussion List
Cc:Peter Miškovič
Date: Thu, 13 Apr 2017 22:55:30
Subject: [外部郵件] Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of 
Baseline Requirements
Disig votes „YES“.
 
Regards
Peter
 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Dimitris 
Zacharopoulos via Public
Sent: Wednesday, April 5, 2017 9:47 AM
To: public@cabforum.org
Cc: Dimitris Zacharopoulos 
Subject: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline 
Requirements

 

After the recent discussion, the ballot is now updated with simpler language. 
Voting starts tomorrow April 6th.

Dimitris.


Ballot 189 - Amend Section 6.1.7 of Baseline Requirements
The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert
Background: 
Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys 
MUST NOT be used to sign end-entity certificates, with some exceptions. It is 
unclear if this exception list includes end-entity certificates with EKU 
id-kp-timeStamping. This ballot attempts to clarify two things: 
that it affects Root Keys in a hierarchy that issues SSL Certificates and that 
it does not include time stamping certificates in the exception list. It also 
clears the exception language for 1024-bit RSA Subscriber Certificates and 
testing products with Certificates issued by a Root.
-- MOTION BEGINS -- 
Current section 6.1.7 
Root CA Private Keys MUST NOT be used to sign Certificates except in the 
following cases:
Self-signed Certificates to represent the Root Certificate itself; Certificates 
for Subordinate CAs and Cross Certificates; Certificates for infrastructure 
purposes (e.g. administrative role certificates, internal CA operational device 
certificates, and OCSP Response verification Certificates);Certificates issued 
solely for the purpose of testing products with Certificates issued by a Root 
CA; andSubscriber Certificates, provided that: The Root CA uses a 1024-bit RSA 
signing key that was created prior to the Effective Date;The Applicant’s 
application was deployed prior to the Effective Date; The Applicant’s 
application is in active use by the Applicant or the CA uses a documented 
process to establish that the Certificate’s use is required by a substantial 
number of Relying Parties;The CA follows a documented process to determine that 
the Applicant’s application poses no known security risks to Relying 
Parties;The CA documents that the Applicant’s application cannot be patched or 
replaced without substantial economic outlay.The CA signs the Subscriber 
Certificate on or before June 30, 2016; and The notBefore field in the 
Subscriber Certificate has a date on or before June 30, 2016Proposed section 
6.1.7 
Private Keys corresponding to Root Certificates MUST NOT be used to sign 
Certificates except in the following cases:
Self-signed Certificates to represent the Root CA itself; Certificates for 
Subordinate CAs and Cross Certificates; Certificates for infrastructure 
purposes (administrative role certificates, internal CA operational device 
certificates)Certificates for OCSP Response verification; These changes become 
Effective 30 days after the ballot passes.
-- MOTION ENDS -- 
The procedure for this ballot is as follows (exact start and end times may be 
adjusted to comply with applicable Bylaws and IPR Agreement):
BALLOT 189 Status: Amend BR 6.1.7 
Start time (22:00 UTC)
End time (22:00 UTC) 

Discussion (7 days) 
30 March 2017 
6 April 2017 

Vote for approval (7 days) 
6 April 2017 
13 April 2017 

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days)
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.
Upon filing of Review Notice by Chair
30 days after filing of Review Notice by Chair


From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines. Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j). 
Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 

Re: [cabfpub] Ballot 196: Define "Audit Period"

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. votes Yes to ballot 196 .

   Li-Chun Chen




 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Gervase Markham 
via Public
Sent: Monday, April 3, 2017 2:06 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 196: Define "Audit Period"

 
Ballot 196 - Define "Audit Period"
Purpose of Ballot: It appears that CAs are sometimes confused by the phrase 
Audit Period. This ballot adds a definition of that phrase to the BRs, in the 
hope of heading off any further misunderstandings.
The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jody Cloutier of Microsoft:


-- MOTION BEGINS -- 
Add the following definition to section 1.6.1 of the Baseline Requirements:



Audit Period: In a period-of-time audit, the period between the first day 
(start) and the last day of operations (end) covered by the auditors in their 
engagement. (This is not the same as the period of time when the auditors are 
on-site at the CA.) The coverage rules and maximum length of audit periods are 
defined in section 8.1.
-- MOTION ENDS -- 



The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):
 
BALLOT 196
Status: Final Maintenance Guideline
Start time (23:00 UTC)
End time (23:00 UTC)

Discussion (7 to 14 days)
3rd April
10th April

Vote for approval (7 days)
10th April
17th April

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Upon filing of Review Notice by Chair
30 days after filing of Review Notice by Chair

 
From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines.  Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).
 
Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here:https://cabforum.org/members/
In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.





___

Public mailing list

Public@cabforum.org

https://cabforum.org/mailman/listinfo/public

___
Public mailing list
Public@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.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Naming rules

[realsky(CHT) via Public]

Dear Kirk,Ben,Dimitris and Jeremy,

 Good morning. Although most of the time of CP reviewing WG today will 
focus on the ballot Dimitris proposed. Would you mind giving me thirty minutes 
to present "Amendment of  SSL BR 7.1.4.2.2 :Add Section K for existing PKI" 
propsed by Wen-Cheng Wang ? If time is not enough, it may take up the 
Validation WG discussion session. I also hope Peter have time to see and 
support our ballot.

Sincerely Yours,

  Li-Chun Chen



-Original message-
From:Gervase Markham 
To:王文正 ,CA/Browser Forum Public Discussion List 

Cc:陳立群 
Date:Tue, 21 Mar 2017 06:24:18
Subject:[外部郵件] Re: [cabfpub] Naming rules

On 19/03/17 11:18, 王文正 wrote:
> Thanks for your positive feedback. I am very sorry for our late in
> reply. We carefully examined and thought about how to propose minimum
> changes to the BRs to embrace subject naming rules of existing PKI. 

Thank you for your proposal. Having helped guide the conversation to
this point, I'm not the right person to assess the wisdom of what you
propose; I will leave that to others. :-)

Gerv


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


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [外部郵件] Re: Draft Agenda for F2F meeting Research Triangle Park, NC - March 21-23

[realsky(CHT) via Public]

Since I needed an invitation letter to join F2F meeting, so I remeber Dean told 
me the meeting agenda is  confirmed one week or two weeks before the F2F 
meeting. The agenda was copied from Redmond meeting with little modification. I 
agree with  Ryan' and Peter's suggestion. It is time for Kirk to collet 
suggestion to arrange the new meeting agenda and update the Wiki.  


   As for Redmond's meeting, my topic about changing to browser UI for Subject 
DN of EV SSL Certificate has not yet be resolved. 

  It seems there is no further progress after I and Dimitris file a bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=1308755
https://bugzilla.mozilla.org/show_bug.cgi?id=500333

   As for suggestion to Microsft , it was post by Dimitris, thanks for him. 
Because that mail was in my office computer, it is National holiday in Tawian, 
If Dimitris read the mail, please tell us the status.

 Li-Chun Chen
 Chunghwa Telecom 



-Original message-
From:Ryan Sleevi via Public
To:CA/Browser Forum Public Discussion List
Cc:Ryan Sleevi
Date: Mon, 27 Feb 2017 04:48:43
Subject: [外部郵件] Re: [cabfpub] Draft Agenda for F2F meeting Research Triangle 
Park, NC - March 21-23


On Sun, Feb 26, 2017 at 12:32 PM, Peter Bowen via Public  
wrote:
Kirk,

It looks like Day 2 is mostly copied from the Redmond F2F agenda.  I don’t have 
an intention of repeating the topics I lead previously unless there are new 
things to cover.

Thanks,
Peter

Indeed, I was just about to suggest that for several of the other (non-Peter) 
topics, unless there's something new to cover - and ideally, discussed on the 
list prior - we shouldn't schedule those items either.

I also note that Day 1 limits the discussion of "Future Thoughts" to 45 
minutes, although I would suggest and suspect that this is a line of discussion 
that might easily occupy an hour and a half, if not more, as members work 
through understanding the various goals of the suggestions, and then try to map 
out possible paths towards those goals by articulating concerns and constraints 
that they may have.

If I might, borrowing from an "unconference" like approach, might I suggest 
that Day 1 gather the "Future Thoughts" as scheduled, and have a (brief) 
discussion and presentation of those future thoughts (also as scheduled), but 
we make use of time of Day 2 to actually explore and articulate how to get 
there. This would allow time for members to socialize and understand the items 
raised on Day 1, and then come back on Day 2 with a better sense of concerns 
and directions. I suspect this will allow us a much more productive discussion 
and figuring out next steps.

Alternatively, we could consider gathering those discussion items now, prior to 
the meeting. Day 1 can include a summary of the items and themes and allow time 
for basic clarification, and then we can dedicate several discussion slots on 
Day 2 to explore those items identified as either controversial or as shared 
interest, so that we can more rapidly make progress. This might make it more 
productive then, say, if I were to request several agenda slots for what Google 
considers as high importance and future direction.

Another agenda item I might suggest, and I'm happy to be the 'discussion 
leader' because of it, is the question about the role and relationship of the 
Forum. Judging by the reactions to Ballot 185, and from various questions that 
have come in on the questions@ list which have sparked debate, perhaps it's 
worth revisiting how different members see the role and scope of the Forum, so 
that we can better understand each other's objectives and needs.

There also appears to be one or two agenda items previously discussed, but 
missing. One was a retrospective discussion about the SHA-1 deprecation, with 
input from various Browsers, to help capture and crystalize the challenges and 
to examine some of the lessons learned from the SHA-1 exception process. 
Another was more targeted towards the technical members of the Forum, which is 
related to workflow management (GitHub, production of PDFs, etc), with the goal 
of making it less onerous on Ben to manage that. I realize that the Forum has 
historically conducted a 'single track' meeting schedule, there may be 
opportunity during the WG day to run that exploration in parallel, if there's 
space available. My instinct is that there may be sufficient non-overlap in 
members as the Governance discussions, but as the agenda for Day 2 shapes out, 
there may be an opportunity there instead.

 
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public




本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains 

[cabfpub] Reply: Ballot 185 (Revised) - Limiting the Lifetime of Certificates

[realsky(CHT) via Public]

Chunghwa Telecom votes Abstain.

 
 Li-Chun Chen



From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi 
via Public
Sent: 13 February 2017 19:18
To: CABFPub 
Cc: Ryan Sleevi 
Subject: [cabfpub] Ballot 185 (Revised) - Limiting the Lifetime of Certificates

 

Pursuant to the consensus on 
https://cabforum.org/pipermail/public/2017-February/009530.html about the 
nature of changes during the discussion period, and the request from Gervase on 
https://cabforum.org/pipermail/public/2017-February/009618.html to adjust what 
represents the Baseline agreement, this adjusts the effective date from 1 April 
to 24 August. While individual programs may choose to enact or enforce 
requirements prior to that, as the Baseline Requirements capture the effective 
point of common agreement of the bare minimum security levels, it seems 
appropriate that this Ballot accurately reflect that.

 

 

Ballot 185 - Limiting the Lifetime of Certificates

 

The following motion has been proposed by Ryan Sleevi of Google, Inc and 
endorsed by Josh Aas of ISRG and Gervase Markham of Mozilla to introduce new 
Final Maintenance Guidelines for the "Baseline Requirements Certificate Policy 
for the Issuance and Management of Publicly-Trusted Certificates" and the 
"Guidelines for the Issuance and Management of Extended Validation Certificates"

 

-- MOTION BEGINS --

Modify Section 6.3.2 of the "Baseline Requirements Certificate Policy for the 
Issuance and Management of Publicly-Trusted Certificates" as follows:

 

Replace Section 6.3.2, which reads as follows:

"""

6.3.2. Certificate Operational Periods and Key Pair Usage Periods

 

Subscriber Certificates issued after the Effective Date MUST have a Validity 
Period no greater than 60 months. 

Except as provided for below, Subscriber Certificates issued after 1 April 2015 
MUST have a Validity Period 

no greater than 39 months. 

 

Until 30 June 2016, CAs MAY continue to issue Subscriber Certificates with a 
Validity Period greater than 39 

months but not greater than 60 months provided that the CA documents that the 
Certificate is for a system or 

software that:   

(a) was in use prior to the Effective Date;  

(b) is currently in use by either the Applicant or a substantial number of 
Relying Parties;  

(c) fails to operate if the Validity Period is shorter than 60 months; 

(d) does not contain known security risks to Relying Parties; and  

(e) is difficult to patch or replace without substantial economic outlay

"""

 

with the following text:

"""

6.3.2. Certificate Operational Periods and Key Pair Usage Periods

 

Subscriber Certificates issued on or after 24 August 2017 MUST NOT have a 
Validity Period greater than three hundred and ninety-eight (398) days.

 

Subscriber Certificates issued prior to 24 August 2017 MUST NOT have a Validity 
Period greater than thirty-nine (39) months.

"""

 

Modify Section 9.4 of the "Guidelines for the Issuance and Management of 
Extended Validation Certificates" as follows:

 

Replace Section 9.4, which reads as follows:

"""

9.4. Maximum Validity Period For EV Certificate

 

The validity period for an EV Certificate SHALL NOT exceed twenty seven months. 
It is RECOMMENDED that EV

Subscriber Certificates have a maximum validity period of twelve months.

"""

 

with the following text:



9.4 Maximum Validity Period for EV Certificate

 

EV Certificates issued on or after 24 August 2017 MUST NOT have a Validity 
Period greater than three hundred and ninety-eight (398) days.

 

EV Certificates issued prior to 24 August 2017 MUST NOT have a Validity Period 
greater than twenty seven (27) months.

"""

-- MOTION ENDS --

 

Ballot 185 - Limiting the Lifetime of Certificates

Status: Final Maintenance Guideline

 

Review Period:

Start Time: 2017-02-10 00:00:00 UTC

End Time: 2017-02-17 00:00:00 UTC

 

Vote for Approval:

Start Time: 2017-02-17 00:00:00 UTC

End Time: 2017-02-24 00:00:00 UTC

 

Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.

 

A vote in favor of the ballot must indicate a clear 'yes' in the response. A 
vote against must indicate a clear 'no' in the response. A vote to abstain must 
indicate a clear 'abstain' in the response. Unclear responses will not be 
counted. The latest vote received from any representative of a voting Member 
before the close of the voting period will be counted. Voting Members are 
listed here: https://cabforum.org/members/

 

In order for the ballot to be adopted, two thirds or more of the votes cast by 
Members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.



本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains 
confidential information and may be legally privileged. If you 

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certif icates

[realsky(CHT) via Public]

-Original message-
From:Ryan Sleevi via Public
To:Geoff Keating
Cc:Ryan Sleevi,CA/Browser Forum Public Discussion 
List
Date: Sat, 04 Feb 2017 09:37:51
Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates


On Fri, Feb 3, 2017 at 4:35 PM, Geoff Keating  wrote:
Weren’t most of the long-lived certificates that caused problems those issued 
before the current limit of ~3 years?  

Nope, not in our experience. I'm hoping Jody can share his graph, but much of 
our 'breakage' experience was from sites where the CA waited to stop issuing 
SHA-1 certs until it was explicitly forbidden - that is, they did not even 
default to SHA-256, or made it considerably *more* difficult for their 
customers to obtain SHA-256 signed certs

===>
Ryan, You said you hope Jody can share his graph. Do you mean the discussion in 
last Fall Redmond F2F meeting as the minute below in Mozilla's news section?
https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Mozilla

Side note based on comments from Microsoft
•MS shows 20M sites with SHA-1 where as FF counts traffic
•Why do this now vs. waiting a year, that’s the rush?
•Wants to work with other browsers on timing. Google might have different pain 
thresholds. Goal is to figure out we get proper user feedback and that 
stakeholders are not screaming.


The no-SHA-1 requirement came in force January 2016 - not 2015. We passed the 
Ballot in 2015, following Microsoft's announced deprecation in Nov 12, 2013 - 
https://technet.microsoft.com/en-us/library/security/2880823.aspx

==>
The SHA-1 sunset ballot was passed on 16 October 2014, not 2015. 
Please see 
https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/ 

I think most CAs offer their cusomers to migrate SHA-1 SSL certificates to SHA 
256 SSL certificates for free. Try their best to call out and e-mail to the 
customers to encourage them.   

Sincerely Yours,

  Li-Chun Chen
 Chunghwa Telecom Co. Ltd.



___
Public mailing list
Public@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.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] An inconsistency for "Issuing CA" in BYLAWS and SSL BR

[realsky(CHT) via Public]

For survey Ballot 183, I found there is an inconsistency for "Issuing CA" in 
BYLAWS of The CA/Browser  Forum version 1.4 and SSL BR V1.4.2.
 
In BYLAWS of The CA/Browser  Forum version 1.4, 

2.1 Qualifying for Forum Membership
(a) CA/Browser Forum members shall meet at least one of the following criteria.
(1) Issuing CA: The member organization operates a certification authority that 
has a
current and successful WebTrust for CAs audit, or ETSI 102042 or ETSI 101456
audit report prepared by a properly-qualified auditor, and that actively issues
certificates to Web servers that are openly accessible from the Internet using a
browser created by a Browser member. Applicants that are not actively issuing
certificates but otherwise meet membership criteria may be granted Associate
Member status under Bylaw Sec. 3.1 for a period of time to be designated by the
Forum.


(2) Root CA: The member organization operates a certification authority that 
has a
current and successful WebTrust for CAs, or ETSI 102042 or ETSI 101456 audit
report prepared by a properly-qualified auditor, and that actively issues 
certificates to
subordinate CAs that, in turn, actively issue certificates to Web servers that 
are
openly accessible from the Internet using a browser created by a Browser member.
Applicants that are not actively issuing certificates but otherwise meet 
membership
criteria may be granted Associate Member status under Bylaw Sec. 3.1 for a 
period
of time to be designated by the Forum.


But in 1.6.1 Definitions of SSL Baseline Requirement Version 1.4.2,

Issuing CA: In relation to a particular Certificate, the CA that issued the 
Certificate. This could be either a
Root CA or a Subordinate CA. 


   


Sincerely Yours,


 Li-Chun Chen
 Chunghwa Telecom Co. Ltd.

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


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting has started on Ballot 183 – Amending the Bylaws to Clarify the Ballot Approval Process

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd.  votes “Yes”


Sincerely Yours,

 Li-Chun Chen
 Chunghwa Telecom Co. Ltd.


 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Kirk Hall via 
Public
Sent: 25. januar 2017 16:27
To: CA/Browser Forum Public Discussion List
Cc: Kirk Hall
Subject: [cabfpub] Voting has started on Ballot 183 _ Amending the Bylaws to 
Clarify the Ballot Approval Process

 
Voting has started on Ballo3 183, and continues through Tuesday, January 31, 
2017 at 22:00 UTC.  Please vote via the Public list.
 
Ballot 183 _ Amending the Bylaws to Clarify the Ballot Approval Process
 
The following motion has been proposed by Kirk Hall of Entrust, Inc. and 
endorsed by Virginia Fournier of Apple, Inc. and Chris Nalevanko of Amazon.com, 
Inc. to amend the CA/Browser Forum Bylaws (the ylaws_):
 
-- MOTION BEGINS _
 
In accordance with Section 6.1 of the Bylaws of the CA/Browser Forum (the 
orum_), the Bylaws are hereby amended as follows:

1.  Ballots Among Forum Members. Section 2.2 of the Bylaws is hereby amended to 
read in its entirety as follows: 

_2.2 General Provisions Applicable to all Ballots

The following rules will apply to all ballots, including Draft Guideline 
Ballots (defined in Section 2.3).

(a)  Only votes by Members shall be accepted.

(b)  Only one vote per Member company shall be accepted; representatives of 
corporate affiliates shall not vote.

(c)  A representative of any Member can call for a proposed ballot to be 
published for discussion and comment by the membership. Any proposed ballot 
needs two endorsements by other Members in order to proceed. The discussion 
period then shall take place for at least seven but no more than 14 calendar 
days before votes are cast.  The proposer of the ballot will designate the 
length of the discussion period, and each ballot shall clearly state the start 
and end dates and times (including time zone) for both the discussion period 
and the voting period.

(d) Upon completion of the discussion period, Members shall have exactly seven 
calendar days for voting, with the deadline clearly communicated in the ballot 
and sent via the Public Mail List. All voting will take place via the Public 
Mail List.   Votes not submitted to the Public Mail List will not be considered 
valid, and will not be counted for any purpose.

(e)  Members may vote yes, no, or abstain on a ballot.  Only votes that 
indicate a clear es_ or o_ response to the ballot question shall be 
considered (i.e. votes to abstain and votes that do not indicate a clear es_ 
or o_ response will not figure in the calculation of item (f), below).

(f)  Members fall into two categories: CAs (comprising issuing CAs and root 
CAs, as defined in the membership criteria) and browsers (as defined in the 
membership criteria). In order for the ballot to be adopted by the Forum, 
two-thirds or more of the votes cast by the Members in the CA category must be 
in favor of the ballot, and at least 50% plus one of the votes cast by the 
members in the browser category must be in favor of the ballot. At least one CA 
Member and one browser Member must vote in favor of a ballot for the ballot to 
be adopted.

(g) A ballot result will be considered valid only when more than half of the 
number of currently active Members has participated. The number of currently 
active Members is the average number of Member organizations that have 
participated in the previous three Forum-wide meetings (both teleconferences 
and face-to-face meetings).  Working Group, subgroup, committee, PAG, and other 
similar meetings do not count for purposes of calculating the umber of 
currently active members._ 

(h) The Chair will tabulate and announce the results within 3 business days of 
the close of the voting period.
(i) The Chair may delegate any of his/her duties under this Section 2.2 and 
Section 2.3 to the Vice Chair as necessary, or the Vice Chair may otherwise 
execute the duties and obligations of the Chair as provided in Section 4.1(a) 
of these Bylaws._
 
2.  Draft Guideline Ballots.  A new Section 2.3 shall be added to the Bylaws, 
and will read in its entirety as follows:
 
_2.3   Requirements for Draft Guideline Ballots
 
This section applies to any ballot that proposes a Final Guideline or a Final 
Maintenance Guideline (a raft Guideline Ballot_), all as defined under the 
Forum IPR Policy.  Draft Guideline Ballots must comply with the following 
rules in addition to the requirements set forth in Section 2.2 above.
 
(a)  A Draft Guideline Ballot will clearly indicate whether it is proposing a 
Final Guideline or a Final Maintenance Guideline.  If the Draft Guideline 
Ballot is proposing a Final Guideline, such ballot will include the full text 
of the Draft Guideline intended to become a Final Guideline.  If the Draft 
Guideline Ballot is proposing a Final Maintenance Guideline, such ballot will 
include a redline or comparison showing the set of changes from the Final 

Re: [cabfpub] Voting has started on Ballot 181 - ends January 7

[realsky(CHT) via Public]

 Chunghwa Telecom abstains on ballot 181.

   Li-Chun Chen



From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Monday, January 02, 2017 1:29 PM
To: CA/Browser Forum Public Discussion List 
Cc: Kirk Hall 
Subject: [cabfpub] Voting has started on Ballot 181 - ends January 7

 
The voting period for Ballot 181 has started, and will continue until January 
7, 2017 at 22:00 UTC.  The ballot is shown below.  Please vote this week on 
this ballot and also on Ballot 180.  Voting will occur on the Public list.
 
Ballot 181 – Readopting BR 3.2.2.4 (Part 1)
 
The following motion has been proposed by Kirk Hall of Entrust and endorsed by 
Peter Bowen of Amazon and Virginia Fournier of Apple as a Final Guideline:
 
-- MOTION BEGINS –
 
In accordance with the Bylaws and Intellectual Property Rights (IPR) Policy of 
the CA/Browser Forum (the “Forum”), the Forum Baseline Requirements (BR) and 
Extended Validation Guidelines (EVGL), as previously approved by all ballots up 
to and including Ballot 176, are hereby readopted by this Ballot, with the 
following amendments.
 
1.  BR 3.2.2.4 is amended to read in its entirety as follows:
 
3.2.2.4 Validation of Domain Authorization or Control
 
This section defines the permitted processes and procedures for validating the 
Applicant's ownership or control of the domain.
 
The CA SHALL confirm that, as of the date the Certificate issues, either the CA 
or a Delegated Third Party has validated each Fully-Qualified Domain Name 
(FQDN) listed in the Certificate using at least one of the methods listed below.
 
Completed confirmations of Applicant authority may be valid for the issuance of 
multiple certificates over time. In all cases, the confirmation must have been 
initiated within the time period specified in the relevant requirement (such as 
Section 3.3.1 of this document) prior to certificate issuance. For purposes of 
domain validation, the term Applicant includes the Applicant's Parent Company, 
Subsidiary Company, or Affiliate.
 
Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the 
subjectAltName extension or in Subordinate CA Certificates via dNSNames in 
permittedSubtrees within the Name Constraints extension.
 
3.2.2.4.1 [Reserved] 
 
3.2.2.4.2 [Reserved] 
 
3.2.2.4.3 [Reserved]
 
3.2.2.4.4 [Reserved]
 
3.2.2.4.5 Domain Authorization Document
 
Confirming the Applicant's control over the requested FQDN by relying upon the 
attestation to the authority of the Applicant to request a Certificate 
contained in a Domain Authorization Document. The Domain Authorization Document 
MUST substantiate that the communication came from the Domain Contact. The CA 
MUST verify that the Domain Authorization Document was either (i) dated on or 
after the date of the domain validation request or (ii) that the WHOIS data has 
not materially changed since a previously provided Domain Authorization 
Document for the Domain Name Space.
 
3.2.2.4.6 Agreed-Upon Change to Website
 
Confirming the Applicant's control over the requested FQDN by confirming one of 
the following under the "/.well-known/pki-validation" directory, or another 
path registered with IANA for the purpose of Domain Validation, on the 
Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an 
Authorized Port:
 
1.The presence of Required Website Content contained in the content of a 
file or on a web page in the form of a meta tag. The entire Required Website 
Content MUST NOT appear in the request used to retrieve the file or web page, or
 
2.The presence of the Request Token or Request Value contained in the 
content of a file or on a webpage in the form of a meta tag where the Request 
Token or Random Value MUST NOT appear in the request.
 
If a Random Value is used, the CA or Delegated Third Party SHALL provide a 
Random Value unique to the certificate request and SHALL not use the Random 
Value after the longer of (i) 30 days or (ii) if the Applicant submitted the 
certificate request, the timeframe permitted for reuse of validated information 
relevant to the certificate (such as in Section 3.3.1 of these Guidelines or 
Section 11.14.3 of the EV Guidelines).
 
Note: Examples of Request Tokens include, but are not limited to: (i) a hash of 
the public key; (ii) a hash of the Subject Public Key Info [X.509]; and (iii) a 
hash of a PKCS#10 CSR. A Request Token may also be concatenated with a 
timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR 
as a Request Token and did not want to incorporate a timestamp and did want to 
allow certificate key re-use then the applicant might use the challenge 
password in the creation of a CSR with OpenSSL to ensure uniqueness even if the 
subject and key are identical between subsequent requests. This simplistic 
shell command produces a Request Token which has a timestamp and a hash of a 
CSR. E.g. echo date -u 

Re: [cabfpub] [Corrected] Voting has started on Ballot 180 - end s January 7

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. abstains on ballot 180.
  Li-Chun Chen
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Monday, January 02, 2017 1:30 PM
To: CA/Browser Forum Public Discussion List 
Cc: Kirk Hall 
Subject: [cabfpub] [Corrected] Voting has started on Ballot 180 - ends January 7

 
The voting period for Ballot 180 has started, and will continue until January 
7, 2017 at 22:00 UTC.  The ballot is shown below.  Voting will occur on the 
Public list.
  
 
 
Ballot 180 – Readopting the BRs, EVGL, EV Code Signing, and NCSSR Guidelines 
with Amendments 
 
The following motion has been proposed by Kirk Hall of Entrust and endorsed by 
Peter Bowen of Amazon and Virginia Fournier of Apple as a Final Guideline:
 
-- MOTION BEGINS –
 
In accordance with the Bylaws and Intellectual Property Rights (IPR) Policy of 
the CA/Browser Forum (the “Forum”), the following Guidelines:
 
· Baseline Requirements Certificate Policy for the Issuance and 
Management of Publicly-Trusted Certificates (BRs)
· Guidelines for the Issuance and Management of Extended Validation 
Certificates (EVGL)
· Guidelines for the Issuance and Management of Extended Validation 
Code Signing Certificates, and 
· Network and Certificate System Security Requirements,
 
all as previously approved by all ballots up to and including Ballot 175, are 
hereby readopted by this Ballot, with the following amendments.
 
1.  BR 3.2.2.4 is amended to read in its entirety as follows:
 
3.2.2.4 Validation of Domain Authorization or Control
 
This section defines the permitted processes and procedures for validating the 
Applicant's ownership or control of the domain.
 
The CA SHALL confirm that, as of the date the Certificate issues, either the CA 
or a Delegated Third Party has validated each Fully-Qualified Domain Name 
(FQDN) listed in the Certificate by using any method of confirmation, provided 
that the CA maintains documented evidence that the method of confirmation 
establishes that the Applicant is the Domain Name Registrant or has control 
over the Fully Qualified Domain Name (FQDN).
 
Completed confirmations of Applicant authority may be valid for the issuance of 
multiple certificates over time. In all cases, the confirmation must have been 
initiated within the time period specified in the relevant requirement (such as 
Section 3.3.1 of this document) prior to certificate issuance. For purposes of 
domain validation, the term Applicant includes the Applicant's Parent Company, 
Subsidiary Company, or Affiliate.
 
2.  EVGL 11.7 is amended to read in its entirety as follows:
 
11.7.1. Verification Requirements
 
(1) For each Fully-Qualified Domain Name listed in a Certificate, other than a 
Domain Name with .onion in the rightmost label of the Domain Name, the CA SHALL 
confirm that, as of the date the Certificate was issued, the Applicant (or the 
Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively 
referred to as “Applicant” for the purposes of this section) either is the 
Domain Name Registrant or has control over the FQDN using a procedure specified 
in Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to a 
Domain Name with .onion in the right-most label of the Domain Name, the CA 
SHALL confirm, as of the date the Certificate was issued, the Applicant’s 
control over the .onion Domain Name in accordance with Appendix F.
 
(2) Mixed Character Set Domain Names: EV Certificates MAY include Domain Names 
containing mixed character sets only in compliance with the rules set forth by 
the domain registrar. The CA MUST visually compare any Domain Names with mixed 
character sets with known high risk domains. If a similarity is found, then the 
EV Certificate Request MUST be flagged as High Risk. The CA must perform 
reasonably appropriate additional authentication and verification to be certain 
beyond reasonable doubt that the Applicant and the target in question are the 
same organization.
 
The proposer and endorsers of this Ballot may withdraw this Ballot at any time 
prior to completion of the final vote for approval, in which case the Ballot 
will not proceed further.
 
-- MOTION ENDS – 
 
The procedure for this Maintenance Guideline ballot is as follows (exact start 
and end times may be adjusted to comply with applicable Bylaws and IPR 
Agreement):
 
BALLOT 180
Status: Final Guideline
Start time (22:00 UTC)
End time (22:00 UTC)

Discussion (7 days)
Oct. 25, 2016
Nov. 1, 2016

Review Period (Chair to send Review Notice) (60 days).  
If Exclusion Notice(s) filed, PAG to be created and no further action until PAG 
recommendations received.
If no Exclusion Notice(s) filed, proceed to:
Nov. 1, 2016
Dec. 31, 2016

Vote for approval (7 days)
Dec. 31, 2016
Jan. 7, 2017

 
Votes must be cast by posting an on-list reply to this thread on the Public 
list. 
 
A vote in favor 

Re: [cabfpub] Voting has started on Ballot 181 - ends January 7

[realsky(CHT) via Public]

The motion begins said
"...as previously approved by all ballots up to and including Ballot 176..."

But there is no Ballot 176 result in Quorum Calculator on Google Docs 
https://docs.google.com/spreadsheets/d/1FBsMZjlzyvK3mFR1u4qMqvZwlI86yJ-v0am1pCBo8uI/edit#gid=4

Also I can't find Ballot 176 in the new table in https://cabforum.org/ballots/

I only find in wiki https://www.cabforum.org/wiki/Ballots ,
there is "176 - Addition of CNAME verification to domain validation methods". 
But after clicking that link, there is no any content about this ballot. 


There are no content under SSL BR V1.41 in
3.3.1. Identification and Authentication for Routine Re‐key

But there are some sentences in Ballot 180 and 181
"...specified in the relevant requirement (such as Section 3.3.1 of this 
document) prior to certificate issuance." 

Would Kirk mind answering above questions? Thanks.


Li-Chun Chen
Chunghwa Telecom 





-Original message-
From:Frank Corday via Public
To:CA/Browser Forum Public Discussion List
Cc:Frank Corday
Date: Fri, 06 Jan 2017 23:47:55
Subject: [外部郵件] Re: [cabfpub] Voting has started on Ballot 181 - ends January 7
Trustwave votes Yes to 181
On 2017-Jan-02, 13:29, "Public on behalf of Kirk Hall via Public" 
 wrote:

 

The voting period for Ballot 181 has started, and will continue until January 
7, 2017 at 22:00 UTC.  The ballot is shown below.  Please vote this week on 
this ballot and also on Ballot 180.  Voting will occur on the Public list.
 
Ballot 181 – Readopting BR 3.2.2.4 (Part 1)
 
The following motion has been proposed by Kirk Hall of Entrust and endorsed by 
Peter Bowen of Amazon and Virginia Fournier of Apple as a Final Guideline:
 
-- MOTION BEGINS –
 
In accordance with the Bylaws and Intellectual Property Rights (IPR) Policy of 
the CA/Browser Forum (the “Forum”), the Forum Baseline Requirements (BR) and 
Extended Validation Guidelines (EVGL), as previously approved by all ballots up 
to and including Ballot 176, are hereby readopted by this Ballot, with the 
following amendments.
 
1.  BR 3.2.2.4 is amended to read in its entirety as follows:
 
3.2.2.4 Validation of Domain Authorization or Control
 
This section defines the permitted processes and procedures for validating the 
Applicant's ownership or control of the domain.
 
The CA SHALL confirm that, as of the date the Certificate issues, either the CA 
or a Delegated Third Party has validated each Fully-Qualified Domain Name 
(FQDN) listed in the Certificate using at least one of the methods listed below.
 
Completed confirmations of Applicant authority may be valid for the issuance of 
multiple certificates over time. In all cases, the confirmation must have been 
initiated within the time period specified in the relevant requirement (such as 
Section 3.3.1 of this document) prior to certificate issuance. For purposes of 
domain validation, the term Applicant includes the Applicant's Parent Company, 
Subsidiary Company, or Affiliate.
 
Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the 
subjectAltName extension or in Subordinate CA Certificates via dNSNames in 
permittedSubtrees within the Name Constraints extension.
 
3.2.2.4.1 [Reserved] 
 
3.2.2.4.2 [Reserved] 
 
3.2.2.4.3 [Reserved]
 
3.2.2.4.4 [Reserved]
 
3.2.2.4.5 Domain Authorization Document
 
Confirming the Applicant's control over the requested FQDN by relying upon the 
attestation to the authority of the Applicant to request a Certificate 
contained in a Domain Authorization Document. The Domain Authorization Document 
MUST substantiate that the communication came from the Domain Contact. The CA 
MUST verify that the Domain Authorization Document was either (i) dated on or 
after the date of the domain validation request or (ii) that the WHOIS data has 
not materially changed since a previously provided Domain Authorization 
Document for the Domain Name Space.
 
3.2.2.4.6 Agreed-Upon Change to Website
 
Confirming the Applicant's control over the requested FQDN by confirming one of 
the following under the "/.well-known/pki-validation" directory, or another 
path registered with IANA for the purpose of Domain Validation, on the 
Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an 
Authorized Port:
 
1.  The presence of Required Website Content contained in the content of a 
file or on a web page in the form of a meta tag. The entire Required Website 
Content MUST NOT appear in the request used to retrieve the file or web page, or
 
2.  The presence of the Request Token or Request Value contained in the 
content of a file or on a webpage in the form of a meta tag where the Request 
Token or Random Value MUST NOT appear in the request.
 
If a Random Value is used, the CA or Delegated Third Party SHALL provide a 
Random Value unique to the certificate 

Re: [cabfpub] Validation WG

[realsky(CHT) via Public]

For proposed Ballot 163 - Fix Errata in EV Guidelines 11.2.1, I joined 
Validation WG, now please include me on the validation WG list. Thank you, 
Jeremy.

  Li-Chun Chen
  Chunghwa Telecom



From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Tuesday, November 08, 2016 12:46 AM
To: CA/Browser Forum Public Discussion List
Cc: Jeremy Rowley
Subject: [cabfpub] Validation WG
 
During the face-to-face we discussed restarting the validation working group. 
Please let me know if you are interested and the agenda items you’d like to 
discuss. We plan on starting the meetings at the time slot previously occupied 
by the code signing working group (9 Pacific). 
 
Thanks,
Jeremy



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


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Presentation file about "Amendment for BR 7.1.4.2. 2 e /f, EVGL 9.2.5 & 9.2.7" for Oct. 18 Working Group Meetings

[realsky(CHT) via Public]

Thanks to participants for patient to hear and discuss the issue in CP review 
working group meeting.  

Thanks for Seth Schoen of Electronic Frontier Foundation,he can't join this F2F 
meeting,   e-mailed me below information, share here with his allowance. 


Wikipedia has at least two other related concepts (which possibly should have 
been part of the same page!)

https://en.wikipedia.org/wiki/Independent_city

https://en.wikipedia.org/wiki/Capital_districts_and_territories

 which might provide further examples of some cities around the world that are 
not regarded as belonging to a state or province.

 Li-Chun CHEN


-Original message-
From:realsky(CHT) via Public 
To:public@cabforum.org 
Date:Tue, 18 Oct 2016 14:07:38
Subject:[外部郵件] [cabfpub] Presentation file about "Amendment for BR 7.1.4.2.2 e  
/f,EVGL 9.2.5 & 9.2.7" for Oct. 18 Working Group Meetings


Attached is my Presentation file about "Amendment for BR 7.1.4.2.2 e/f, EVGL 
9.2.5 & 9.2.7" for discussion in Oct. 18 Working Group Meetings (Policy Review 
Working Group led by Ben.).

  Li-Chun CHEN
  Chunghwa Telecom Co. Ltd.

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




___
Public mailing list
Public@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.


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public