[cabfpub] Final Meeting 42 Minutes – F2F meeting, Taipei, Oct. 4-5, 2017
Adriano Santoni
adriano.santoni at staff.aruba.it
Wed Jan 10 10:15:05 UTC 2018
One question to Google people regarding this line of the minutes:
> - Q re CT: Is April finalized? A: CT policy days will finalized the
> exacts dates
Any update on that? I gather that the next CT policy days event was due
to be held in November 2017, but I cannot find information on it.
Adriano
Il 30/12/2017 03:08, Kirk Hall via Public ha scritto:
>
> The CA/Browser Forum was delayed in completing the minutes for its
> last Face-to-Face meeting Oct. 4-5, 2017 in Taipei, and the proposed
> final Minutes were only sent by the Chair to the Members on December
> 13, 2017 for their review. There was not enough time for Members to
> review the draft before the next teleconference of December 14, and
> the teleconference of December 28 was cancelled due to the holidays.
> The next Forum teleconference is scheduled for January 11, 2018.
>
> To avoid further delay in publishing the Final Minutes on the Public
> list, we are following Bylaw 5.1(a) which states that draft Minutes
> will be considered final two weeks after publication to the members,
> at which point they will be considered final and be posted to the
> Public list. The only edits offered during this two week review
> period were from the Mozilla representative, and the edits related
> solely to Mozilla’s presentation during the meeting and so were accepted.
>
> *Final Meeting 42 Minutes – F2F meeting, Taipei, Oct. 4-5, 2017*
>
> *Attendance:* Peter Bowen (Amazon); Geoff Keating and Curt Spann
> (Apple); Jeremy Shen (Central Police University); Franck Leroy
> (Certinomis / Docapost); Wayne Chan and Sing-man Ho (Certizen
> Limited); Wen-Cheng Wang, Bon-Yeh Lin, Wen-Chun Yang, Jenhao Ou,
> Wei-Hao Tung, Chiu-Yun Chuang, Chung-Chin Hsiao, Chin-Fu Huang,
> Li-Chun Chen, Pin-Jung Chiang, and Wen-Hui Tsai (Chunghwa Telecom);
> Alex Wight and JP Hamilton (Cisco), Robin Alden (Comodo), Gord Beal
> (CPA Canada), Ben Wilson and Jeremy Rowley (DigiCert), Arno Fiedler
> and Enrico Entschew (D-TRUST); Kirk Hall (Entrust Datacard); Ou
> Jingan, Zhang Yongqiang, and Xiu Lei (GDCA); Atsushi Inaba and Giichi
> Ishii (GlobalSign); Wayne Thayer (GoDaddy); Devon O'Brien (Google);
> David Hsiu (KPMG); Mike Reilly (Microsoft); Gervase Markham and Aaron
> Wu (Mozilla); Hoang Trung La (National Electronic Authentication
> Center (NEAC) of Vietnam); Tadahiko Ito (Secom Trust Systems); Leo
> Grove and Fotis Loukos (SSL.com); Brian Hsiung (Sunrise CPA Firm);
> Steve Medin (Symantec); Frank Corday and Tim Hollebeek (Trustwave);
> Robin Lin, David Chen, and Huang Fu Yen (TWCA); and Don Sheehy and
> Jeff Ward (WebTrust).
>
> *Antitrust Statement* - Read by Robin Alden
>
> *Mozilla Root Program Update - Gerv*
>
> Notetaker: Jeremy
>
> 1. Mozilla root policy 2.5 shipped. Anyone wth questions should ask
> Mozilla.
>
> 2. All s/MIME intermediate certificates must have true technical
> constraints by Nov 15 2017. Revocation of non-compliant intermediates
> must happen by April 15, 2018.
>
> 3. Non-BR cert and OCSP issues. Lots of reports of non-compliance with
> public thanks to Ryan and other reports. Mozilla looks at the severity
> of the problem along with the speed, openness, depth, and competence
> when deciding what to do. Part of the remedial action is to integrate
> checks into the issuance process that evaluate compliance prior to
> issuance. Mozilla is debating whether there will be a requirement for
> programmatic checking added to the Mozilla policy.
>
> 4. BR self-assessment. Mozilla may require CAs to perform a
> Self-Assessment to surface additional compliance issues. This is just
> a proposal at this point. Feedback is welcome. One assessment would be
> required for each CP/CPS pair.
>
> 5. CAA and CNAME. Mozilla permits the errata and non-errata checking.
> The expectation is all CAs will migrate to the errata within the next
> three months after the ballot requiring use of the errata is passed by
> the CAB Forum.
>
> 6. ONECRL. The process for adding intermediates to OneCRL is
> established. Mozilla adds a batch of non-urgent updates every 2 weeks.
> Mozilla will make more urgent updates as needed. OneCRL is only
> checked for TLS (and is not checked for s/MIME). CAs can add their
> legacy non-constrained CAs to avoid BRs. However, this is only
> appropriate for legacy intermediates. New intermediates must be
> technically constrained. Be sure to test the certificate's serial
> number before it is marked as revoked in CCADB. Many intermediates
> have similar names.
>
> 7. CA Communication. The next CA communication will occur in the
> Nov/Dec timeframe. The communication will include administrative
> notices, self-assessments, a request for CAA identifiers, a CABlint
> requirement, and refinements to the problem reporting mechanism. All
> CAs are expected to have at least one CAA identifier. There will be
> penalties for failing to add intermediates to CCDAB within the one
> week requirement. Mozilla is pondering whether each CA should provide
> an email mechanism for communications. Gerv will make a note to alter
> the report to spam proof the email addresses.
>
> 8. Aaron Wu is working towards getting all BR self-assessments
> completed. Aaron will let CAs know if further information is needed.
> Only after Aaron completes his review does a CA move to the public
> discussion phase.
>
> 9. Firefox changes. Firefox 58 will print warnings to the developer
> console for Symantec-rooted EE certs if the notBefore date is before
> June 2016. Firefox 60 will disable all these certs (due out in May
> 2018). Firefox 57 will include the first ever formally verified
> cryptographic primitive in a major browser. The implementation uses
> Curve25519 for key establishment. Gerv will consult with Firefox team
> to discuss when they will extend permitted keys to include 25519.
>
> *Microsoft Root Program Update - Mike*
>
> Notetaker: Robin
>
> Team updates: * Keri Street no longer with Microsoft
>
> * Karina Sirota hired a few weeks ago
> * should be used for communications to ensure timely response.
> Communications to CAs will come from this address as well rather
> than from individual team members
>
> Microsoft Trusted Root Program releases through Windows Update: * Most
> recent release had 43 changes. Details at
> http://aka.ms/rootupdates. Highlights:
>
> * This release will “NotBefore
> <https://www.cabforum.org/wiki/NotBefore>” 6 WoSign/Startcom roots
> per Windows Security Blog
> <https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/>
> * Next release targeted for end of November 2017
> * Govt Domain constraints: technical solution pushed out to latter
> half of CY18
> * Continued efforts toward automation of program processes to
> minimize errors and enable increased verification of program
> compliance
>
> Update on our Common CA Data Base CA Audit Letter Validation project
> (Jixi) * Purpose: CA Audit Letter Validation using Natural Language
> Processing. Accept requests from Salesforce to validate CA audit
> letter and pass results back
>
> * Status: Connected to CCADB Prod for testing and bug fix phase
> * Demo at next f2f (March 2018 in Virginia)
> * Daju project: Increase automation of the process of ingesting CA
> changes and delivering the bits needed to deploy the changes as
> part of our Windows Update process. Basically, creates a program
> dashboard for change control. Targeting January 2018 to go live
>
> Reviewing all external facing communications (e.g. websites,
> contracts) for consistency and improvement opportunities
>
> EIDAS Technical Best Practices Document status: (submitted to Head of
> eGovernment and Trust Unit for the EU) in coordination with the other
> Browsers (Mozilla, Google and Apple) * Basically, a summarized version
> of browser program requirements related to technical best practices
>
> * Receipt acknowledged but no additional feedback or next steps proposed
>
> Other areas of recent focus include: * Certificate Transparency (CT)
>
> * Building out CT Monitor as part of TRP
> * Participating in CT policy days with other browsers in November
> * Impact of CT on Govt partners?
> * DNS Certification Authority Authorization (CAA) Implementation
> o Given that CAA is now mandatory and ballot 214 is currently in
> voting period, Microsoft will give immediate dispensation for
> CAs to issue certificates following the algorithm specified in
> either RFC 6844 or RFC 6844 as amended by Erratum 5065 when
> performing the mandatory pre-issuance CAA checks. If Baseline
> Requirements are updated to require Erratum 5065 algorithm,
> then CAs will be expected to transition to this updated
> algorithm within a reasonable amount of time which may be
> specified by a follow on ballot to 214 in the CAB Forum.
>
> SHA-1 deprecation updates can be found at http://aka.ms/sha1
>
> *Google Root Program Update - Devon*
>
> Notetaker: Peter
>
> Google Chrome Program Update
>
> Devon presenting
>
> - Chrome has shipped new certificate parser on all platforms -- used
> instead of platform native parser or BoringSSL (Linux on 63 is the
> last to land)
>
> * - Q: Why did Chrome do this?
> o A: Foundational component for future work
>
> - CT: Some churn on log list. Expect-CT experimental header shipped in
> Chrome 61. Starting to take a better look at inclusion proof checking,
> both in browser and in the crawler, to help assure things are included
> in the log.
>
> - UI: HTTP Bad is continuing to roll out to mark as negative
> indicator. 62 marks as negative in incognito mode and any use form
> interaction. New paper on research.google.com on causes of TLS errors;
> data is being used to create TLS error pages. New MITM page that
> triggers on known misconfiguration page for AV and detected captive
> portals.
>
> - As of yesterday, Google has signed the CCADB agreement, so they are
> now officially working with Mozilla on CCADB
>
> - Symantec blog post is up; managed PKI discussion is continuing on
> m.d.s.p
>
> - Want to push CP/CPS to follow RFC 2527 & 3647 formats (for those not
> using either)
>
> * - Gerv comment: Mozilla wants all to move to 3647
>
> - Looking to improve incident response reporting and blameless
> post-mortem practices and increased transparency. Revocation is
> necessary but not sufficient response in many cases.
>
> - Q re CT: Is April finalized? A: CT policy days will finalized the
> exacts dates
>
> - Q on cert parser: Does it affect path processing? A: No. Still using
> securityframework on mac
>
> - Q: Have they put out final details on CT days? A: Will check with R.
> Hurst
>
> - Q: Are you confident that the CT ecosystem is strong enough to
> support April date? A: Yes, R. Hurst's team is working to flush out
> any remaining bugs on the Trillian code base
>
> - Q: Will a certificate issued with SCTs that are trustworthy at
> issuance continue to be SCT-valid if the logs are later distrusted? A:
> Policy calls out log trusted at time of issuance, not at time of TLS
> handshake
>
> - Q: Is there a single central place that has a reference list of
> trusted logs? A: Yes, it is on gstatic
>
> - Q: Will logs be distrusted retroactively? A: (Gerv) There is a
> possibility that it could happen, especially for a small period of
> time, but unlikely.
>
> - Q: Will Google work with Mozilla on best practices to avoid
> conflict? A: Yes, but these are just best practices, not specific
> requirements. A: (Gerv) I doubt there will be significant disagreements
>
> *Apple Root Program Update*
>
> Notetaker: Wayne
>
> Curt Spann -
>
> - Just released iOS 11 and MacOS High Sierra – these releases include
> the improved revocation checking mechanism that was presented in Berlin
>
> - Latest batch of improved root inclusions have been completed
>
> - Focusing on creating a CT log policy. It will include a log
> monitoring solution. Curt will be at CT policy days in November and is
> looking for community input.
>
> Peter – does slight false positive risk present in the new revocation
> mechanism still exist?
>
> Geoff – Yes, nothing has changed. We are not hearing about false
> positives. The IDP flag in CRLs does cause issues with this revocation
> mechanism – avoid IDP (partitioned CRLs) if possible. If having a
> problem with revocation on the latest version of iOS or OS X, try:
>
> • Enable OCSP Stapling (immediate)
>
> • Update CRLs (take effect with next download version)
>
> * • Publish a full CRL (no issuingDistributionPoint)
>
> • Place relevant certificates in Certificate Transparency (weeks)
>
> * • For every CA, put one cert in CT which references a full CRL
>
> • Contact certificate-authority-program at apple.com
> <mailto:certificate-authority-program at apple.com>
>
> Peter – can anything be done to eliminate a specific false positive?
>
> Geoff – no, because the certificates that trigger false positives will
> change over time.
>
> Robin – it’s generally not in the CA’s control if OCSP stapling is
> used or not.
>
> Geoff – if, worst case, you can’t get customer to implement OCSP
> stapling, reissue the cert. The new serial will solve the problem for
> that specific certificate.
>
> *WebTrust Update*
>
> Notetaker: Kirk
>
> Jeff Ward, Don Sheehy, and Gord Beal made the following presentation
> (available for download)
>
> Current Status: WebTrust for CA 2.1 is complete. Generally, sections
> added on key migration, destruction and transport that were not in
> ISO21188. V2.1 will be effective September 1, 2017. hanks to CA/B
> members for comment
>
> Details of changes in WebTrust for CAs v2.1 – Includes: Updated
> introduction section, including clarifying definitions for Root CA,
> Intermediate / Issuing CA, and Subordinate CA, and added explanation
> of a Bridge CA structure.
>
> Removed references to WebTrust v1 for Business Practices Disclosures.
> All CP / CPS documents must now be in accordance with RFC 3647
> (recommended) or RFC 2527.
>
> Updated the following criteria: • Criteria 1.1 and 1.2 –removed
> WebTrust v1 references • Criteria 2.1 and 2.2 –swapped order to be
> consistent with 1.1 and 1.2 • Criterion 3.6 –Expanded scope to
> specifically address hypervisors and network devices • Criterion 3.7
> –Expanded scope to specifically address system patching and change
> management activities • Criterion 3.8 –Clarified scope to include
> requirement for backups of CA information and data to be taken at
> regular intervals in accordance with the CA’s disclosed business
> practices. • Criterion 4.5 –Split into two criterion (4.5 and 4.6),
> subsequent criteria renumbered • Criterion 4.6 –Clarified scope to
> include destruction of any copies of CA keys for any purpose, and
> added illustrative controls addressing formal key destruction
> ceremonies. • Criterion 4.10 –New criterion added to address CA Key
> Transportation events • Criterion 4.11 –New criterion added to address
> CA Key Migration events • Criterion 6.1 –Streamlined criteria, minor
> updates to illustrative controls • Criterion 7.1 –Updated to address
> cross certificate requests
>
> Current Status – WebTrust for Publicly Trusted Code Signing: Modified
> version released to fix error in material and to remove unauditable
> criterion Removed Principle 2, Criterion 5.11 as it was determined not
> to be auditable Clarified Principle 2, Criterion 3.2 with regards to
> the signing of Subscriber Agreements Vs 1.01 effective October 1, 2017
>
> Current Status - WebTrust EV Code Signing: Released vs 1.4.1 effective
> October 1, 2017 Removed Principle 2, Criterion 5.12 as it was not
> auditable
>
> Current Status - WebTrust EV SSL: Released vs 1.6.2 effective October
> 1, 2017 Updated EV SSL Audit Criteria to conform to EV SSL Guidelines
> v1.6.2 and other clarifications, including the following: • Principle
> 2, Criterion 2.2.3 –Updated maximum EV certificate lifetime to 825
> days • Principle 2, Criterion 3.2 –Clarified signing requirements for
> Subscriber Agreements • Principle 2, Criterion 4.13 –Codified the
> requirements regarding the CA’s responsibility for verifying the
> accuracy of QIISs used for verification
>
> Current Status - WebTrust Baseline Requirements including Network
> Security Requirements Released vs 2.3 effective TBD based on CABF
> feedback Updated SSL Baseline Audit Criteria to conform to SSL
> Baseline Requirements v1.4.9 and Network and Certificate System
> Security Requirements v1.1 Principle 1, Criterion 6 –Require CAs to
> disclose their CAA Records policy in their CPS Principle 2, Criterion
> 2.14 –Clarified the requirement for Root and Subordinate CA Subject
> Information Principle 2, Criterion 4.6 –Revised age of data from 39
> months to 825 days Principle 2, Criterion 4.10 and 4.11 –New criteria
> added to address CAA Records processing requirements Principle 2,
> Criterion 4.12 and 4.13 –Renumbered from 4.10 and 4.11 Principle 2,
> Criterion 8.3 –Updated that this criterion is only effective for
> certificates issued before 11 August 2017 Principle 4 –Updates made to
> conform to CA/B Forum Ballot 210
>
> Current Status –DRAFT Practitioner Audit Report templates: Approved by
> AICPA / CPA Canada Released Sept 1, 2017 Covers nearly all potential
> types of reports (about 18 examples in each) and assertions Separate
> documents created for each governing body (US, Canadian and
> International) Needs to be followed to get the seal from CPA Canada
>
> Current Status - updating/preparing WebTrust for RAs: 2ndDraft version
> in process Will have main principles similar to WebTrust and
> additional principles (appendices) for Baseline Requirements including
> Network Security Requirements and for EV Strength of controls will be
> an issue Reporting alternatives being discussed including SOC2 like,
> public report and impact on CA report
>
> Current Status – IN PROCESS: Practitioner guidance for auditors Under
> development covering public and private CAs. Draft expected early 2018
>
> Some Old and Some New Issues: WebTrust for CA reports –should a more
> detailed version be created similar to SOC 2 (limited distribution/no
> seal) or report with detailed system description and controls Cloud
> questions continuing to surface -perhaps WT for RA will help lay
> groundwork for other delegated third parties
>
> CPA Canada Now: Gord Beal, Bryan Walker, Kaylynn Pippo (maternity
> leave), Lori Anastacio, Janet Treasure. Consultant to CPA Canada: Don
> Sheehy (Vice –chair) Task Force Members and Technical Support Volunteers
>
> Task Force Members and Technical Support Volunteers: Jeff Ward
> (Chair), BDO; Daniel Adam,Deloitte; Chris Czajczyc, Deloitte; Tim
> Crawford, BDO; Reema Anand, KPMG; Zain Shabbir, KPMG; David Roque, EY;
> Donoghue Clarke, EY.
>
> Reporting Structure/Roles: Gord Beal –WebTrust falls into Guidance and
> Support activities of CPA Canada Janet Treasure –Seal system
> responsibility Bryan Walker –Licensing advisor Don Sheehy -Task Force
> and CABF Jeff Ward -Chair of the WebTrust Task Force and primary
> contact All Task Force members provide WebTrust services to clients
> Volunteers are supported by additional technical associates and CPA
> Canada liaison but report to CPA Canada
>
> CPA Canada activities Auditor list updated More formalization and
> support in seal issuance and licensing processes.
>
> Questions: Gerv noted there had recently been a question about changes
> in the BRs (relating to CAA implementation) that presented technical
> problems, and which might result in some CAs receiving Qualified
> audits, even though they were trying to comply with all BR and audit
> requirements. He observed that there may be a benefit to the current
> lag time between when changes are adopted in the BRs and when they
> appear in the BR WebTrust requirments, because issues in the BRs can
> be fixed before they find their way into the BR WebTrust requirements.
>
> Others commented on this issue, and expressed the following points of
> view:
>
> • The BRs presently require CAs to follow the most current version of
> the BRs, and to promise they are doing so in their CPS – whether or
> not the changes to the BRs are included in WebTrust for BRs. This
> could create a problem. Gerv thought it might be good to remove that
> requirement from the BRs and only require CAs to follow the current BR
> WebTrust requirements, as those were the only requirements that are
> actually tested and reported to the browsers and public. In that way,
> browsers can give CAs special and temporary dispensation to not follow
> certain problematic BR changes before they are incorporated in the
> next WT BR release.
>
> • There was discussion of whether a CA could face an audit problem if
> there is a mis-match between the BR requirements and the current BR WT
> requirements. The auditors said it would depend on the level of
> importance of the issue, and in some cases the auditor might simply
> comment on the issue in the audit report but the CA would not be at
> risk of failing the audit or even receiving a qualification.
>
> • The browsers don’t want these ballot problems to occur often, so the
> Forum should try to avoid ballot problems like what occurred with
> Ballot 214 regarding CAA errata. Gerv pointed out that the problems
> with CAA and the ballot only became obvious at a later date.
>
> • Jeff Ward noted there will always be a delay in getting changes in
> the BRs into a new version of the BR WebTrust requirements. Gerv noted
> that browser root program requirements (including special and
> temporary dispensation from BR compliance) can be done more quickly
> and easily than updating the BR WebTrust requirements.
>
> • Wayne thought this problem could be solved in part by new and better
> effective dates in the ballots themselves
>
> • Curt asked how browsers could be assured that CAs are following the
> latest BR requirements if they are not covered by the latest BR
> WebTrust requirements. Gerv noted that some requirements are external,
> and non-compliance can be observed by the browsers.
>
> • Devon noted that auditors are in the best position to know if a CA
> is in compliance – browsers generally can’t check for compliance.
>
> • Gerv emphasized that the conversion of BR changes to new BR WT
> requirements is a process (including determining what in the BRs is
> auditable), and so can’t always be speeded up.
>
> • Don noted that when the EV requirements were created, the Forum went
> created a long list of Errata to correct the early versions of the EV
> requirements, and the WebTrust auditors were not required to change
> the audit requirements on a weekly or monthly basis – the audit
> criteria were more stable then, which was better.
>
> • Kirk said if Gerv had ideas on changes to make to the BRs to deal
> with these issues, he should propose them Gerv said he would move
> forward with suggestions.
>
> *ETSI Update*
>
> *https://portal.etsi.org/TBSiteMap/ESI/ESIActivities.aspx*
>
> Notetaker: Enrico
>
> Arno presented an Update on the ETSI Working Group ESI: (Electronic
> Signatures and Infrastructures)
>
> ISO 17065 is one of the foundations of the ETSI Certification Policies
> based audit scheme. Caused by the eIDAS Regulation an European
> accreditation system is incorporated into the audit scheme. There has
> been the need over the past few years for a better way to know who is
> accredited as an auditor for ETSI CP, because ETSI is an official
> standardization organization that does not oversee audits.
>
> The accreditation scheme is not person-based, it is accreditation of
> the auditing body – the Conformity Assessment Body (CAB). The CAB is
> responsible for the quality and skills of the auditor and the quality
> of their work. In Europe, at the top level, there is the European
> Accreditation Authority (http://www.european-accreditation.org
> <http://www.european-accreditation.org/>). A CAB must conform to the
> ISO 17065 and must be accredited to audit pursuant to ETSI 319 403. To
> verify whether the CAB is accredited, you can request its
> accreditation certificate, and the certificate will need to reference
> the applicable standards for which the CAB is accredited. The ACAB’C
> is now an organization that cares about the quality of the auditor.
> ETSI has created a detailed audit check list for auditors who audit
> CAs, the check list includes more than 300 specific controls.
>
> Standards are available for download at
> http://www.etsi.org/standards-search. The most important standard for
> this group is EN 319 411-1 . End of October 2017 an actual version
> will be published.
>
> *Governance Working Group Report*
>
> Notetaker: Ben
>
> During the Policy Review Working Group meeting we went over a proposed
> change to the definition of Certification Authority. It would be
> amended to read, “a technical certificate generation service that is
> trusted by one or more entities to create and revoke or hold public
> key certificates and is operated by a Trust Service Provider.” And
> after that discussion, we received a comment from GDCA that they would
> like it to refer to a “logical entity”. GDCA was going to post
> something to the list to clarify this request. GDCA clarified that the
> request was so that the definition of a CA was not limited to a
> service, so that it could be an organization. Ben said that the
> “organization” part is under the last part of the definition that
> mentions “Trust Service Provider” and that he had misunderstood GDCA’s
> request. Ben said that we could say “a logical entity or service”, or
> we could leave the definition as proposed. Ben noted that the
> definition was a combination of ETSI and ISO definitions crafted by
> Peter Bowen. Peter said he didn’t mind having “logical” in the
> definition if it would help non-native-English speakers. It was agreed
> that further discussion on the public email list would be of benefit
> to everyone on this issue. Dimitris said that he had the definition in
> an email from September 14 that could be referenced, and Ben said that
> he had forwarded that email to GDCA. Kirk suggested that they provide
> examples of the logical relationship to make it clearer for people to
> understand what is being proposed.
>
> Another topic discussed was a review of the Baseline Requirements and
> the use of the word “CA” to determine whether we’re talking about the
> organization or the logical entity / service that signs and revokes
> certificates. The relative frequency of places where “CA” will remain
> is high when compared to places where we would replace CA with Trust
> Service Provider.
>
> Dimitris noted that during the discussion on Tuesday we also focused
> on “trusted by one or more entities” in the proposed definition and
> whether it should say “trusted by Application Software Suppliers.” Ben
> said that you could word it by leaving that phrase out and saying
> “trusted to create and revoke” or “trusted by subscribers and relying
> parties” because Application Software Suppliers are acting as agents
> for relying parties. Dimitris said he is fine with the definition as
> is. Ben noted that the next speaker had joined and that we should take
> the topic offline and continue it during the next call or on the
> mailing list.
>
> Finally, Ben noted that in reviewing the use of the term “CA” he
> identified an inconsistency between the Baseline Requirements and the
> EV Guidelines. In the Baseline Requirements section 7.1.6.3 we talk
> about use of the anyPolicy policy OID by an “affiliate of the Issuing
> CA” whereas in section 9.3.4 of the EV Guidelines we say it may be
> used for a subCA “for which the corresponding Private Key is
> controlled by the Root CA.” Ben said he prefers the usage found in the
> EV Guidelines. It was suggested that with the modified definition of
> CA, section 9.3.4 of the EV Guidelines could even be edited to read,
> “(2) Certificates issued to Subordinate CAs that are operated by the
> same Trust Service Provider as the Issuing CA MAY contain the special
> anyPolicy identifier (OID: 2.5.29.32.0).”
>
> *CCADB Update and demonstration*
>
> Notetaker: Mike Reilly
>
> • Purpose: Common CA Database (CCADB) Demo was presented as a result
> of CA feedback and questions on use of the database.
>
> • Demo started with an overview of the “Information for CA” page.
> Aaron walked through the process of creating a new audit case and how
> it’s tracked in the dashboard. New audit cases are based on CA
> information. Currently a manual process is used to validate this
> information, but validation will become automated soon as part of the
> Jixi project mentioned in the Microsoft update
>
> • Question asked: Will the CCADB replace Bugzilla? No, currently
> Bugzilla pulls reports from CCADB to provide info to CAs and others.
> Microsoft, Mozilla and Google use this CCADB (Google just announced
> they are joining it) to track CA information in support of their root
> programs. Apple is looking to use it as well and is going through
> legal review to start using it.
>
> • Auditors would like to see the CCADB data as well. Follow up:
> Kathleen to discuss with Microsoft and Google to see how we may do that.
>
> • A new field has been added that shows auditor information and allows
> for easy add of auditor from a drop-down list
>
> • Audit statement (PDF) is added and audit type is selected along with
> audit date. Audit date cannot be more than 90 days past the end date.
> If a CA has a reasonable reason why they went past 90 days they can
> add comments
>
> • Question asked: can the file name for audit document URL be the same
> each year? No, since we require new filenames/URLs for audit statement
> each year, please have CAs to use a new filename for a new document
>
> • CAs should list all certs in the CCADB that way browsers can cross
> reference and the CA has less data input requirement overall to get
> info to browsers using CCADB
>
> • Question asked: One CA had to upload the same audit document
> multiple times for multiple roots and wondered if there was an easier
> method. Answer was that CA still need to create multiple roots under
> one Audit Case if audit document is the same one, and CA can create
> multiple audit cases for different audit statements.
>
> • Positive comments by a few folks as to the good design and ease of
> use for adding audit documents
>
> • Are the dashboard tools available to the CAs? (EKU Management, Audit
> Standards, etc view). Those views are part of the “Jixi” project
> Microsoft mentioned in its update and will be demonstrated at the
> March f2f CABF meeting. Mike to take action to update CAs on what
> views and reports Jixi will provide for their use
>
> • Question: Any plans for adding submission APIs so it’s easier for
> CAs to add their information? Answer is NO, so far CA still need to
> create each case/root case one by one, no API supported for now.
>
> • Question: Will “bulk load” capability be available? CA would need to
> get in touch with Kathleen if this is needed. It was used initially to
> get all CAs onboarded
>
> • There are also detailed instructions on the CCADB site should CAs
> want to follow up on how to use the CCADB (Gerv comment)
>
> *Guest Speaker: Jonathan Levi - Hyperledger Fabric Project 1.0 update
> and usage of x.509 v3 certificates*
>
> *Approve Minutes CABF teleconference Sept. 14, 2017*
>
> The Minutes were approved, and will be posted to the Public list.
>
> *Determine Applicability of Certificates by using standard CABF CP OIDs*
>
> Notetaker: Li-Chun Chen
>
> Dr. Wen-Cheng Wang changed his presentation title from original "Using
> CP OIDs instead of Extended Key Usage to distinguish different kinds
> of Certificates" in meeting agenda to "Determine Applicability of
> Certificates by using standard CABF CP OIDs" Determine Applicability
> of Certificates by using standard CP OID.pdf
> <https://www.cabforum.org/wiki/Meeting%2042%20Minutes?action=AttachFile&do=view&target=Determine+Applicability+of+Certificates+by+using+standard+CP+OID.pdf>.
>
> At first Wen-Cheng asked the audience that: When a certificate-using
> software (such as a browser) encounter a SSL certificate or a
> code-signing certificate that is chained up to a trusted Root CA, how
> does it determine whether the certificate is issued by a Subordinate
> CA that conforms the applicable CA/Browser Forum guidelines?
>
> He said: Currently, there is no systematic and automatic way to check
> this applicability.
>
> In the slide page 3 about Mis-issuance by Unconstrained CA, The PKI is
> WebTrust <https://www.cabforum.org/wiki/WebTrust> for CA Audited.
> SubCA 1 is WebTrust <https://www.cabforum.org/wiki/WebTrust> SSL BR
> audited. So SubCA1 can issue OV/IV SSL Certificates. SubCA2 is
> WebTrust <https://www.cabforum.org/wiki/WebTrust> EVCS audited. So
> SubCA2 can issue EV Code Signing Cert. SubCA3 is not “WebTrust
> <https://www.cabforum.org/wiki/WebTrust> SSLBR” audited or “WebTrust
> <https://www.cabforum.org/wiki/WebTrust> EVCS” audited. SubCA3 could
> mis-issuse SSL certificates or EV Code Signing certificates unless all
> SubCAs are “Technically Constrained”. In the slide page 4, Wen-Cheng
> discussed some application software use EKU Chaining in Sub CA
> certificates and EE Certificates to let SubCAs to be "Technically
> Constrained".
>
> Using EKU in Sub CA certificate is controversial. The section 4.2.1.12
> of RFC 5280 says “In general, this extension will appear only in end
> entity certificates.” Both ITU-T X.509 and RFC 5280 say nothing about
> the semantics if this extension appeared in CA certificates.The is no
> EKU Chaining (a.k.a. EKU nesting) in the standard certification path
> validation procedure define in both ITU-T X.509 and RFC 5280.
>
> Wen-Cheng reminds that the X.509 standard and RFC 3647 define a
> Certificate Policy (CP) as "A named set of rules that indicate the
> applicability of a certificate to a particular community and/or class
> of application with common security requirements." For example, a
> particular certificate policy might indicate the applicability of a
> type of certificate to the authentication of electronic data
> interchange transactions for the trading of goods within a given price
> range. A CP is represented in a certificate by a unique number called
> an "Object Identifier" (OID). When a CA places multiple CPs within a
> certificate's Certificate Policies extension, the CA is asserting that
> the certificate is appropriate for use in accordance with any of the
> listed CPs. CA/Browser Forum had defined several CP OID as below.
>
> EV SSL CP OID: 2.23.140.1.1
>
> EV Code Signing CP OID: 2.23.140.1.3
>
> DV SSL CP OID: 2.23.140.1.2.1
>
> OV SSL CP OID: 2.23.140.1.2.2
>
> IV SSL CP OID: 2.23.140.1.2.3
>
> Each CP OID indicates the applicability of different type of certificate.
>
> From the perspective of audit, Wen-Cheng in his slide page 8 shows the
> Audit Applicability Matrix quoted from WebTrust for Certification
> Authorities - Audit Applicability Matrix
> <http://www.webtrust.org/principles-and-criteria/docs/item83986.xlsx> in
> WebTurst <https://www.cabforum.org/wiki/WebTurst>website. “CABF BR +
> CABF Network and Certificate System Security Requirements” define a
> set of rules (i.e. effectively a CP) for the applicability of
> publicly-trusted DV, OV, or IV SSL certificates.
>
> Wen-Cheng said “CP OID Chaining” is well-defined in the certification
> path processing procedure of the X.509 standard and RFC 5280. Where
>
> user-initial-policy-set: comprising one or more certificate policy
> identifiers, indicating that any one of these policies would be
> acceptable to the relying party for the purposes of certification path
> processing.
>
> initial-explicit-policy = true: indicates an acceptable policy
> identifier needs to explicitly appear in the certificate policies
> extension field of all public-key certificates in the path.
>
> Processing intermediate certificates: each CP OID that appears in an
> intermediate certificates must also appear in the upper-level
> intermediate certificate or in the user-initial-policy-set.
>
> Each CP OID that appears in the end-entity certificate must also
> appear in the intermediate certificates.
>
> In page 16 of Wen-Cheng's slide, he showed a table from
> https://cabforum.org/object-registry/ about CABF compliance OID. Most
> of the CAs put their private CP OIDs in their intermediate CA
> certificates and EE Certificates. What should we do? Wen-Chung
> suggested to enforce to adopt CABF CP OIDs. Set a sunrise date as below:
>
> Effective DD MM YYYY, CAs MUST use the following CP OIDs in the
> subordinate CA certificates and the subscriber certificates. Maybe two
> years later.
>
> Note that currently “Microsoft Root Certificate Program”
> <https://technet.microsoft.com/zh-tw/library/cc751157.aspx> already
> mandate the use of CABF CP OIDs 4.15 CAs must use the following OIDs
> in the end-entity certificate: DV 2.23.140.1.2.1; OV 2.23.140.1.2.2;
> EV 2.23.140.1.1.; IV 2.23.140.1.2.3; EV Code Signing 2.23.140.1.3;
> Non-EV Code Signing 2.23.140.1.4.
>
> For Browsers, All of the Root CA certificates in the trust list must
> associate with one or more applicable CABF CP OIDs.
>
> Wen-Cheng concluded that the advantages of determining the
> applicability of certificates by using standard CABF CP OIDs instead
> of EKUs is that it can provide a uniform, systematic, and automatic
> way to determine the applicability of different types of certificates.
> It is fully compliant to the certification path processing procedure
> defined in the X.509 standard and RFC 5280.
>
> Let’s do the right thing in a way that we do it right
>
> Do the right thing: we must always check the applicability of certificates
>
> Do it right: By enforcing standard CABF CP OIDs, we can systematically
> check applicability of certificates.
>
> Ans: If people wants to use their own private PKI, they have to import
> their own Root CA to browser. They can assign appropriate CP OIDs in
> their certificates, so we can still use the systematical way to do the
> CP OID validation.
>
> Ans: So if the appropriate CP OIDs are assigned, the browser can knows
> that it is OV or EV on path processing.
>
> Q: The browser wants to check if the certificate is mis-issued
> according to CAB’s baseline requirement. If a CA wants to mis-issue
> certificate, it can easily add the CP OIDs into the mis- issued
> certificate. Your opinion is asking all browsers to change the
> software to check the CP OIDs and all CAs must add CP OIDs into
> intermediates to achieve something that is not much valued. That is my
> concern to this proposal and I don’t think it will work.
>
> Ans: The CA should disclose the CP OIDs used in their certificates, so
> it could be easily determine the certificate has appropriate CP OIDs
> or not.
>
> Q: The Web PKI doesn’t do CP OIDs checking.
>
> Ans: It depends on browsers. I know Firefox and NSS don’t process
> certificate policies. Microsoft requires all CAs to have appropriate
> CP OIDs end entities, since these CP OIDs may not in intermediates.
>
> Q:Your opinion is to request browser to full process the CP OIDs in
> path building. These is not only to end entities, since Microsoft
> require all the root certificate has these CP OIDs too.
>
> Ans: I think it is a big challenge to trust stores and browsers, but
> in long term it is a right way to do it.
>
> Q: What is the problem that we are trying to solve? You are trying to
> use a trusted root to issues certificates to intermediates that not
> comply with baseline requirements.
>
> Q: If the browser claim requires CT/SCT is embedded in the
> certificate, it also works and in such CA, any issue among in OV and
> EV situation, roughly in 24 hours condition, is that correct?
>
> Ans: Yes. If someone find there’s something wrong and he commits and
> reports to the browser of course you can stop the CA. But you already
> accepted, by using the CP OIDs, you will reject this kind of
> certificate immediately.
>
> Q: Yes. Right now we are in reactive position. We will detect them.
> Something prevents it. You mention we need 24 hours to solve them but
> in situation, no one saw them and the browser will reject certificate
> there for about a process time.
>
> Ans: If someone find there’s something wrong in the middle, some CA
> issue website certificate and is not issued by me. I will get some
> report to the browser. Browser will ask CA to fix. So mis-issued
> problems happen from time to time. So if we can have a systematical
> way, we can reject this kind of mis-issued certificate immediately
>
> Q: You want the ability to have a root CA that essentially issues a
> constraint supported to a 3rd party that has different controls to the
> root CA. So you don’t completely trust, you want to be able to issue
> to something else, the supported CA, cross sign, and explosively
> exclude them. Say I know I sign that, I disclaiming responsibility in
> the mis-issue. Is that right?
>
> Ans: Of course the CA has the liability to perform well management of
> their system, but here I just like to comment this is a standard when
> check the certificate. And in this way if there is an issue, it can be
> automatically rejected.
>
> Q:If you have a RootCA issuing the SubCA then they have to be concern
> about their compliance with the baseline requirements. If you can
> somehow do that with some other mechanisms such as like CP OID rather
> than EKU then you can do that maybe this is also a build suspenders
> part of that. What the idea is that maybe you can control your
> reliability by doing that and not be such as oids of subCA what you
> created if it’s like an external subCA.
>
> Ans: What I would like to suggest putting this CP OID checking is that
> it can help browser to automatically detect the mis-issued of these
> certificates.
>
> Q:It’s not evil bit said and you are saying this is a mis-issuance but
> what said be not evil bit but I am saying the mis-issuance they can be
> mis-issuing and then they can just issue said to be not evil bit. In
> which case, you know, We will assume, it’s not evil, they will check
> they are not evil bit. Actually it is not evil.
>
> Ans:I do not invent this. This is defined in the standard. We commend
> we use this checking standard. The advantage using this kind of OID
> checking is because that it is systematical and automatic.
>
> Q: Is there a need to do this change? What is the problem you try to
> resolve?
>
> Ans1: Different CA has different hierarchy, for example, If an RCA
> only has one subCA, then EKU chaining is enough.
>
> Ans2: EKU chaining is simple. But there might be non-browser
> applications processing ICA certificate with EKU will have problems.
>
> Ans3: CP OID Chaining is a systematic and automatic way to detect
> miss-issued certificates. It lets browsers and other clients to detect
> and block miss-issued certificate immediately rather than reported
> later by other parties.
>
> Q: There are many different implementations among Browsers and CAs, so
> it is challenging to do this change.
>
> Ans: We know it is challenging, but we just want to evaluate the
> possibilities of this change.
>
> Q: The Key issue is the EKU Extension should not be used for
> certificate signing. If the EKU extension is non-critical, will it
> prevent the standard-violation problem?
>
> Ans: As far as we know, If you recognized the EKU Extension, you
> should process it no matter it is critical or not.
>
> Ans: Critical or non-critical. The standard says that if certificate
> use the software which recognizes EKU, you need to process it, even
> the EKU extension is marked as non-critical
>
> Ans: Yes, service can process and understand. In case Microsoft
> certificate services, if you could put EKU into supported CA, that
> means sub-CA can issue any client certificates that have different
> OIDs, not including any EKU extension of sub-CA.
>
> Ans: That’s what I emphasize then. How we replace EKU with CP OID. I
> suggest all of CAs add the standard of CA/Brower Forum OID into
> certificate. This is first step you need to do. If all of intermediate
> CA and subscriber certificates contain these standard CP OIDs, then
> the certificate using system, such as browser or the operating system
> or even the future software can check these CP OIDs chain
> automatically. Prevent the accident of mis-issue immediately.
>
> Q: Right, this means that get back to the point, say EKU constrained is?
>
> Q2: Right, I think the general answer is so? That’s what we’re using
> paper works. Everybody signs up to it, and everybody is using it. It
> does its job. It’s great deal and let’s it!
>
> Ans: There is an improvement because you can automatically detect.
>
> Q: You can use EKU chain. EKU desti and you can all of this, right?
>
> Ans: Yeah! You can also use the EKU to do this check. But the problem
> is controversial and also caused other problem. The certificate is
> varied by other standard complies, such as the C and the CPP software.
> It might be affected if you use the EKU chain.
>
> Q: The Web PKI is the web PKI. Sometimes that’s the way it is.
>
> Ans: Currently, In the BR also faces that in general the EKU do not in
> the subordinate CA group. But, currently we use in the subordinate group.
>
> Q: It’s optional extension.
>
> Q2: So do we turn into the discussion or are there more and more to
> discuss?
>
> Ans: Just want to ask Browsers. Do you want to implement this and the
> mechanism? In the long term, I say this is the right way issue. I do
> not suggest we immediately implement this. I don’t know how long we
> need take to implement this, and how long the standard CP OIDs will be
> in or on the subordinate CA. But we are gathered here to improve the
> trustworthiness of the certificate. I think in the long term we should
> have the systematic way and automatically way to detect this issue.
> This is why I want to propose.
>
> *Validation Working Group Report*
>
> Notetaker: Jeremy
>
> 1. Backlog ballots
>
> 1. Non-latin qualified notaries b. SRVNames c. ASN.1 for JOI
>
> 2. Ballot 190 Experiences
>
> 1. Everyone generally agreed that the documentation/revision storage
> was fairly difficult. Most are storing the information as a date
> that correlates to a BR version b. Jeremy said there’s a lot of
> inconsistency in the language that we need to fix c. Tim said the
> random value means two different things – sometimes it means a
> nonce and sometimes it is a secret. Redefining the term will
> clarify the confusion d. The language sometimes refers to an
> unknown actor. The room agreed generally that the CA should be the
> actor in all cases. This requires clarification e. Jeremy said
> there’s confusion about whether items can be used cross-method.
> Tim said this is clarified once we fix the nonce/secret confusion
> f. Document/information reuse is confusing. g. The scope of the
> domain approval is also confusing. Sometimes the document says
> FQDN, other times it says authorization domain. Once it says base
> domain h. The document is also unclear on the scope of the
> approval. How does a subscriber know they are approving sub
> domains. Gerv asked if we should require scope approval during the
> verification. Jeremy thought this was a good idea.
> 2. Resuability is unclear. Each method should state what can be
> reused and what needs to be redone. Each method should also state
> what how long specific actions are good for.
>
> 3. Ballot 190 Issues
>
> 1. Jeremy showed the issues list b. The validation WG will go through
> the list on their call
>
> 4. IP Address validation
>
> 1. The last proposal was circulated on March 24th b. The ballot
> eliminates the “any other method” c. Jeremy recirculated the
> proposal for discussion on the mailing list
>
> 5. CAA Experiences
>
> 1. The biggest question was about how systems should behave if DNS
> doesn’t answer. This was partly discussed on the mailing list.
> There are two options. First, if there is no record, assume the
> record is permissive for the CA. Second, if there is no record
> keep working the chain. The first is the correct interpretation
> but CAs are permitted to be more restrictive. b. Others felt CAA
> was not mature enough for adoption. The RFC needed more
> clarification before we tried to implement. c. Peter brought up
> that DNSSEC implementations lacked quality. CAs are required to
> fail open if DNSSEC is not present, but fail close if DNSSEC is
> present. d. There are issues with split horizon e. Some failures
> are caused by CNAME loops f. People have seen issues with
> malformed records. CAA needs better implementation tools as these
> are generally caused by manual input processes. g. Lesson learned
> – these new ideas need a more phased-in approach.
>
> h. There was a lengthy discussion about CAA and the audit, especially
> as it pertains to the errata. What happens now that the browser and
> audit requirements differ? Ultimately, this became a non-issue as
> neither WebTrust nor ETSI would updated before the errata requirement
> went into effect.
>
> 2. The validation WG said they would write a normalization document.
> j. CAA for IP Addresses is an IETF issue, not something to discuss
> in the WG k. CAA flags. Four were suggested: Validation methods,
> account identifier, certificate types, and brands l. There’s a
> question whether the WG will cover these or a new CAA WG will
> create them
>
> 6. Root and Intermediate Requirements
>
> 1. We discussed modifying 7.1.4.3.1(b). Right now it specifies that
> the Sub CA must be listed in the O field. There’s a question
> whether vanity issuing CAs are permitted.
>
> *Domain Validation Implementation Issues*
>
> Notetaker: Jeremy
>
> See Validation Working Group Report.
>
> *Network Security Working Group Report*
>
> Notetaker: Ben
>
> Ben explained the background of the Network Security Working Group.
> The CA/Browser Forum’s interest in network security dates back to the
> Diginotar event in 2011. As a result of Diginotar, the Forum adopted
> the Network and Certificate System Security Requirements (NCSSRs).
> Until recently we hadn’t revisited the NCSSRs, so this Working Group
> was formed to take a look at the NCSSRs and decide whether the repeal
> them and adopt some other network security standard or edit the
> NCSSRs. If we had repealed them, there are still several provisions in
> the Baseline Requirements that talk about things like risk assessment
> and network security, as do the WebTrust criteria. However, the reason
> we originally adopted the NCSSRs was because there was a feeling that
> the Diginotar event happened because there were gaps in certain areas,
> e.g., WebTrust 2.0 has Illustrative Controls, which are not mandatory.
> Also, CAs have experienced pain points in applying the NCSSRs due to
> different interpretations by auditors, etc. The Working Group has
> gathered comments on these and recently tackled some of the easier
> ones to address in Ballot 210. We prioritized the remaining issues,
> and we reviewed those during our working group meeting the day before
> yesterday.
>
> During our working group session, we discussed the path forward. The
> NetSec <https://www.cabforum.org/wiki/NetSec> Working Group also has a
> subgroup working on CA architecture, the threat model, threat
> analysis, risk assessment, (i.e. what are we trying to protect). The
> reason for this is that this analysis will allow us to define security
> perimeters of things like root CAs and certificate issuing systems.
> Meanwhile, the Working Group will continue to discuss the remaining
> items on the prioritized list. We may re-prioritize the list based on
> a suggestion that we take low-hanging fruit – items that are easier to
> address.
>
> *CAA Implementation Issues*
>
> Notetaker: Robin
>
> Jeremy initiated the discussion on the topic.
>
> There were a number of Issues expressed at the working group yesterday::
>
> * There is a lack of clarity on how the system should behave if the
> DNS doesn't answer.
> * A lack of quality around DNSSEC implementations
> * RFC not mature enough.
> * Split horizon issues
> * Failures because of CNAME loops
> * Malformed records. Tried for CAA, but failed..
>
> Lesson: we need a more phased approach. Do we need a report-only mode?
> What happens now that BRs requirement is diffferent from browser
> requirements (due to RFC errata)? This turns out to be a non-issue,
> because its not yet in the audit criteria.
>
> Kirk: - Malformed records?
> Jeremy - CAA missing issuernames, or nonsensical data in an issuername.
> Wayne - I see a need for a toolset for people creating CAA DNS records.
> There should be a way to make it much simpler for customers.
>
> Kirk: What is still pending in CAA?
> Jeremy - There is still an errata which is not yet held for update.
> An RFC through the ACME group with FLAGS. Errata still come.
>
> Tim - Doug's recent thread on what to do around retries.
> Jeremy: I was surprised to see the variation in expectation. Do you
> fail closed or fail open?
>
> Wayne - what we're asking is, does an individual DNS lookup failure
> count as a failure? Or do you need to try every step?
> Geoff: If the server failed, you try the server and then retry. What
> do you assume, if you can't get the record?
>
> 1. Assume no record - so you can issue.
> 2. Assume there is a record that allows you to issue.
>
> So for the moment a failure means you can issue.
>
> Gerv: That surprises me because I would expect it to fail closed.
>
> Geoff: I agree that it should fail closed, but the BRs don't say that.
> Alex: Agree. It is bad security practice to fail open.
>
> PZB: Fail open if you have an affirmative 'this isn't DNSSEC signed'
> indicator. Fail closed if DNSSEC in use.
> Wayne: Do you have to use DNSSEC only or can you just do DNS?
> ....
> PZB: - so we're back to yesterday, the standard is OK, but the DNS
> implementations suck.
>
> Wayne - we need to get to a point where we agree on the requirement,
> in this room at least.
>
> Gerv: Agreed. A test suite would be good - but need not be a product
> of the forum. A document with use cases and expectations for edge cases.
>
> Gerv: It is not a good use of CA's time to work out all the edge
> cases. Let's do it in the forum instead, or elsewhere, once.
>
> PZB: Bullet 3 is the core thing. If you've pointed it at a private DNS
> server then it won't resolve. supersecret.project.com points to
> 10.2.3.4. .com zone says whether project.com is DNSSEC signed.
>
> Steve: Assuming that you have a DNSSEC capable system.
>
> CAA is discussed in the validation WG, currently.
> Kirk: There may be a larger group that wants to talk about it.
> (working towards the test set)
> Tim: start a new group
>
> Kirk: Can someone come up with the charter.
> Geoff: I will come up with some language for a charter.
> Tim: Issus in implementing RFC6844 and errata in compliance with the BRs.
>
> PZB: Issues and experience in implementing 6844 and errata.
>
> Wayne: I wanted to clarify the ballot around 214 . Is there still an
> issue on how DNAMES should be handled.
> Tim: Yes. That is the errata that is not yet held for update.
>
> Kirk: Should we get involved in the IETF process?
> PZB: There is no approval process for errata. Once it has a number
> (RFC6844) it never changes. Somethimes there is enough interest to get
> an update - in which case it gets a whole new number. E.g. 3280 became
> 5280.
> Jeremy: You can have a bis.
> PZB - that is a draft. It gets a new number.
>
> *CT Implementation Issues*
>
> Notetaker: Giichi
>
> Kirk: I’m concerned about availability and reliability of CT log
> especially if this is mandatory process for service availability for
> CAs. Google seems to be confident about the availability.
>
> Devon: what is 99% up time CT team is primary working on getting code
> ready and not for availability. The intent was to first release and
> monitor traffic and uptime, etc.
>
> Need to have clear SLA to be able to monitor the real availability.
> Currently Google being the sole determinator of up time, what it means
> to be. Could be network issues. Kirk: Why trust CT log when only 98%
> availability is maintained. Feels like punishing user.
>
> Devon: heart of uptime argument is ensuring the log doesn’t
> intentionally shut down issuance There will be significant policy
> change to address uptime issue. Clearly articulating the concerns
> around uptime is going to affect how policy would be formed.
>
> Gerv: are you saying there are certificates being kicked out without
> notification period?
>
> Jeremy: during the qualification period do we require certificate for
> those who do not permit logging
>
> Devon: 90 days window is a monitoring period and for people to know
> what’s going to be after the monitoring period is over.
>
> Peter: getting CT back doesn’t mean there is a log, it’s a promise
> signed by a server that there is a log. For malicious log, it issues
> bunch of promises, if it’s unavailable, it take the fetch log
> operationally offline then issue promises that never knows, and is
> never detectable until it comes back online.
>
> Jeremy: one of the implication we had was that policy is not the
> amount of information you get as a CA. it’s helpful to get more
> information from log operator on how policy is embedded in the log.
>
> Devon: now, there’s a clause to catch all of this to what is public
> interest to find out what is not defined what are criteria on
> accepting. What is the terms for CA for acceptance? One of the
> non-technical checks on whether log could be trusted. We need to
> address things like what if policy changes, to some extent it’s
> operated by trust store and everything need to be qualified but based
> on increased feedback.
>
> Jeremy: Would it worth coming up with log policy?
>
> Devon: would be valuable. Policy on what log operator support on CA,
> we would be interested to know more about what they are doing.
>
> Jeremy: the interest is probably more on browser rather than public.
>
> Devon: Browsers are the ones who makes distrust decision based on the
> policy, so we want to make sure we understand the expectations from CAs.
>
> Kirk: I’d like to re-open the conversation on enterprise customer
> don’t want to put CT and don’t want to go back to private. Could
> Google explain why name redaction cannot be done?
>
> Devon: long standing discussion on this topic and could further be
> discussed at CT meeting.
>
> Kirk: want to know “why” cannot
>
> Peter: There were several options Ryan agreed to implement to allow
> enterprise to push policy to say “for my enterprise, I do not require
> CT on subset of certificates”.
>
> Kirk; That’s not the same. They wanted to work within their
> environment without having to get warning. They don’t want to
> configure special setting in order to avoid browser warning. Coming
> back to the original point, what is the reason why redaction is not
> allowed?
>
> Peter: With redaction how do you determine if one is permissible
> redaction or not? For example, if Amazon decides payment.amazon.com
> doesn’t want to be checked by Google? How do we ensure that doesn’t
> happen?
>
> Kirk: That is not really a relevant threat. If domain is validated,
> and it is their domain. For payment.amazon.com, it’s Amazon who has
> ordered such certificate, and they can simply ask for redaction.
>
> Peter: Reason for CT is to avoid the challenge of somebody misdoing
> it. Mozilla currently surveillances 64 trust service providers, and
> the reality is there are vulnerabilities in the process. That’s where
> CT can make it easier to spot these mistakes.
>
> Kirk: If you see payment.amazon.com certificate and if we look at CT
> log, we will automatically know or do we need to do some research?
>
> Peter: For Amazon certificate, every single certificate issued from
> Amazon goes through internal management system that talks to CAs and
> anything shows up to CT log that aren’t in there is a major security
> alert.
>
> Kirk: Yes, but that can also be done with redaction as well.
>
> Peter: Yes, but what do I do?
>
> Kirk: You contact the CA and request for revocation. But what do you
> do anyway when you see a certificate in CT and un-redacted CT that you
> think is not adequate. It would be the same process, asking the
> issuing CA to revoke the certificate.
>
> Peter: We will need to investigate.
>
> Kirk: that issue was different my point was subscriber should be able
> to identify the certificates that they don’t recognize and ask issuing
> CA to revoked.
>
> Peter: if it is redacted, all the information subscriber get was it
> was issued to xxxx.amazon.com and its serial number. Then subscriber
> will need to ask issuing CA for further detail.
>
> Kirk: that is Amazon’s specific case of handling it. If someone finds
> out about certificates that they are not sure about, they will have to
> research it anyway.
>
> Peter: what is the goal of redaction? Under what circumstances does CA
> need to disclose further information?
>
> Kirk: If they can prove domain control.
>
> Peter: What happens to redaction if someone sells the domain?
>
> Kirk: that’s the use case we never thought about.
>
> Kirk: CAs can bring redaction issues propose to create rules around it
> including points on how CA should handle the request from subscriber.
>
> Devon: We can probably bring proposal and have informed discussion at
> CT Policy Day.
>
> Robin: current RFC does not mention about redaction.
>
> Kirk: We can fix it in version 2, but in the meantime, errata can be
> released.
>
> Peter: part of issue is that technical specification is not really
> finished.
>
> Jeremy: it was abandoned because there was no ambiguity.
>
> Peter: RFC6962 continued to move forward, existing methods at least
> needs to be updated.
>
> Devon: another reasons for holding up the changes to RFC6962 are that
> there area other signification technical changes are coming.
>
> Kirk: Main point is to come back with errata and technical scheme on
> how to do name redaction.
>
> Devon: even if changes are incorporated in errata, it needs to be
> reflected technically before it means anything.
>
> Kirk: is that what happened to CAA errata?
>
> Devon: errata doesn’t equal to implementation.
>
> Peter: implementation must happen from both CA and Browser side. It
> must be deployed to all customers and will takes long time to roll
> out. Do apple check CT as well?
>
> Geoff: Yes
>
> Jeremy: Microsoft also check.
>
> Geoff: but we will need to have users update the mac OS.
>
> Devon: what are behavior on EV certs in CT in High Sierra?
>
> Geoff: in order to get EV treatment in High Sierra and have to have CT
>
> Devon: which CT log does it support for SCTs?
>
> Geoff: Apple has a list, but not useable yet.
>
> Curt: will create similar to Google one.
>
> Kirk: for CAs to bring up on redaction, we will discuss offline.
>
> *Policy Review Working Group Report*
>
> Notetaker: Tim
>
> The definitions of Trust Service Provider and CA were discussed. It
> was proposed that "logical entity" would make the definition clearer.
> Further discussion will occur on the CABF public email thread.
>
> We need to go back and find the thread where we identified which
> instances of CA in the BRs refer to the service and which refer to the
> organization. Very few instances refer to the organization.
>
> Should the definition of CA state that it is trusted by "one or more
> Application Software Suppliers" instead of "one or more entities"?
> It's not clear.
>
> "operated by the same TSP" vs "affiliate"? Might handle after the CA
> bifurcation work is done.
>
> *Review of pending ballots*
>
> * Reminder to include redlines with ballots
>
> 206: "Governance Rule Change"
>
> * nothing to add
>
> 207: "ASN.1 jurisdictionBlahBlah"
>
> * About to be introduced
>
> 208: "dnQualifiers"
>
> * About to be introduced
>
> 209: "EV Liability"
>
> * Allow CAs to have a per-cert total cap on liability
> * About to be introduced
>
> 213: "Revocation timeline extension"
>
> * Pushing out the timelines for non-urgent revocations
> * Ryan wanted notification of the CAB Forum if it takes longer
> * Seems a bit stuck, but want to pass it
> * Robin and probably Kirk will endorse
>
> XXX: Remove "Any Other Method" from IP Address Validation
>
> * Looking for endorsers
> * People should read through it one more time
>
> XXX: Remove requirement to obey latest version of the BRs
>
> *Symantec EV Cert Discussion*
>
> Notetaker: Robin
>
> For background to this issue, look on the CABFMAN email list.
> The domain /FQDN is 0.me.uk/ev-phishing.
> The email subject is:
> Subject: [cabfman] Data for discussion of Symantec EV cert article
>
> Kirk opened by asking the nature of the problem with this certificate.
> The on-list discussion seemed to center around the 'applicant place of
> existence'. UK Companies House shows that address.
> Gerv: I was hoping SYMC would discuss this to determine whether there
> were improvements we can make to the EV guidelines.
> Kirk sent out that they have his name and a picture of his house. One
> quote in the article ....
> Geoff: The original requirement was that he had a place where they
> actually did business.
>
> PZB: is there a requirement that SYMC discuss this?
> Gerv: my indications are that SYMC are willing to discuss, so that Q
> is moot.
> Steve Medin: We see a request from a module peer as a requirement.
> We regret that the investigation is taking a long time. We believe
> this will lead to an improvement in the EVGL.
> Kirk: You said there is a problem. What is the problem?
> Gerv: Steve said there is a problem.
>
> Geoff: The point is that if you have business operations at that
> address it is harder to move.
> Steve: you can't just use a QGIS to prove 'operational existence' -
> even by companies house. There is the potential for some
> disappointment in some of the processes and there may be a
> improvements required across the board to meet the standard as it is
> currently stated.
>
> *Possible Root Program/BR Lint testing requirement*
>
> Notetaker: Robin
>
> Should we have a rule requiring lint testing?
>
> Gerv: recently people have been digging thru CT and fining issues with
> certs and creating bugs. It is useful to see which CAs are on the
> ball. One common thread is that CAs realizing that cablint and
> x509lint are potent weapons so they incorporate them into their
> issuance process. Kathleen was wondering whether it is wise enough for
> it to be a program requirement or a BR requirement. We would probably
> not mandate the use of particular software. But if you don't do that,
> can you have a requirement without teeth..?
> Tim: Doesn't that just end up being 'don't misissue.'
> Devon: It's a handy thing to lint, but we already have the requirement
> to comply. Does it help to have a meta requirement like that?
> Jeremy: I disagree. It's handy to have the requirement to steer CAs to
> do it.
> Devon: You imply CAs aren't perfect?!?
> PZB: as an author of some of the software in question, .. urges
> caution to require its use! There are bugs! It was written for
> internal use.
> I'm somewhat disappointed in the use that has been made of it to
> report findings in certificates from crt.sh.
> Gerv: From our perspective, we don't sweat the small stuff, but it is
> useful because it flushed out one CA that doesn't know what they're doing.
>
> Robin: We run the tool against the certificates we issue. Although PZB
> is correct to say no tool is perfect, there is value in running the
> tool, but an 'exception' process is necessary.
> Gerv: If you get a finding from such a tool it is up to you whether
> you choose to issue nonetheless. You have at least made the
> determination. We drew attention to the existence of these Lint tools
> in our last CA communication.
>
> Jeremy: but new CAs come along.. A recommendation could be useful.
> Gerv: we have a problematic practices and a best practices page.
> Wayne: Could it be a MUST that prior to issuance a CA must perform a
> check for technical compliance?
> Curt: Doen't we already have that requirement by auditing?
> Wayne: Post issuance
> Devon: But we have requirements, CAs must follow requirements already.
> Gerv: I guess we should just add this to our best practices page.
>
> *Discussion of Mozilla BR self-assessment experience*
>
> Notetaker: Robin
>
> Gerv: Kathleen ponders a suggestion that CAs that haven't done a
> self-assessment recently should do one. Is it fair to say that, for
> each CP/CPS pair, you would need a separate assessment? So our request
> may be 'can you do N self-assessments'.
>
> A BR audit maps each requirement of the BRs to the CP/CPS.
>
> Aaron checks before inclusion that a CAs documentation is adequate and
> BR compliant. It used to be that we went through the CP and CPS and
> did the mapping. Now we get the new CA to do the mapping as a
> self-assessment.
>
> Gerv: SSL.com - you are in the inclusion process. Can you give us a
> rough idea how many man hours the self-assessment took?
> Leo: several weeks elapsed time.
> Gerv: So of the order of a man-week?
> Leo: - that would be fair.
>
> Straw poll shows no-one had more than 3 CP/CPS pairs.
>
> ben: what about a CP/CPS combo that just maps to the BRs?
> Gerv: We say that you can't just the dump the BRs into your CP/CPS for
> 3.2.2.4.
>
> Kirk: It could be useful to help a CA find gaps in their own process.
> But I don't want to subsequently hear from the browsers that 'You said
> in your SA that you did 7.1.4, but we found that you don't. Double whammy.
>
> Gerv: That is not the intent.
> Devon: How many people are there on the planet whose job it is to map
> CP/CPS to BR audit criteria? 10?
>
> Gerv: Having the CA doing the mapping makes the process of CP/CPS
> evaluation much easier at the time when it comes to admit a CA to a
> root program.
>
> Kirk: Maybe as we post a new version of our CPS, the self-assessment
> could be tied to that.
>
> Robin: It's got to be useful to have more eyes on a CP/CPS. You can't
> review your own code! As Jeff Ward pointed out yesterday, the CA's
> auditor will already have done the mapping as part of their annual
> audit work. Do we just end up handing over our auditors' mappings?
>
> Gerv: OK, so I haven't made you do an incredible amount of work.
>
> Robin: Small amount of incremental value, for a small amount of work?
>
> Geoff: The interesting thing is the ratio between the work done and
> the value derived.
>
> Gerv: I will take this back to Kathleen.
>
> *Information about next F2F Meeting 43 hosted by Amazon in Herndon,
> VA, USA – March 6-8, 2018*
>
> Notetaker: Kirk
>
> Peter confirmed the next F2F meeting will be hosted by Amazon on March
> 6-8, 2018 at its Herndon, Virginia location. More information will be
> provided in the coming months.
>
> Kirk said that both Cupertino, CA and London had been suggested for
> the June 2018 meeting, and asked for a straw poll of preference. Gerv
> asked where the Fall 2018 meeting would be, and Kirk said China. Gerv
> said that London seemed the better choice for a June meeting, as that
> balances meetings among Europe, North America, and Asia, and the
> group's consensus was the same. The June 2018 meeting will be hosted
> by Comodo in London. Kirk asked other members to talk to him if they
> wanted to host a meeting in 2019.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180110/d1108798/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180110/d1108798/attachment-0002.p7s>
More information about the Public
mailing list