Home » Posts » Minutes of the F2F 46 Meeting in Cupertino, California, 12-14 March 2019

Minutes of the F2F 46 Meeting in Cupertino, California, 12-14 March 2019

WG and Subcommittee Meetings (Tuesday March 12, 2019)

Call to Order – CA/Browser Forum Meeting

Attendees on March 12, 2019: Adam Clark (Visa), Adam Sink (GoDaddy), Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Bailey Basile (Apple), Ben Wilson (DigiCert), Benjamin Gabriel (DarkMatter), Bruce Morton (Entrust Datacard), Xiaotong Chen (SHECA), Chris Kemmerer (SSL.com), Corey Rasmussen (OATI), JiuQing Cui (SHECA), Curt Spann (Apple), Dave Blunt (Amazon Trust Services), Davut Tokgöz (E-Tugra), Daymion Reynolds (GoDaddy), Dean Coclin (DigiCert), Devon O’Brien (Google), Dimitris Zacharopoulos (HARICA), Don Sheehy (CPA Canada), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Eva Van Steenberge (GlobalSign), Fotis Loukos (SSL.com), Frank Corday (SecureTrust), Geoff Keating (Apple), Georgy Sebastian (Amazon Trust Services), Gordon Bock (Microsoft), Hwai-Ling Shan (Chunghwa Telecom Co. Ltd.), Iñigo Barreira (360), Janet Treasure (CPA Canada), Jason Cooper (Microsoft), Jeff Ward (WebTrust/BDO), Jeremy Rowley (DigiCert), Joanna Fox (GoDaddy), Jos Purvis (Cisco), Josselin Allemandou (Dhimyotis (Certigna)), Karina Sirota (Microsoft), Kathleen Wilson (Mozilla), Ken Myers (FPKI), Khadija Amin (Cisco), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom Co. Ltd.), Matthias Wiedenhorst (ACAB-c / TÜViT), Michelle Coon (OATI), Mike Guenther (SwissSign), Mike Reilly (Microsoft), Nur H. Kuran (E-Tugra), Philippe Bouchet (ACAB’C/LSTI), Renne Rodriguez (Apple), Rich Smith (Sectigo), Robin Alden (Sectigo), Romain Delval (Dhimyotis (Certigna)), Ryan Hurst (Google), Ryan Sleevi (Google), Scott Rea (DarkMatter), Somer Shively (Cisco), Tad Kaburaki (Amazon Trust Services), Tadahiko Ito (Secom), Xingkun Tang (SHECA), Tim Callan (Sectigo), Tim Hollebeek (DigiCert), Tim Shirley (SecureTrust), Trevoli Ponds-White (Amazon Trust Services), VijayaKumar Manjunatha (eMudhra), Wayne Thayer (Mozilla), Wei Yicai (GDCA), Xiu Lei (GDCA), Yuu Hidaka (Secom), Zane Lewiston (Microsoft), Zhihui Liang (360).

Welcome, Preliminary Matters, Meeting Recordings, Photo Policy, Logistics, Antitrust Statement, Code of Conduct, Assign Minute Taking

Forum Infrastructure Working Group meeting

Presenter:

Jos Purvis, Cisco

Notetaker:

Chris Kemmerer, SSL.com

Noted participants: Jos, Dimitris (DZ), Rich Smith, Wayne Thayer, Ben Wilson, Ryan Sleevi, Curt Spann

Jos takes the floor. Call to order. Approval of minutes tabled for the next meeting since the draft minutes have not been posted yet.

Items for consideration:

WIKI MIGRATION – Jos: test has been up, testing of migration = next phase (wiki to test server) planned (later: Damien notes )

Q abt infrastructure for wiki – which organization can supply hosting: open question. Amazon requests info re: requirements.

DOCUMENT MANAGEMENT

– Request for demo of GitHub for ballot creation – Jos offers to run a Git 101 session Thursday, Wayne notes that workflow/redline demos scheduled for Wed. – Q from Rich Smith: do we guarantee consistency in redlining? Wayne: q he THOUGHT he was going to recv – how to harmonize redline and ballot language, suggests changing bylaws to allow for the GH redline itself to be the item voted upon. Jos Q: any additional formal process needed for GH correction in course of voting/discussion? DZ: discussion needed to ensure GH canonical version acceptable. Ben: notes that a batch for minor language error correction circulation may be required. Jos: suggests that the GH/markdown version is canonical, batching for a vote to update via ballot.

(Further discussion of migration ensues, including testing migration as poss. Thursday topic for hackathon.)

DZ: Remote participant notes that F2F infrastructure requires use of microphone.

Jos yields time back to chair.

DZ: Notes the issue of re-reading bylaws can be difficult given multiple WGs

Sleevi: Charter/structure of WG vs subcommittees discussed, notes that WGs include specific companies w/specific surrender of IP rights.

Jos/DZ/Sleevi: discuss that Infrastructure WG could convert to a subcommittee w/IP commitment under plenary? when/if/as bylaws modified to allow for this.

Ben: sign-in sheet?

Jos: notes that this is a good question going forward, as nature of CABF F2F sessions has changed from Ye Olde Dayes.

Jos shall append companies/representatives

Tim: notes that repeating questions helps remote participants, and WG IP acceptance

DZ: legal opinion was rendered that antitrust statement needed for each WG, but would welcome another opinion

Sleevi: Google believes that antitrust statements important for each WG (as sep. meeting)

Ben: Possibly streamlined/abbreviated method of accepting anti-trust statements?

Sleevi: IETF Notewell as a method/model of streamlining similar requirements

Jos: Notes that growth process will lead to more issues/questions/methods which will evolve to meet needs.

Curt: do we need separate WebEx sessions for each WG? (Asking as host, quite likely.)

Jos: quite likely, for discussion – but then:

Sleevi: logistical provisioning is extension of physical space, but should be considered. Nothing in bylaws *prohibits* chair from inviting non-WG members to “observe” any WG session.

Jos: Suggests noting in bylaws: F2F and remote participants operate under identical constraints

Sleevi: doesn’t believe WebEx starting/stopping required, photo policy suggests that remote participants distinguish themselves

DZ/Jos notes that CS WG will lead to even more issues/questions.

Jos also notes that CABF general questions list best solution – DZ notes per bylaws, incoming questions should be distributed to chair of appropriate WG for resolution

Jos: mailing list titles note – WG vs WG-MGMT(?)

Tim: bylaws only allow for acceptance of questions by the forum as a whole, proly best to amend bylaws to allow (for instance) CS WG questions to be forwarded/declared to move to the CS WG for action (to allow IP questions to be best directed).

Jos: adjourns mtg at 10:06

Forum Bylaws and CWG Charter discussion

Presenters:

Dimitris Zacharopoulos, HARICA
Dean Coclin, Digicert
Wayne Thayer, Mozilla

Notetaker:

Robin Alden, Sectigo

Wayne circulated bylaws updates for members to have their legal counsel review. Wayne thanks Dimitris for doing a substantial part of the work.

We’re changing the way membership works. currently you have to be a member of a chartered WG to be a member of the forum, but we had applicants who applied to both and the requirements were different. We changed it so now if you’re a member of a chartered WG you are a automatically a member of the forum. Also moved a bunch of the membership language into the CWG charter instead of in the bylaws. Made clarifications to voting rules as to who could vote on which items. Also clarifications to how officers are elected.

We emailed out on Feb 19th asking for legal review / opinions.

After legal review, heard comments from Apple.. 5.6 subcommittees of the forum. The forum has no IPR protection. Wayne drafted: “Due to the lack of IPR protection, subcommittees of the forum shall not negage in activities that carry significant risk of introducing encumbered IP such as the development or amendment of guidelines …” Apple’s attorneys prefer “No actions taken by a forum subcommittee will implicate obligations under the IPR policy . a forum subcommittee will not generate or discuss any contributions of any draft guideline, or final guideline of the CWG or partake in activity that could otherwise trigger IPR obligations….” Suggest we accept that. Any comments?

Looking for feedback on the following so we can put a ballot forward..

2.1 forum membership language has been stripped out and replaced with ‘CWG members & associated members and interested parties are automatically granted forum membership.’ All this language is also grafted into the server certificate working group charter.

Tim Hollebeek: Is that needed for infra WG? Wayne: We explcitly said 1 member 1 vote for infrastructure group. Jos: It might be useful to deteermine of membership of the infra WG was dependant on plenary membership. We need to clarify that the infra group does not grant plenary membership.

Rich: turn it into a sub-committed, and in the ballot include wording to amend the by-laws. Wayne: finally we have a reason to turn the infra WG into a Subcommittee!

Anna (Apple) asked if all existing members are grandfathered in. Ryan S: although an interested party joined the CSWG who was not a member they have subsequently become a member. A defensive approach is (similar to how Daymion suggested we tackle the infra group) to provide some guidance on that in the event that it takes a month or two to go through. Wayne: The guidance would be to the effect that you have to be a member of the CS or SMIME WGs once the new bylaw changes they automatically become members of the forum. Ryan S: Don’t even code it to those specific working groups. Just a general statement. Wayne: we can add somthing to address the membership question.

1.3: scratched ‘the chair read the anti trust’ to ‘the chair shall have read the anti trust..’

2.2. ending forum membership. If you are no longer a member of any chartered WG, your membership terminates. (but wording in the doc doesn’t say that) Wayne will check and revert.

Wayne: changes to how ballots work – mostly from Dimitris – says which lists ballots must be sent to for each WG.

2.4 – Wayne’s interpretation is that the bylaws discriminate between a ballot version of the GLs (e.g. “add this wording to section x.y, delete section pp”) and a redline version of the ballot. it is implied that both will exist. Added language that says that you don’t have to include the ballot version. The redline remains mandatory.

5.1 clarified whether maillists and websites pertain to the forum or the WG.

5.3.1 formation of chartered WGs. We moved the membership criteria into the WG charter. The WG charter has to say how people become members.

Electing new Chair and vice chair. tried to clear up ambiguities.

5.3.4 legacy WGs, removed , as that was a transition from a previous version.

Subcommittees:- a bunch of improvements from Dimitris

Charter template.. added much more detail in membership criteria that’s required in future charters.

Server Cert WG charter has been updated with the membership criteria that used to live in the bylaws. Added criteria for ending WG membership.

Dimitris: For questions lists, do we need to make it explicit that each WG should have a Qs list?

Jos: 6.2 questions and comments, it probably needs amending as it says ‘.. the questions list response shall be coordinated on the member mail list ..’ to move the discussion to the relevant list. Qs to the questions list will be directed to the relevant working group (or groups) for answer.

Next steps are to take a look at the minutes, incorporate the comments we had back, and send out an updated draft. Wayne asks how much time we would need to allow for legal review of the changes made as a result of the above comments. Anna: 2 weeks Wayne: OK

Adjourn CA/B Forum Meeting

Call to Order – Server Certificate Working Group Meeting

Antitrust Statement, Assign Minute Taking

Network Security Subcommittee

Presenter:

Ben Wilson, Digicert

Notetaker:

Trevoli Ponds-White, Amazon Trust Services

One of the primary goals of the Net Sec group has been to examine how to re-architect the Network Security Guidelines. By examining common problems that people have been running into such as compliance issues, lack of clarity, etc. The group will be taking a parallel approach of running separate efforts such as document structure. There is also another work stream that is focused on clarifying the definitions for the purposes of driving scoping the requirements. To run these efforts in parallel 4 sub groups have been created:

Document Structure
Threat Analysis
Access and Authentication
Pain Points

In the previous meeting of Net Sec we started to define specific deliverables.

The Net Sec group made the decision to use, for some of the requirements, guidance from other compliance programs, such as PCI DSS in particular which we agreed had a good framework for laying out the principles and how to meet them.

The purpose of the Threat Model group will be able to identify new threats we haven’t found before.

The purpose of the Document Structure group is to come up with a framework for document restructuring.

Validation Subcommittee

Presenters:

Tim Hollebeek, Digicert
Wayne Thayer, Mozilla

Notetaker:

Doug Beattie, Globalsign

Presentation: Validation.pptx

Comments beyond what is in the presentation:

IANA registration of CAA tags process has been approved and is now working quickly and efficiently. Just need a publicly accessible link that can be referenced.

Tim discussed the following:

History of Validation working group
Summary of Validation summit held in March 2018
Listed currently Active methods
Did a quick scan through the Google Doc created for the Validation Summit with updates since then.

Identified the following as next targeted updates:

Method 2: Should we split method #2 (Email, Fax, SMS, or Postal Mail to Domain Contact) into multiple methods as we have done recently with Email and Phone validation methods?
Update Method 6 for items such as:
proper handling of redirects for HTTP validation
On shared IP addresses: use SNI
Query strings: TBD
Cross protocol attacks: TBD
Caching: Do nothing
There are 5 general updates that have been identified and will be targeted with upcoming ballots:
Random Number requirements are repeated over and over, can we normalize these, or define the requirements in separate section? Freshness vs. one-time secret should be highlighted.
Domain Contact: Review definition and references
Including “notes”: We should consistently remove this and update the methods to contain the relevant guidance or info.
Spring time clean up minor updates: reference to compliance dates in the past, Internal names, minor formatting issues, etc.
What is an ADN and how can validation re-use be better described?
Wildcard domains and their description needs to be cleaned up
Method (new): Registrar challenge
this leverages existing threat challenge (who-is), so it should be relatively easy to accomplish.
This is stronger than who-is
Using RDAP authenticated communications to the Registrar would be an improvement over Whois
This mitigates DNS related issues since it not in the middle as this is an independent direct link to the Registrar
There was a recommendation that perhaps CAs should document how they do this in their CPS

Summary of Validation Methods in section 3.2.2.4:

1: REMOVED: Validating the Applicant as a Domain Contact (Ballot 218)
2: Email, Fax, SMS, or Postal Mail to Domain Contact
3: SUPERSEEDED (As of May 31, 2019) Phone Contact with Domain Contact (SC14)
4: Constructed Email to Domain Contact
5: REMOVED Domain Authorization Document – (Ballot 218)
6: Agreed-upon change to a website – Changes being investigated
7: DNS Change – Changes being investigated
8: IP Address – improvements made by removing any other method in 3.2.2.5
9: REMOVED Test Certificate (SC15)
10: TLS Using a Random Number – To be replaced with TLS ALPN method
11: REMOVED – Any Other Method
12: NEW: From Method #1: Applicant as domain registrant
13: NEW: Email to DNS CAA Contact (SC13)
14: NEW: Email to DNS TXT Contact (SC13)
15: NEW: from Method #3: Phone Contact with Domain Contact (SC14)
16: NEW: Phone Contact with DNS TXT Record Phone Contact (SC14)
17: Proposed: Phone call to DNS CAA Contact
18: Proposed: TLS ALPN, once RFC is finalized [Break]
Next steps:
Many of the things we discussed over past year are ready for ballots.
We need concrete proposals to move forward.
Tim Hollebeek will update the Trello board.
We are seeking a series of validation ballots before the June 2019 meeting.

Adjourn Server Certificate Working Group Meeting

Call to Order – Code Signing Certificate Working Group preparatory Meeting

Attendees on March 12, 2019: Not captured as this was not an official meeting of the CSCWG.

Antitrust Statement, Assign Minute Taking

Kick-off preparatory meeting for the newly established CSCWG

Presenter:

Dean Coclin, Digicert

Notetaker:

Jos Purvis, Cisco

N.B.: As this was not an official meeting of the CSCWG, no attendance was taken for the preparatory announcement and procedure review.

Dean noted that the first meeting will take place on Thursday during the Face-to-Face meeting, and that this and the posting to the public list would constitute the required public notice for the impending meeting. He took a roll of CAs and other parties present interested in the Code Signing Working Group, and indicated that at the first meeting, he would go down the list of those present and validate they met the requirements in the charter for the membership each one sought.

Adjourn Code Signing Certificate Working Group preparatory Meeting

Plenary Meeting Day 1 (Wednesday March 13, 2019)

Call to Order – CA/Browser Forum Meeting

Attendees on March 13, 2019: Adam Clark (Visa), Aleksandra Kapinos (Certum), Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Bailey Basile (Apple), Ben Wilson (DigiCert), Benjamin Gabriel (DarkMatter), Bruce Morton (Entrust Datacard), Xiaotong Chen (SHECA), Chris Bailey (Entrust Datacard), Chris Kemmerer (SSL.com), Corey Rasmussen (OATI), JiuQing Cui (SHECA), Curt Spann (Apple), Dai Yeqi (SHECA), Dave Blunt (Amazon Trust Services), Davut Tokgöz (E-Tugra), Daymion Reynolds (GoDaddy), Dean Coclin (DigiCert), Devon O’Brien (Google), Dimitris Zacharopoulos (HARICA), Don Sheehy (CPA Canada), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Eva Van Steenberge (GlobalSign), Fotis Loukos (SSL.com), Frank Corday (SecureTrust), Geoff Keating (Apple), Gordon Bock (Microsoft), Hwai-Ling Shan (Chunghwa Telecom Co. Ltd.), Iñigo Barreira (360), J.P. Hamilton (Cisco), Janet Treasure (CPA Canada), Jason Cooper (Microsoft), Jed Glazner (Apple), Jeff Ward (WebTrust/BDO), Jeremy Rowley (DigiCert), Joanna Fox (GoDaddy), John Noll (Apple), Jos Purvis (Cisco), Josselin Allemandou (Dhimyotis (Certigna)), Karina Sirota (Microsoft), Kathleen Wilson (Mozilla), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom Co. Ltd.), Lin Feng (CFCA), Marcelo Silva (Visa), Matthias Wiedenhorst (ACAB-c / TÜViT), Mike Guenther (SwissSign), Mike Reilly (Microsoft), Nur H. Kuran (E-Tugra), Philippe Bouchet (ACAB’C/LSTI), Rachel McPherson (TrustCor), Rich Smith (Sectigo), Robin Alden (Sectigo), Romain Delval (Dhimyotis (Certigna)), Ryan Hurst (Google), Ryan Sleevi (Google), Scott Rea (DarkMatter), Somer Shively (Cisco), Tadahiko Ito (Secom), Xingkun Tang (SHECA), Tim Callan (Sectigo), Tim Hollebeek (DigiCert), Tim Shirley (SecureTrust), Tony Perez (GoDaddy), Trevoli Ponds-White (Amazon Trust Services), VijayaKumar Manjunatha (eMudhra), Wayne Thayer (Mozilla), Wei Yicai (GDCA), Wojciech Trapczyński (Certum), Xiu Lei (GDCA), Yuu Hidaka (Secom), Zhihui Liang (360), Mads Henriksveen (Buypass), Mike Agrenius Kushner (PrimeKey), Kirk Hall (Entrust Datacard).

Welcome, Recap of Preliminary Matters, Meeting Recordings, Photo Policy, Logistics, Antitrust Statement, Code of Conduct, Assign Minute Taking

Approval of CABF Minutes from March 7, 2019

Presenter:

Dimitris Zacharopoulos, HARICA

Approval of CABF Minutes from March 7, 2019

Report from Forum Infrastructure Working Group

Presenter:

Jos Purvis, Cisco

Notetaker:

Tim Callan, Sectigo
The working group met yesterday.
It went over migration of the wiki from physical hosting to AWS hosted service. We believe Amazon will be able to provide that.
We have scheduled a slot on Thursday to look at the wiki migration and try to get the data copied over.
The working group went through document management.
We are closer to getting GitHub as canonical standard for baseline requirements.
We scheduled a session to compare the PDFs from the markdown to the current BRs and, if need be, update the BRs to match the markdown.
Based on a long discussion we decided it makes sense to convert the Infrastructure Working Group into a subcommittee because it’s cleaner from a membership perspective.
We confirmed that remote attendees are governed by the same requirements as those present, which means we don’t have to stop and start the WebEx from working group to working group during in-person meetings.

Report on Bylaws, SCWG Charter updates

Presenters:

Dimitris Zacharopoulos, HARICA
Wayne Thayer, Mozilla

Notetaker:

Robin Alden, Sectigo

Dimitris: We had good discussion yesterday, and some contributions from Apple’s counsel. Wayne: We’re going to take the bylaws and circulate them again, give a few weeks for review, and then ballot.

CA/B Forum Issues to be addressed

Presenters:

Dimitris Zacharopoulos, HARICA
Dean Coclin, Digicert
Wayne Thayer, Mozilla

Notetaker:

Ben Wilson, DigiCert

Dimitris made observations regarding the CABF from the mailing list and F2F and WG meetings.

Use of English – Many members have difficulty when you use complex phrases or slang. Online this isn’t as much of a problem. However, in F2F, WG meetings and teleconferences, please take time to explain your positions.

Expression – Should be done in a neutral way with more consensus. We need to make more members feel comfortable and willing to share more freely. This will help us improve practices.

IPR Protection Discussions – Not all members may understand the IPR protections. Please feel free to ask existing members or leaders if you have questions. IPR issues should not dominate discussions.

“Basic Principles”

The CAB Forum is considered a volunteer-operated standards body. Members need to be patient when things don’t work perfectly. Officers provide service to organization and should be given respect.

Wide participation is encouraged to help with the global reach of the CAB Forum’s standards. We are all here to learn and can learn from sharing insights with the group.

The CAB Forum is not a regulatory body. It doesn’t monitor compliance or impose sanctions for non-compliance with guidelines.

The SSL/TLS Ecosystem (Web PKI) is mature and users of the Internet rely on the work we do. We need to take care in drafting requirements. Ballot proposers should take the time to carefully review the proposal and members need to closely review proposals during the comment period.

The CAB Forum leadership is working to formalize procedures and drafting checklists and guidance.

Proposals for Future Meetings

Dimitris will send out a survey to see what the expectations are of attendees.

Proposed Future Work Shops – examples include key management, validation practices, CP/CPS documentation, use of Policy OIDs, etc. They might help us identify where other improvements can be made. Disclosure of practices will help improve them.

Sessions for Specific Regions/Geographies – members in those regions can prepare and bring practices and concerns back to the Forum.

We need volunteers to write about good, bad and best practices for the web site subject to approval from the Forum membership.

Creation of additional Working Groups – Secure Mail

Presenters:

Ben Wilson, Digicert

Notetaker:

Ken Myers, Protiviti Supporting the U.S. Federal PKI
Code Signing WG charter went out first. A lot of the SMIME charter concerns were specific to creation of working groups rather than specific to SMIME. Waiting for Code Signing WG to pass to work out kinks and then focus on SMIME working group creation.
Ask that SMIME Charter be the next ballot. Please submit any comments or concerns on ballot here or to the list.
Feb 5th was last email on the topic.
Google did not comment on Code Signing WG Charter because they are not a certificate consumer. The basis for SMIME comments are concerns about SMIME audit criteria. WebTrust for CA vanilla is the minimum bar and comparable ETSI, specific to SMIME there are alot of government CAs for national citizens and national audit schemes. A number of CAs already issue and we can develop an audit standard, how do we capture that and then put that in the charter? Those comments needed to filter back to by-laws which would influence the government audits for SMIME consumers and issuers. We don’t want to limit the parties based on audits.
Tim – anyone outside of audit reqs can participate as associate members or interested parties and no voting rights.
Ryan, Google – If the focus is SMIME how do we scope the criteria to include these outside parties if they want to have voting rights?
Tim – If the bylaw ballot passes then WG charter will have increased scope and may include additional types of audits outside of webtrust and ETSI. We can make that change to the SMIME charter.
Ryan, Google – The crux is the charter requires an Audit and SMIME consumers may not have those audits so the WG may exclude a number of participants who this charter will impact. We need something to make a baseline for SMIME, it just doesn’t exist in the same fashion as a WebTrust for BR. Do we allow it to be open ended or make it restrictive, similar situation the CAB Forum faced in 2008 and 2010 with TLS. The Forum is taking on a new activity without a strong path.
Ken – U.S. Federal PKI follows a U.S. government PKI standard which is based on NIST guidance for identity validation, physical, and technical security in additional to other controls. Comparable to WebTrust for CA but includes additional criteria that a CP conforms to its CPS and the entity is audited against its CPS. Biggest difference we noticed is WebTrust for CA is less descriptive meaning they ask if there are procedures for validation while FPKI has specific NIST procedures to validate etc. If the Federal PKI were to submit an audit, it would be an Federal PKI audit.
Ryan, Google – If you use WebTrust for CA, very broad set up requirements, or ISO or a nationally recognized scheme for email certificates.
Dean – We have a blank slate here and it seems the reluctance was to make it a narrow scope and then focus on either one aspect of SMIME. First task might be how to validate an email, and then focus on identity validation. Some comments were to make the chart narrow to focus on one task while others say to include all proposed tasks to not have to recharter which has caused issues in the past.
Ryan, Google – But how do you scope that broad identity validation task that there is an endpoint in mind? Certificates may be used for different purposes in different jurisdictions and now that we are talking about people there are multiple privacy laws which may come into play when validating a person vice a device. Charter should be scoped so that a task is manageable with a clear end state rather having multiple tasks and moving on before a task is completed. This is a multi-year effort and we should try to identify all issues at first. Let’s scope for highest priority issue first and then complete that and then move on to hard identity issues with a little bit of time.
Tim – Client auth and document signing are out of scope because this is SMIME.
Ryan, Google – Understand but it has come up that those should be part of the profile because some jurisdictions may use one certificate for all signature or authentication because of the identity proofing.
Tim – Not a bad idea to identify when types of certificates may be used for multiple use cases. That’s one of the things I push back on with charter scoping issues. We need to trust the participants to not take too long with creating a wg product.
Ryan, Google – Much rather focus on email validation because it is an easy end point and can be a stepping stone to bigger issues. Odds of producing a product are much higher with a narrow scope then including every possible issue.
Dean – Focus on what we have agreed, need for a SMIME WG, need for standards, standards close to BR, need for industry participants, membership will be in the charter. Disagreement on scope whether narrow for email validation or broad to include identity. We can keep talking around the same scope issue. Charter authors can take this and update the charter.
Dimitris – We can start with a narrow charter by maybe focusing on certificate extensions. Take a look at current certificates to see if they include identity (persons) or emails (potentially not linked to person directly).
Ryan, Google – Have this idea of an RFC822 name in SAN and then methods to validate the information in the extension. Whether that is format of the DN or assessment of the information. Narrow scope could be just on that and maybe a transition scheme of how to start issuing certs in accordance with this method. Then move on to focus on identity like SMIME + identity and maybe at that point look at extended signature capabilities or assurance certificates similar to DV, OV, EV types for identity.
Dean – Go back to certification discussion, national CAs and national requirements. Helpful to understand those national schemes as we update the charter. Do other countries have national standards around identity validation or auditing?
Scott Rea – UAE has a national identity card and standards about card certificates and national assurance criteria including national audit requirements. CAs can be certified under those processes.
EU has a ITIS framework general PKI framework that might be useful for this discussion.

Adjourn CA/B Forum Meeting

Call to Order – Server Certificate Working Group Meeting

Antitrust Statement, Assign Minute Taking

Approval of SCWG Minutes from March 7, 2019

Presenter:

Dimitris Zacharopoulos, HARICA

The Minutes were approved.

Procedures for ballots and guideline updates

Presenters:

Dimitris Zacharopoulos, HARICA
Wayne Thayer, Mozilla

Notetaker:

Marcelo Silva, Visa

Wayne – Addressed the Bylaw updates on some potentials changes.

Dimitris – In order to get a ballot number. We need to find the endorsers first and update Wiki table. Are we going to continue following that?
Wayne – Agreed on that as a good practice to get all endorsers before get a ballot number, stating that before you post a ballot for a formal review, you need to get endorsers and a number.
Tim – Existing practice is that you go to Wiki, if you have 2 endorsers. You should update the Wiki only once you have an official ballot with the required endorser.
Dimitris – Under the Bylaws we are getting questions on how to start a new ballot and the procedures for that. That’s why the value on having this conversation.
Tim – We should have a step-by-step process in the Wiki. It would be extremely helpful.
Ben – Historically we have sent the emails messages to describe what the ballot is and why we are creating it, instead of the former process to do that on the Wiki.
Wayne – We have the Webpage links to ballots and from there to the Wiki.
Ryan – We only publish on the website when we already have an official ballot.
Wayne – We don’t actually have a consensus on the process. Sometime we publish only after the ballot is accepted/rejected.
Dimitris – A solution to tackle this redundancy is to point the Email and Wiki to the Website, where we would have a centralized information.
Ryan – Initially Dimitris mentioned the difficult to know how to create a ballot, but now we are discussing where the information should be.
Dimitris – In the Wiki we should have only the reference to the ballot number, and once it’s voted we can have it only in the webpage. I’ll publish a ballot creation check list for comments.
Ryan – Prescriptive or descriptive?
Tim – Suggested to create a template/sample/example to give more assistance on the process.
Ryan – When you have version numbers, you may have the idea to rush it to the completion to the voting process, and that’s not a good thing.
Tim – On the ballot versioning, the intention was to avoid forcing rushing the discussion to voting process.
Ryan – For the benefit of the broader group, it seems to the ballot versioning idea is not good to not rushing ballot. We should discuss ideas and language before get into the official ballot discussion phase.

Then I was wondering whether this doc address that and avoid rushing ballots.

Dimitris – Whenever someone would like to introduce an idea, it does not get a ballot number. The language has to be mature enough, and try to reach consensus, and then start the discussion period with a ballot number.

So the idea is working on the ideas, language, get endorsers, reach out an initial consensus, and then get a ballot number and start the official discussion period.

360 Root Program Update

Presenter:

Iñigo Barreira, 360

Notetaker:

Chris Kemmerer, SSL.com

News: Technical – There´s a “http: not secure” Project introducing a new icon with an “red x” in the “lock” icon and when click on it shows messages such as “your connection is not secure” or “do not enter sensitive information in these fields” for those sites with request passwords or credit card numbers. In June 2019, this “icon” will be changed to a “not secure” message. Within this Project there´s also a warning banner in which a banner message indicates the website is not safe and indicates to not introduce any sensitive information and adds some options to dismiss it or to not show any more popups information (note: more than 8 million pages have been warned daily). – New Mac OSX and Linux versions now out (share root store and program with Windows). – Cross-platform support w/same root store (see graphic). – Other products: 360 Secure Browser for Enterprise (admin can control root store/certificate). – Update to Chrome 69 in Q1 2019. – TLS 1.3 support in next version (April 2019).

** News: Root store inclusion** – Updated list December 2018, new in browsers Jan 2019, new list expected by end of March 2019 (and expected updates to RSP every three months) – See: caprogram.360.cn/#trust – Still many issues w/CA documentation noted (and slow responses from CAs to 360 queries), would like more attention paid to documentation by CAs and auditors.

Apple Root Program Update

Presenters:

Curt Spann, Apple
Geoff Keating, Apple

Notetaker:

Bruce Morton, Entrust Datacard

Apple advised of the following:

Reminded that CT is enforced for certificates issued after October 2018.
Support for TLS 1.0/1.1 will be dropped.
Support for TLS 1.3 and is already shipping in 12.2.
Apple plans to mark HTTP as “not secure.”
Apple root program is not changing significantly, yet.

Cisco Systems Root Program Update

Presenters:

J.P. Hamilton, Cisco
Jos Purvis, Cisco

Notetaker:

Mike Reilly, Microsoft

Presentation: Cisco Trusted Root – CABF Meeting 46 Update.pdf

ADDING TRUST BITS: Keeping with a multi-file approach in the near term based on current gear still in the field. Highlights discussed were:

Tech changes to add trust bits to P7Bs in progress
Will deﬁnitely want at least Server TLS, Code Signing, Device Identity
Current multi-ﬁle approach needs to stick around
Supports devices with earlier non-bit releases
Provide multiple sizes for smaller memory footprint requirements.

Trust bits will include:

CORE BUNDLE NEEDS TO SPLIT:

Cisco wants separation of Cisco-speciﬁc private functions like licensing from mutable stores like TLS.
We can then encourage devs to keep the immutable set in protected memory
With the expansion of our Core TLS CA set, the split will help out devices with smaller memory footprints

STICKING A FORK IN THE CORE: ios_core.p7b “Grilled Lite” will fork into:

DIVING INTO THE CCADB:

Cisco moving more fully into the CCADB

In the next year:

Replace the contents of Intersect with validations from CCADB
Open a formal inclusion request process through CCADB

Google Safe Browsing (Guest Speaker session)

Presenter:

Cy Khormaee, Google

Presentation: Safe Browsing Overview for CAB.pdf

Google Root Program Update

Presenters:

Devon O’ Brian, Google
Ryan Sleevi, Google

Notetaker:

Eva Van Steenberge – GlobalSign

Presentation: CABF F2F 46 Chrome Browser Update.pdf

Key points:

Principle for security indicators: visible when you need it, invisible when you don’t.
Conducted a study on security UI (which has been discussed at F2F 44 in London), which is currently in peer review. This study will be circled back in F2F later this year.
Currently conducting a small % experiment – following work other browsers have been doing. Showing red “not secure” chip on HTTP pages.
Degrading positive security UI.
Talks about challenges with URLs showing identity information.
TLS 1.0 and 1.1 deprecation early 2020. early release channels in 2019.
CT front: log list changes. Following shards will be usable:
June 2019 – Nessie
August 2019 – Xenon
On incident reporting: High quality and thorough incident reports: transparency and cooperation gives confidence that the issue at hand is a problem of the past, and that the is bound.

Q: October 2018, upcoming Google research paper on auto-upgrading mixed content. Is this research concluded and included in the new study (that is currently peer reviewed) or is this research still ongoing?

A: Orthagonal papers. This one is about site identity and if EV indicators are conveying site identity, and not about mixed content.

Q: Where is the progress on that one?

A: I don’t know, will need to check.

Microsoft Root Program Update

Presenters:

Mike Reilly, Microsoft

Notetaker:

Tim Hollebeek, Digicert

Presentation: Microsoft CABF Update Presentation.pdf

Mozilla Root Program Update

Presenter:

Wayne Thayer, Mozilla
Kathleen Wilson, Mozilla

Notetaker:

Jos Purvis, Cisco

Presentation: Mozilla Root Program Update – Meeting 46 March 2019.pdf

Kathleen presented first, discussing the CCADB effort. For CCADB, Kathleen primarily works with audit cases, CCADB verifications, and inclusion requests, which are then passed to Wayne for verification and close review. When you update your root inclusion bug, Kathleen gets an email and notes the date and number. All bugs are processed first-in-first-out, regardless of who the CA is–this typically takes about 3-4 weeks due to the volume of work involved. If CAs have not heard anything in 4+ weeks, they can nudge Kathleen for a response. Kathleen showed off the CCADB site for CAs, walking them through the interface and how to generate audit cases (annual updates) using the standard process. This new process allows CAs to provide updated audit information in one place and it goes to all of the various root programs included.

Now CAs can submit root inclusion cases in addition to root update cases. CAs will also be able to submit one inclusion case and check off which root programs they want to submit for, allowing the ticket to be routed to multiple at once instead of having to duplicate information. Right now Mozilla is using root inclusion cases, and CAs can enter information for themselves. CAs can avoid not to have to fill out PDFs, as they can now just fill out information directly in CCADB.

Next project for the CCADB is to solve how people who aren’t in the CCADB right now can request access, to help reduce/eliminate copy-pasting of data.

If CAs get stuck using CCADB, they can email ; the home page in CCADB also lists root store operators and contacts.

Wayne went next; he opted to read the Mozilla root store update into the record. A copy of the update is available in PDF as an attachment to this page.

Questions for Mozilla

Ryan Hurst: Thanks for clarifying M’s policy on bulk revocation. I think there’s an opportunity for more clarity here. You’ve requested more information about non-disclosures, including justifications on a per-customer basis. When dealing with millions of certificates, how will customer-by-customer justifications work, and how are we supposed to even gather that within 5 days? Can we accommodate this type of problem? Wayne: My significant takeaway here is that it’s not policy, it’s best practice in the wiki. It was updated in response to the underscore sunset period, focused on the small set of certs there. I think there’s room in that guidance to expand to look at the impact of 500,000-certificate revocations and take that into consideration. Clearly it doesn’t make sense to require per-subscriber explanations for 500k certs; I have that as a to-do to clarify and request input from the community.

Ryan Sleevi: Going back to intermediate preloading–I know of at least 5 members with technically constrained subCAs. Mozilla doesn’t require these or the chains under them to be disclosed to CCADB. ATT-WIFI, e.g., has multiple levels of these under their hierarchy. Are you only pulling preload information from CCADB (which wouldn’t preload those), or are you going elsewhere as well? Wayne: We are only pulling from CCADB right now; if we get to enforcing this, we would have to change our approach to accommodate technically constrained subCAs. These would only lose the perfoamcne benefit from preload, though. Ryan Sleevi: What would be the behavior for CRLite if they’re not in CCADB but are in CT? Wayne: There’s another dimension to CT. To make CRLite work, we need to be able to pull CRLs from all CAs. So we’ll either know about the intermediates because we’ll have their CRLs, or we don’t and we won’t know. Whether we’re going to pull intermediates from CT and load them into CRLite, we don’t know yet–I have to talk with the engineers on it. Ryan Sleevi: So CAs should be aware that performance or other issues might arise from this.

Curt Spann: On incident reporting for subCAs, if an incident happens and subCA is run by someoen else, should root issue incident report, or subCA? Wayne: Good question, and we should provide clarity. My perspective is that the root is the direct participant, so I’m assigning the incident bug to the root, but I don’t really care that much if the report comes from one or the other as long as we get a response to the bug. If there is no response, I hold the root CA accountable, but we have cases where subCAs are participating and posting bugs, and I think that’s great. Ryan Sleevi: If a subCA has an issue and files a report, is the root responsible for filing something regarding their supervision? Wayne: That’s definitely a possibility…I’d call it ‘aspirational’. I’m happy if we get *one* good incident report, honestly. There are cases of supervisory negligence, but for a one-off, I don’t see requiring that.

Dean Coclin: For all the root program presenters-In Shanghai, there was a presentation on the Chinese algorithm SM2. Has there been discussion for supporting these in browsers? Wayne: There has not been, from my perspective. I don’t believe the BRs would allow it. Mike Reilly: Microsoft hasn’t either. Dean Coclin: I’m not sure it has to be a BR issue before it’s a browser issue.

Dean Coclin: At a Europe meeting, a speaker from EU commission mentioned a meeting with browsers to talk about eIDAS and trust lists. Did that happen and were there outputs from it? Ryan Sleevi: A meeting happened; I’m not aware the commission has published the minutes, so no further comment. [Other browsers concurred]

Curt Spann: For the intermediate posting an incident report, I could see the root posting an incident report not to indicate problems, but instead to document any oversights or further controls to prevent future problems. Wayne: I’m always happy to get more incident reports, but in that case it would make sense for the root to just follow up on the existing threads on the mailer or existing incident, instead of just bifurcating into multiple incident reports. Ryan Sleevi: As a good example, the Dutch govt. PKI Overheid fits this closely, and their incident report is a good example here.

Devin O’Brien: You discussed a hard-fail for OCSP for certs. Have you thought about a policy for timeouts, and have you communicated it? Wayne: We haven’t thought about it a lot; currently it’s a ten-second fail, and Firefox has some OCSP-fetching bugs that need fixing before turning that on. Right now, the policy is either overly crazy or overly liberal, depending on your perspective.

Ben Wilson: On TLS 1.0/1.1 deprecation, we could do a white-paper or guidance paper for the rationale of the deprecation as an outreach to the community or users. That might be a good effort for the Forum as a whole to engage in. Wayne: I’d welcome it. Everyone involved in the deprecation would likely welcome all the help they can get.

Rich Smith: For the differential between Mozilla policy and the BRs on allowed ECDSA curves, I don’t recall: was there an attempt to bring that to ballot in the Forum to eliminate the differential? Wayne: I don’t know or recall, but it was discussed back in 2017. Rich Smith: Root stores are free to be tighter than the BRs, but diverging from the BRs creates issues. It would be helpful to rationalize those. Ryan Sleevi: There has been discussion about this in the past with, e.g., the P-521 curve that Chrome doesn’t support but Microsoft/Apple do. BRs always capture the floor of the industry, but others are free to raise the bar further. It made more sense to allow Microsoft to continue allowing it and allow CAs not to get qualified audits for using it to support them. Rich Smith: Would you consider that a mis-issuance? Ryan Sleevi: Google hasn’t stated that as a policy requirement; it just won’t work in Chrome. We would have done it as a policy requirement. Rich: So if it’s a mis-issuance, shouldn’t we fix it? Wayne: I think there’s two pieces to that. There are and will be cases where Mozilla policy goes above the BRs, and those will create a mis-issuance. I don’t see that as a problem. But I agree that if you’re setting policy to be applied broadly, we should apply that in the BRs wherever we can. Geoff Keating: One comment is that in terms of treating it as a mis-issuance, I don’t think it’s helpful for browsers to ask that certs they don’t accept be treated as mis-issued and revoked, because that prevents them from being used with other platforms that do accept and use them. As a good example, Apple does not consider certs without CT to be mis-issued or require revocation for them-we just don’t support them. Wayne: Moz doesn’t require revocation or treat them as a mis-issuance if they obey the current BRs. That’s something we should fix in our language to clarify it.

ETSI Update

Presenter:

Arno Fiedler, ETSI Member

Notetaker:

Matthias Wiedenhorst (ACAB-c / TÜViT)

Presentation: 2019-03-13-ETSI-CABFORUM-Cupertino.pdf

The main topics of ETSI works are:

Update to CA policy requirements
PSD2

The website “eid.as” is available with information about eIDAS, including a browsable version of the EU trust list.

Arno gave an overview of the latest ETSI document landscape. (see presentation)

Qualified certificates under PSD2

PSD2 regulates the electronic interconnection of banks for the exchange of information
Qualified website authentication certificates (QWACS) are utilized for mutual authentication of the bank prior the exchanging sensitive information.

Supplements to ETSI EN 319 403 are under work. The supplement ETSI TS 119 403-2 is about audit reporting for publicly-trusted certificates. Amongst others it will explicitly require the disclosure of non-conformities in the audit attestation letter.

New activities are arising around the following topics:

Quantum-safe cryptography
Crypto-agility

ETSI is engaged in activities on the global acceptance of European Trust Services

Study report: Analysis of international communities adopting PKI technology
Workshops to be held this summer in Dubai, Tokyo and Mexiko City
TSP Day in Berlin on September 25th/26th

ACAB’c Update

Presenters:

Matthias Wiedenhorst, ACAB’c / TÜViT
Philippe Bouchet, ACAB’c / LSTI

Notetaker:

Arno Fiedler, D-Trust

Presentation: CABF_ACAB-c_presentation_March2019.pdf

ACABc the “Accredited Conformity Assessment Bodies’ Council” is the Association of Certification Audit Bodies in Europe. It’s main goal is to harmonize amongst CABs a comparable/standardized application of the conformity assessment requirements by different CABs in respect with the REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (eIDAS).

Members provide conformity assessment of TSP based on ETSI standards. ACAB Members Trusted by accreditation based on ISO standards (ISO 17065, ETSI EN 319403).

ACABc cooperates with ENISA, ETSI, CEN, CA/B-Forum, FESA and the European Commission. ACAB’C has 5 members, certify one third of all European qualified TSPs (100/300) ACAB’c members conducts certification in nearly half of the European countries where we could find qualified TSPs ACAB now produces position papers on Dealing with minor and major non-conformities, Sampling of registration authorities; Audit time calculation and Attestation letter template (CAB/Forum)

Even if accredited against the same standard, CABs follow their own certification scheme. Acab’c is proposing unified procedures to have a single certification scheme at European level compliant with appropriate ISO standards. For any further question and membership criteria please contact: Secretariat Armelle Trotin + 33 608 675 144;

WebTrust Update

Presenters:

Don Sheehy, CPA Canada
Jeff Ward, WebTrust / BDO

Notetaker:

Karina Sirota, Microsoft

Presentation: Webtrust – CABF update March 13, 2019 FINAL.ppt

Webtrust Update:

ETSI and Webtrust met in Shanghai and Berlin
Discussed schemes, technical requirements, auditor requirements, reporting, SWAT Analysis, disclosure of testing and sampling, working together in the future
Webtrust Docs
Updated to newest versions
Reporting links included in ppt
Lifecycle updates
Rootkey Generation Ceremony Report (Birth Certificate)
New – Key Protection (Provides assurance that once a key is created and up to the point it is moved into production, it was properly safeguarded.
Point In Time (As of date for testing the design and implementation of controls)
Period of Time (Same as Point in Time, but also tests transactions over a period between 2-12 months to ensure they are operating effectively)
New – Key Transportation, Migration & Destruction (under development)
Webtrust for RA
Draft completed
Couple of templates to be able to monitor for different customers
Likely available April 1st, 2019
Practitioner Guidance
International versions created
Want to share best practices
End of year availability
SOC2-Like reporting
Some browsers want more info
Overall audit results
Details on the policies and controls tested
Detailed testing results
CP/CPS info not in the System Description. SD will only have references to CP/CPS
Highlight critical information
Client will distribute to browsers
Should complete Q1 2020
Lifecycle reports
Regular reports based on various event scenarios
Total cradle to grave for keys
Enhancement of CPACanada
Replaced webtrust.org with CPACanada.ca
Webtrust.org doesn’t have good security protocols anymore
Redirection of old pages
Applications for auditors
Segments of applications for different sections
More questions and documentation for auditors
Issued a certification trademark agreements
Seal application for auditor
New Seal Deployment is under development
Improved Rigor on expired seals
Working with browsers to work correctly
Questions
How will the reporting get to the browsers?
Browser community will decide when they want the SOC2 report. Testing is all the same, but reporting is different. This will be used on customer requests and probably not used all the time
Does a period of time audit have all the same detail of the point in time audit and check of operations?
Yes
Does a period of time audit still comment on a control, even if it isn’t being used?
Yes, they still do everything.

WebTrust for RAs

Presenter:

Tim Hollebeek, Digicert

Notetaker:

Dimitris Zacharopoulos, HARICA

This document intends to describe the RA functions and associated Controls for TLS Certificates, that CAs may choose to delegate to third-party entities. These functions are more related to Identity Validation and not Domain Validation.

For example, the CA might be operating in the US and use an RA in China.

It is an improved way to know what external RAs do.

Ryan mentioned that the WebTrust for RAs is untested but CAs could require this type of reporting to have better idea of the operations of their delegated RA. He also raised some concerns related to liability and cost of these additional audits.

ETSI and WebTrust may be in the same area with current practices for cases where an auditee doesn’t perform parts of the BRs.

How would it work for ETSI? Can an RA get an independent report under their name for ETSI audit for a smaller scope (for example identity validation)? Arno and Matthias provided an example of the “post office” entity which can get a report that can be used by the TSP. In ETSI this is already performed by scoping the audit appropriately to include only particular operations that are evaluated and this is reflected in the audit report and attestation.

The reporting of these audits would be nice to evaluate if they are made public.

Dimitris said that HARICA had done some research on how that would work in practice and the TSP would request an ETSI limited-scope audit for RA.

It would be nice if this process was normalized by the ACAB’c or ETSI, for example any use of DTP must have a public report describing which controls were evaluated to assess a particular external registration authority. This seems like a reasonable path forward from the ETSI side.

It seems like a safe space to encourage it but not risk qualifications for CAs if there is a DTP failure due to WebTrust for RAs.

This topic needs more discussion, maybe create some root program expectations and in case of failures, require disclosure with details and problems that were discovered in external RA functions.

Report from SCWG Validation Subcommittee

Presenter:

Tim Hollebeek, Digicert

Notetaker:

Tim Shirley, SecureTrust
Expert now imported and tags being added smoothly for IETF registries for RFC 6844 CAA property tags
Discussed redirects but no ballot yet. Will likely be part of method 6 ballot, which is next on the agenda
Gave overview of changes made since 1 year anniversary of VWG summit in Herndon. Made improvements to most methods and created new validation methods.
DNS Change methods have not yet been changed, but there are not many suggestions there.
Methods 9 and 10 still need attention.
Validation summit document created last year has lots of good history.
Trello board is also a good way to keep up with what’s going on, as well as monitoring the mailing list.

Demo how to create a ballot and red-line version on GitHub

Presenter:

Wayne Thayer, Mozilla

Notetaker:

Dimitris Zacharopoulos, HARICA

Wayne walked the members though the process documented on the wiki . He was able to create a red-line within minutes with very few steps. The goal is to make this guide as simple as possible.

In case members want to try out this process and encounter problems, please contact the Chair or Vice-Chair or any othe member that is more familiar with GitHub for assistance.

Adjourn Server Certificate Working Group Meeting for the day

Plenary Meeting Day 2 (Thursday March 14, 2019)

Call to Order – Resume Server Certificate Working Group Plenary Meeting

Attendees on March 14, 2019: Adam Sink (GoDaddy), Aleksandra Kapinos (Certum), Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Bailey Basile (Apple), Ben Wilson (DigiCert), Bruce Morton (Entrust Datacard), Chris Bailey (Entrust Datacard), Chris Kemmerer (SSL.com), Corey Rasmussen (OATI), Curt Spann (Apple), Dave Blunt (Amazon Trust Services), Davut Tokgöz (E-Tugra), Daymion Reynolds (GoDaddy), Dean Coclin (DigiCert), Devon O’Brien (Google), Dimitris Zacharopoulos (HARICA), Don Sheehy (CPA Canada), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Eva Van Steenberge (GlobalSign), Fotis Loukos (SSL.com), Frank Corday (SecureTrust), Geoff Keating (Apple), Gordon Bock (Microsoft), Hwai-Ling Shan (Chunghwa Telecom Co. Ltd.), Iñigo Barreira (360), Jason Cooper (Microsoft), Jeff Ward (WebTrust/BDO), Jeremy Rowley (DigiCert), Joanna Fox (GoDaddy), John Noll (Apple), Jos Purvis (Cisco), Josselin Allemandou (Dhimyotis (Certigna)), Karina Sirota (Microsoft), Kathleen Wilson (Mozilla), Li-Chun Chen (Chunghwa Telecom Co. Ltd.), Lin Feng (CFCA), Marcelo Silva (Visa), Matthias Wiedenhorst (ACAB-c / TÜViT), Mike Guenther (SwissSign), Mike Reilly (Microsoft), Nur H. Kuran (E-Tugra), Philippe Bouchet (ACAB’C/LSTI), Rachel McPherson (TrustCor), Rich Smith (Sectigo), Robin Alden (Sectigo), Romain Delval (Dhimyotis (Certigna)), Ryan Hurst (Google), Ryan Sleevi (Google), Scott Rea (DarkMatter), Somer Shively (Cisco), Tad Kaburaki (Amazon Trust Services), Tadahiko Ito (Secom), Tim Callan (Sectigo), Tim Hollebeek (DigiCert), Tim Shirley (SecureTrust), Trevoli Ponds-White (Amazon Trust Services), VijayaKumar Manjunatha (eMudhra), Wayne Thayer (Mozilla), Wei Yicai (GDCA), Wojciech Trapczyński (Certum), Xiu Lei (GDCA), Yuu Hidaka (Secom), Zhihui Liang (360), Mads Henriksveen (Buypass), Mike Agrenius Kushner (PrimeKey), Kirk Hall (Entrust Datacard).

Recap of Preliminary Matters, Logistics, Antitrust Statement, Assign Minute Taking

Report from SCWG Network Security Subcommittee

Presenter:

Ben Wilson, Digicert

Notetaker:

Tim Callan, Sectigo
Met Tuesday (committee meets every other week)
Have taken parallel approach to revising network security requirements with three legs
Document structure
Threat analysis
Pain points (includes Access and Authentication subgroup)
On Tuesday we discussed document structure and statements of principles followed by requriements to better address concerns of the WebTrust task force
The committee will look at other standards and how they organize their requirements (such as PCI and WebTrust requirements)

S/N Entropy

Presenter:

Jeff Ward, BDO, Various

Notetaker:

Bruce Morton, Entrust Datacard
Auditors asking what the root programs are expected to see if they audit that a CA did not revoke within the 5 day requirement
Randomness in certificates serial numbers was introduced to mitigate hash collisions.
Some CA’s have issued 63-bits serial numbers instead of 64-bits. DigiCert does not see any security risk.
Google will not discuss this issue; however, CA’s may be responsible to assess their issue, provide miss-issue report and take actions.
The question was asked, how will the auditors assess the issue, if the CA does not revoke? Qualification? Mozilla would just prefer to see the issues listed in an audit report. Microsoft would also like to see more transparency in audit reports. Jeff suggested auditors may list the item in the compliance report, but may not state this is a qualification.
The question was asked, are we happy as a forum to have requirements which will cause knee-jerk reactions which may provide more harm than good.
Google has a matter of concern if there is a deviation away from the BR revocation requirements. As such, transparency is required to be able to assess patterns, etc.
BRs already have a risk approach with different revocation periods based on issue.
Scott Rea states that this is not a security risk, but is a compliance risk. The service can be lined up with the type of risk.
Google states that the risk assessment should also consider the risk to the ecosystem
Dimitris suggested we could add into the BRs an assessment if the CA does not revoke after 5 days, where reports would be put on the CA website for public interest.
Concerned with only advising the browsers as other relying parties may not be notified
It would be great to have a place to discuss issues and collaborate. Mozilla forum does not appear to be a good place to collaborate. Wayne stated that Mozilla does have a code of conduct, where Wayne trys to enforce it. If someone crosses the line, please let Wayne know. The Mozilla forum was created to help the industry.
If there is a instance where the CA does not know there is an issue, then the discussion cam be anonymous to allow meaningful engagement. Also, some people have policies which does not allow them to discuss openly.
Ryan stated that there is a concern that disclosure should be per the root programs and not the BRs. It was also state that the BRs provide 24hr/5days revocation model, if the CA does not meet this model, then an Incident should be filed.
The BRs do not account for the fact that revocation could be a bad decision.
Cannot think of a way to phrase items to allow non-compliance. These are the requirements so either comply or not comply.

Update on London Protocol – Anti-Phishing, Flag List

Presenters:

Chris Bailey, Entrust Datacards
Daymion Reynolds, GoDaddy

Slot 1: Update on London Protocol (Part 1) – Anti- Phishing, Flag List

Notetaker (Part 1)

Eva Van Steenberge – GlobalSign

Recap:

London protocol named after F2F 44 in London
Project from CASC, but everyone can join.

Objective:

There is not a single objective.
Primary concern is anti-phishing.
Hoping to add more value to certificate types as a secondary objective. Reduce phishing for identity certificates.

We don’t have data on browser filters (which algorithms are used or how effective they are). The only public data that could be found on browsers is NSS Labs.

Trends:

Good job, but not perfect.
Most phishing with DV
Recently a rise in phishing sites with OV certificates. This is coming from “hosters” for the lack of a better word. Cloudflare represented 102 out of 145 of these phishing sites. For these types, represented content doesn’t have to match the certificate or the subject name in the certificate.

Different points of view:

It’s better to have something in the cert than nothing – at least there is a point of contact. These are legitimate certificates: BRs require domain control.
On the other hand: It is confusing to consumers.

Should we address this issue? Possible options:

We can ignore this issue
We can try to do some sort of content mapping?
Some self disclosed information that they are representing the content of the site, or that they are a hoster – this can be then monitored?
We should start talking about this.

Methodology for phishing detection:

different feeds. Adding more content (e.g. Phishlabs)
Would be great if we could get content from other providers. Google doesn’t share the actual site – so we can’t see what sites are dangerous, unless we submit the site to safe browsing via signature match.
We double check against google safe browsing.
Collect a whole bunch of data, including screenshots and certificate data and other stats. Flag list. We could use more data.

What do we do?

Contact CA, some of these sites are online for a long time.
CA contacts customers. We help the customer to remove that problem.
Further monitoring for 30 days
Phishing sites during the lifecycle of the certificate, not just at issuance.
CA has contact information. Customers like it when we call.
Re-iterate who’s in: see slide. Ayone who can join can join, you don’t have to join CASC.

Any questions?

Q: Who sends the email to CAs?

A: automated through a system called physhbank.

Q: Most of the problem is DV, so it misses most of the problem?

A: We were worried that phishing was being associated with EV and OV. So we are addressing that. Also, the follow up action is that the CA contacts customer. This requires that the CA has contact information. Without contact information, it’s hard to get that resolved. It’s a very complex system, but it will allow CA to get the problem reports that they need to handle the situation.

Q: Do you have to sign up to London protocol to participate in this system?

A: Yes. This is a north star. You are contributing to the concept of going further than the baseline. Some thing might work, some might not.

Q: Is it appropriate that this is linked to certificates? Domain registrars offer this as part of their offering. Is this just an value add service or do you suggest it will required for certificate services?

A: It is a value add. What we are concerned with is, we want to know if there is a value in offering this service to the greater community. That’s why we try to see if this works in a broader context. In DV, the results might be limited. But if a CA would like to do this, they could use this to monitor DVs also. Shocked at EV and OV level phishing (how low) – maybe not enough data, or maybe it is a reality. Yet there is an increase in OV phishing.

Discussion point: Probably inherent to the type of certificate. DV doesn’t require an email contact. As a value add proposition it is good. Some of the input data sources are lower quality of review. That’s why something like safebrowsing exists. There is a risk in normalizing this. And it gets complicated to mandate this. Problems with offering this as a baseline.

Reply: Trying to make this organic, trying to get more data, trying to improve. In a centralized system, this may work. We are trying our best to move this forward. It is difficult to coordinate. And this is all based on feedback from customers. Data we have so far, it might be too early to tell, but it seems worth the effort, and could be successful if we continue working on this.

Discussion point: Each source has a list of trade-offs. CAs are in an excellent position to provide this as a service, but it’s not a certificate problem, there’s no necessary correlation between content and certificate. How can this be made audit-able?

Reply: Some of these commercial sources already use certificates to determine if a site is phishing or not. Discussion point: This is not related to the issuance of the certificates or related to domains even. Great if CAs want to provide this to users. At the same time, this is not a baseline requirement thing. It’s just not on that end. Is this about promoting a particular product?

Reply: We hope CAs make this a requirement, we need more data. We are not just doing this to make certain CAs look better, we are trying to improve the eco-system. We are not closing it down to one system, we are expanding. And it’s not a stagnant thing. Be proactive in trying to find these sites?

Q: Do you expect to have a discussion about this the next F2F? A: It really is a valuable service because CAs have contact with customers. Is this just promotional, or is this something worth tackling on a CAB Forum level? Doesn’t seem to align with what we are doing as a Forum?

A: A lot of people would like to continue to improve. It is not ready to go. It’s a north start, trying to see what we can do to improve it (ecosystem).

Notetaker (Part 2)

Robin Alden, Sectigo

What is the flag list? It Provides a list of organization names or domain names.

Updating the list from various trusted sources, e.g. OFAC.

The list is of entries where you should be cautious. It is not a ‘do not issue’ list.

01: the policy piece around timing out entries is still being developed.

OFAC .. Flag02 CA reported an issue – bad guy trying to get certs.

Flag03: – Adam Please review and contribute!

(demo of using the API) java swing app on AWS.

There is code deploy thingy, auto-deploys to beanstalk.

Q: Are the reasons going to be standardized. e.g. all I care about is OFAC. Can I get just the OFAC entries. A: It’s extensible, sure we could do that. Just CA and common_name so far. Q: Will you have guidance on how entries should be formatted? A: Today is free-form. Happy to apply structure.

Dimitris: Is history maintained? A: Yes, everything logged. can pull log entries. helps us find that xyz.com went to godaddy first, then to CA B, then CA C, etc.

Rich: OFAC checks, only required for CAs in the US. CAs in other countries may or may not care. Can we filter out the entries I don’t care about? A: Not today, but good feedback and can incorporate.

Audit requirements over the lifecycle of a Root CA

Presenter:

Wayne Thayer, Mozilla

Notetaker:

Ben Wilson, Digicert

Presentation: Audit Lifecycle Proposal.pdf

Wayne took parts of the EV Guidelines and BRs where are audits are discussed and made suggested changes to them. He reviewed the problem statement presented in Shanghai. Currently, if a new root key pair is generated, then the requirements talk about a root key generation report, but then time goes by before Mozilla gets the request for public trust. Mozilla gets requests for roots generated in 2008, etc., so many things could be going on with root key between generation and presentation of the root CA for public trust. The CABF guidelines don’t provide much detail about what is required. Another situation is when the CA ceases issuing publicly trusted subscriber certificates. Let’s say the root is embedded and there are no clear requirements for audits at that point. So, he’d like the audit requirements in these situations to be clarified.

Slide 3 – Wayne reviewed a timeline, presented also in Shanghai, of CA key and certificate creation (on the top side of the timeline) and the audit milestones (on the bottom side of the timeline). The timeline shows Point-in-Time Readiness Assessments (PITRAs), Point-in-Time audits (PIT), and Period-of-Time (POT) audits. From earlier discussions at the F2F, a POT adds on to PIT the practices. (In ETSI, the PIT audit is really a one-day assessment.)

BRs and EVGs talk about PITRA, and there is no public audit statement or report for these. Dimitris added that in ETSI there is a pre-audit that provides a gap analysis similar to a PITRA. (One of Wayne’s objectives is to clarify terminology.) The point is that these preliminary assessments and key generation reports are not public documents. There is also an issue with what is meant by publicly trusted certificates (when they are “soon-to-be” publicly trusted certificates).

Slide 4 – From Mozilla’s perspective, continuous audits are required from key generation all the way until all certificates are revoked or expire. Where that gets messy is, for example, when Mozilla gets a BR audit for the first time in 2017, even though the key and certificate were created years before.

Slide 5 – Proposals include:

Require continuous period-of-time audits from the time the key pair is created until the root(s) expire EV audits can still begin prior to issuing first EV certificate so long as no EV-capable certificates issued PoT audits required even when there is no active issuance

Don noted that you can get a PoT audit, even when you don’t have active issuance, it just makes it difficult to test some controls. So, the audit report would discuss design, implementation and effectiveness, but there would be a large disclaimer paragraph in the report that said that certain controls could not be observed, etc., etc. Generally, you need 2 months of active issuance, but a different type of non-WebTrust report, an AT-C 105, could be created.

Wayne noted that a PoT audit, even when there is no issuance, examines the effectiveness of controls, and it also is attesting to the protection of the keys in a way that is not provided by a PIT audit. This would apply to protection of the keys themselves, regardless of even whether a root CA certificate had been issued, because that is what you are trying to protect. This would also apply as long as you are keeping a root certificate trusted in the browser. But EV audits would fall under the first bullet.

Resolve “test certificate” confusion by replacing “Publicly-Trusted Certificate”
Clarify current requirements for audits of new roots created by existing CAs
Replace “PITRA” terminology with PiT audit

Slide 6 – Change #1 – Continuous Audits

This requirement will likely have to be phased in for some roots.

Slide 7 – Simplified Timeline

Potentially eliminating the Point in Time Audit because a Period of Time audits would be in place.

The issue that is most difficult is, if you have audits, you also have to get PIT audit report, so maybe the PITRA shouldn’t be required. Mozilla would still need an audit report to go on prior to approving public trust. Don said that a PIT audit wouldn’t be needed unless the company is creating a new system or another branch with different controls, then it would require it.

The requirement would be that you have a current period of time audit report prior to issuing your first publicly trusted certificate.

Robin asked whether the BRs already require this. They say that if the CA doesn’t have a currently valid period of time audit report, then …. Wayne said that he was discussing CAs that don’t have one under his proposed language, so Robin had a point.

Arno said this is a startup situation, where the CA or data center isn’t already under audit.

Ryan S. said that Wayne’s change does away with the PIT and replaces it with a contiguous set of period of time audits beginning from the root creation ceremony.

Ben presented a hypothetical that if you had an HSM and four years ago you created 20 root keys that was witnessed by an auditor, but if you’ve only used 10 of them, then what is required for your contiguous Period-of-Time audits? Wayne said that for existing roots, they could be grandfathered in. Maybe for the unused keys we require proof that the keys were generated and protected, or just require that new ones be created. Currently, keys themselves don’t show up on audit reports, but that is another issue that we’ll have to address.

Dimitris said he thought another reason for not requiring full contiguous period of time audit reports after key generation was that it would expensive. He asked if a smaller report period of time report could be used. Wayne responded that a key protection report with a smaller scope, mentioned by Jeff Ward, could be obtained. ETSI auditors have been asked to look into this as well. Ryan noted that there are two aspect to period of time audit reports– the time duration and the scope of the audit. ETSI is also looking at normalizing controls so that only the relevant controls are covered.

Slide 8 – Change #2 – “Test” Certificates is being used in this slide in a different sense than that of the BRs. Here, in this presentation, it refers to the test websites that CAs have to set up under section 2.2 An edit to section 8.1.1 would allow these certificates as exceptions before you’re actually publicly trusted. Wayne would like to remove “publicly trusted certificate” from this provision and provide cross-references to other sections.

Robin asked whether it would be OK to use a key that is going to end up trusted for a CA to sign a certificate for .com, before it is publicly trusted? This doesn’t do away with other parts of the BRs, but if you need to issue infrastructure certificates, then you can do that without triggering the 90-day period audit requirement which you would normally have to obtain by issuing a publicly trusted certificate. Ryan S. made a distinction between test certificates and test web sites. There is a difference between web sites provisioned for testing and test certificates. Here we are talking about the former-web sites created to test operation of certificates with application software, which fits in with the exception of OCSP certificates, which are allowed to be issued directly from a root certificate.

Dimitris suggested adding “under the CA’s domain name and organization” because the most common error is when a CA issues a test certificate to an organization or domain that it does not own or control. Wayne said he was open to more suggestions, for instance by adding, “subject to the rest of the BRs”.

Ben asked whether a CA would be able to issue certificates under this section directly under the root because sometimes we have been asked for a test certificate when we haven’t yet created an intermediate CA. (We’ve had to then create the intermediate.) Wayne said he would be open to discussing this further, but as currently written, issuing directly under the root would not be allowed. Ryan noted that it would require moving the exception to section 6.1.7.

Slide 9 – Change #3 – Clarify Requirements for Existing CAs

CAs that are under current audit are allowed to issue new CA certificates, but the problem Wayne sees is that CAs will issue a new root or subordinate CA certificate and not include it in their audit report. Even if it shows up on the next audit report, there is a period of more than a year when we don’t have proof that the particular CA is under audit or bound to any particular CPS. In other words, new CA certificates must show up on the next period of time audit report. For example, if an audit report ends on December 31st, and a CA certificate was created on that same day, then it has to be in the audit report. If that new CA is going to be operated under a different CPS, then there needs to be a separate audit for that.

Slide 10 – Change #4

Proposes elimination of the Point in Time Readiness Assessment

Slide 11 – Change #5

Proposes elimination of the Point-in-Time audit because a period-of-time audit is going to be the requirement.

Slide 12 – Change #6

Proposes to remove references to TS 102-042, which are out of date.

Slide 13 – Change #7 – for EV

Proposes changes similar to what was discussed for the BRs, such as allowing issuance of certificates for test web sites, PITRAs, and adding clarification for period of time audits, and other changes for clarity.

Questions?

Ryan asked for clarification of whether Wayne’s proposal attempts to address the situation when there is an existing BR root for 3 years and the CA decides that it wants to get into the EV business. There was previous language in the presentation from Shanghai that talked about policy OIDs. Wayne said that he intends to address this issue in these changes. More discussion will be needed on the audit procedures needed to identify when the CA first issues a certificate with an EV policy OID.

Dimitris noted that in the last slide Wayne had added the ETSI policy scope for EV in proposed changes to EV section 17.4. What about the ETSI policies that need to be added / updated? Arno mentioned that Part 2 is for QWACS. Part 1 – should be for publicly trusted, and then you can do part 2 additionally, so reference to 411-2 could be removed, according to his understanding.

BygoneSSL (Guest Speaker Session)

Presenter:

Ian Foster, Google

Presentation: BygoneSSL CAB.pdf

Quantum Cryptography (problem, need, solutions and timeframe) – assign Forum/SCWG liaison(s)

Presenters:

Dimitris Zacharopoulos, HARICA
Dean Coclin, Digicert
Wayne Thayer, Mozilla

Notetaker:

Tim Shirley, SecureTrust
Groups working on Quantum Crypto
IETF/ITU – Hash-based signatures, Hybrid certificates
NIST has 2 tracks of standardization going on, and are working to make sure that new algorithms land with FIPS support.
National Academy of Sciences has a 200 page report
ETSI active in this area for last 8 years
We should stay in touch with groups working on this, perhaps with a small group that meets regularly to follow progress. Relationship needs to go both ways.
Root store members need to be involved to meaningfully address this, as they need to implement the code to use these post-quantum certificates and they need to meet the needs of their user community.
CAs need to make sure their systems are in a position to migrate between intermediates on a regular basis, and potentially spin up new roots quickly. 10 year intermediates today drive customers to bake in dependencies on existing intermediates. Recent migration from Comodo to Sectigo issuing CAs underscored the challenges here. Being able to do this is a necessary, but not sufficient, step towards being prepared for post-quantum.
We’re looking for volunteers to lead this effort.
It’s an international effort; there is work being done all around the world. Dean reports that China is doing a lot of work in this area, and Tadahiko reports they are as well. Dean and Tim H. invite interested forum members to reach out to them if they are interested in this area.

Automatically produced PDFs from GitHub vs current document PDFs. What features are really needed?

Presenters:

Ben Wilson, Digicert
Dimitris Zacharopoulos, HARICA

Notetaker:

Wayne Thayer, Mozilla
Ben showed a PDF of the current version of the BRs that is available on GitHub and is automatically generated from the files on GitHub – under the “Overview” heading.
There is no table of contents.
Certain other formatting is missing.
It was suggested that Ben present the old and new side-by-side.
Ryan said that creating an exact duplicate is not the goal, so Ben did not display them side-by-side.
Jos said that the purpose is not to achieve a 1:1 match between the current PDFs and those produced from GitHub markdown, but to determine if anyone has concerns with the PDF created from markdown. For instance, some numbering could change.
Tim Shirley said that complex tables are the biggest problem for his use of markdown. Moving to different formatting is his solution.
Ryan Sleevi said that table formatting does change slightly when PDFs are created from markdown. Ryan mentioned that section 7.1.2 also shows some inconsistencies. Ben said that he fixed the markdown formatting in the version he was presenting.
Dimitris said let’s enumerate the issues – ToC, deep nesting…
Kirk asked about copy & paste.
Ben said that Kirk’s concern is about tabs at the end of the lines in PDF generated from markdown, which make copy & paste difficult. Ben suggested copying from the markdown, HTML, or Word versions.
Chris Kemmerer said that they use markdown for their CP/CPS and there are pain points. They export via Pandoc to Word. Word then allows addition of ToC and other grooming to produce the final PDF.
Dimitris replied that we want to fully automate the process.
Kirk asked if we can get a redline version. Dimitris replied “yes”.
Rich said that accessibility is a concern. Rich said that it’s much harder to make changes in a GitHub managed document.
Wayne said that there are two different issues: using GitHub to draft the changes and make a redline as was demoed yesterday, and using GitHub to produce the final output of a new version of a Guideline. The first issue is what was discussed yesterday. In both cases Wayne said that some documentation should be produced, but only a few members need to know how to product the final output.
Ryan said that we’re trying to automate Ben’s job. Ryan suggested that we should have sent out a copy of the produced docs for people to review in advance and comment on.
Wayne said that we tried that in the Infrastructure WG, but didn’t receive any feedback.
Curt said we should have sent out a link to the doc.
Dimitris said he doesn’t like the current PDF version, but the problems should be easy to fix.
Ryan asked how we move forward.
Wayne said that much like a ballot, we should just start using the new method once desired improvements are made and see if anyone complains.
Kirk asked if we would produce instructions for producing ballots.
Wayne said that he thinks we should do that, both for starting a ballot and managing the resulting guidelines.
Ryan said that documentation doesn’t need to delay this change, and it doesn’t need to be in the bylaws but agrees that it should be documented. Jos agreed.
Dimitris said he normally has the responsibility for creating the final version of the doc, and would be happy to change to using GitHub instead of updating the Word doc.

Update EV Guidelines to cater for alternative registration numbers (Ballot SC17)

Presenter:

Tim Hollebeek, Digicert

Notetaker:

Rachel McPherson, TrustCor

Topic: Discuss Ballot SC17

Purpose of Ballot: Allow for the inclusion of additional information in certificates in order to comply with relevant EU regulations.

Motivation behind the Ballot: Update to CAB Forum EV Guidelines to cater for alternative registration numbers caused by EU Legal Requirements:

The EU Regulation no. 910/2014 defines regulatory requirements for certificates with an agreed quality level called “Qualified”. This regulation specifies requirements for “Qualified certificates for website authentication” including the statement that the certificate shall contain: “for a legal person: the name and, where applicable, registration number as stated in the official records.”

This ballot proposal only includes the registration schemes used in ETSI TS 119 412-1, which have clear validation rules (NTR, VAT, PSD) that provide reasonable assurance in line with the EV Guidelines. Discussing the CA/B Forum’s interpretation of EV Requirements in section 9.2.8 “Other Attributes”.

Having found out that CA/B Forum’s interpretation of EV Requirements in section 9.2.8 “Other Attributes” was not in line with those understood by ETSI experts, ETSI would like to harmonise with CA/B Forum approach to carrying alternative forms of registration number for PSD2 and other registration schemes.

CA/B Forum concerns and comments:

An initial concern is that this ballot modifies some of the same sections as SC16. Therefore, it needs to comply with Bylaws section 2.4(j). Workaround suggestion:
The new sections 9.2.8 and 9.2.9 from this ballot should be placed in front of the sections from SC16 if both ballots pass, renumbering those sections as 9.2.10 and 9.2.11, and renumbering the following sections as necessary.
Ryan Sleevi – I think a particular area of concern to highlight is whether the expected selection MUST be PrintableString or UTF8String. If UTF8String, it seems we will still encounter ambiguous representations for a given identifier.
Suggestion: replace the “or equivalent” language for identifiers with “or other numbers specified by the NCA”
Ryan – make it unambiguous to the subscribers and auditors to who the qualified regulatory body is, so the language is not subjective.
Dimitris – (Pointed out that the PSD number is not produced by the CA, it is only produced by the NCA, so update the Ballot language to specify that).

Final outcome: will likely take a few more versions of this ballot to allign with the current bylaws and CA/B forum concerns.

Adjourn Server Certificate Working Group Meeting

Call to Order – Code Signing Certificate Working Group Plenary Meeting

The Minutes of the CSCWG have already been approved and by the WG and distributed via the WG’s public mailing list

Adjourn Code Signing Certificate Working Group Meeting

Latest releases

Code Signing Requirements
v3.7 - Mar 4, 2024

S/MIME Requirements
v1.0.3 - Ballot SMC05 - Feb 20, 2024

Adding CAA.