Home » All CA/Browser Forum Posts » Minutes of the F2F 39 Meeting in Redmond, Washington, 18-20 October 2016

Minutes of the F2F 39 Meeting in Redmond, Washington, 18-20 October 2016

Attendees: NOTE: The following list is of attendees that were there during at least one of the three days: Peter Bowen, Li-Chun Chen, Wen-Chun Yang, Dean Coclin, Kirk Hall, Chris Bailey, Richard Wang, Arno Fiedler, Bruce Morton, Tim Hollebeek, Wayne Thayer, Franck Leroy, Rick Andrews, Ben Wilson, Geoff Keating, Atsushi Inaba, Robin Alden, Doug Beattie, Gerv Markham, Billy Van Cannon, Curt Spann, Andrew Whalley, Ryan Hurst, Ryan Sleevi, Tyler Myers, Alex Wight, Mike Johnson, J.C. Jones, Moudrick Dadashov, Michael Yatsko, Dimitris Zacharopoulos, Joanna Fox, Chen Po-Han (David), Tsai Chya-Hung, Yi Zhang, Josh Aas, Iñigo Barreira, An Yin, Kim Nguyen, Jeremy Rowley, Steve Medin, Rob Stradling, Chi Hickey, Eric Mill, Fotis Loukos, Chris Kemmerer, Patrick Donahue (guest speaker), Shu-Chen Hsiu, Jeff Ward, Don Sheehy, Clemens Wanko, Irina Hedea.

Day 1 – Wednesday, October 19

Working Group Reports

Policy Review Working Group – amendment-of-br-7-1-4-2-2

Governance Reform Working Group – gov-change-wg-summary-and-open-questions-10-18-2016

Ben Wilson (presenter): We’ll annotate Kirk’s outline (memo sent to membership list: Summary of Proposal and Open Questions) Gov Change WG – Summary and Open Questions 10-18-2016.pdf going forward with decisions as they are taken. The points discussed:

Chartering Working Groups (WGs) and powers they shall have.
Pushing work down to WGs.
Initial tranche of WGs: Server Authentication (was: Web), Code Signing and S/MIME (Client?) are likeliest contenders, other WGs possible.

Discussion on Initial WGs:

(Gervase Markham: Preference for S/MIME rather than Client WG, as WGs should be tightly focused, based on past experience and GM’s understanding of participant interest.) (BW: Call for show of hands for Client vs S/MIME for title/focus of proposed group – no votes noted in favor of Client, five votes in favor of S/MIME.) (Dimitris Zacharopoulos: Notes strong call for digital signatures in Europe, not sure what Client group would focus on.) (Robin Alden: Noted different interpretations of ‘client certificate’.) (Alex Wight: Concurred.) (BW: Per Gerv, more focused WG groups likely.) (Phone caller, Ken Myers: Notes WG proposal parallels FedPKI approach.) (Sense of committee appears to be tightly focused WGs are preferable. BW: Moving on:)

Ongoing role of Forum, 8 proposed tasks to remain at Forum level. (Notes open question: should Chair of Forum serve as Chair of Server Authentication Group?)
Voting rules: 2/3 of non-CA membership? Charters of WG may override? Open questions.
Define term ‘affiliate’ in bylaws. (Proposal is to pull existing definition from IPR.)
Define term: ‘decision-making authority’.
IPR policy: needs amendments to describe coverage/scope as applied at WG and/or/vs Forum level. May entail one IPR policy at Forum level, another at WG level. Weighing penalties for action on patents/IP (including loss of royalty-free licenses (RFLs).

Discussion on IPR penalties

(Phone caller, Virginia Fournier: Questioned if one member taking action against another member should trigger a loss of the RFL from other members) (Kirk Hall: Remains an open question, further discussion definitely called for.) (Ryan Sleevi: Objected, noting that the RFL license was worldwide and supposed to be irrevocable, not just to members, so such covenants don’t make sense) (KH: No protection from trolls, however. Moving on.)

Clickthrough vs signed PDF for IPR agreement is open to discussion.
(Note item not discussed in summary: Communication from others/third parties.)

IPR Policy

Note Taker: Billy VanCannon

Kirk Hall Presented

We have had over 160 ballots and not consistently followed our own IPR guidelines. Kirk reviewed our guidelines, but high-level: Before we vote on a given ballot, a review period shall be allowed where members may submit exclusions based on IP claims and if they are willing to license and at what terms. If needed, then a PAG shall be formed to review what should be done, if anything, before the ballot is passed.

The proposal is 3 concurrent ballots.

All things in BR through 176 except 3.2.2.4 and replace with use any method provided they properly document it. This is done because we don’t believe this will generate an exclusion and enable all our BR guidelines to be approved. It would be very “unsporting” for anybody who has an exclusion to submit not to mention this ASAP.
add 3.2.2.4 methods 5, 6, 9, 10 to get them in. Again hoping no exclusions. Update after this is remove #9 and put in C.
add 3.2.2.4 methods 1, 2, 3, 4, 7, 8 and deletes the “any other method” Here we assume exclusions will come. We will see the stance on licensing. PAG will be created if so. PAG to put forth something. It could be modifications, drop the method, come up with new ones, or something we can’t predict now.

Ben Wilson wanted to see if we can start the PAG work now, given the certainty of exclusions. This can be considered.

We have decided to wait on any new ballots until A is passed. Ballots can still be added to wiki with no number so work can continue.

Hope is to start the process early next week. 81 days to get passed from the start assuming all goes to plan. 1 week discussion, 1 week straw-vote, 60 days IP exclusion, 1 week vote.

Browser News

Google

Note Taker: Kim Nguyen

Update on Chrome: In Chrome 56, there will warnings to be issued for Password/credit cards fields used on an http basis (indication based partly on autofill), to be release end of January 17. The expectStaple feature is present in 54 already, this is a way to gather Information for the behaviour on stapling especially on Client Environments. There is a trusted time Service forthcoming as an experimental Service. Chrome 55: will see changes in the UI on indicating the EV status especially with respect to colouring and presentation of names etc., further changes are forthcoming on the basis of the continuous UI testing. TLS 1.3 Support is also forthcoming. This is in addition to the support for QUIC, which tries to resolve some of the HTTPS+HTTP/2 issues by being more like TLS layered on a multiplexed UDP stream. QUIC is also a topic within the IETF discussions, it is as of now already used as the basis for connectors from Chrome to Google services Update on SHA-1 (see also notes from Mozilla Update): SHA-1 deprecation will be rolled out within coming next weeks, there will be a gradual rollout until January 17. Google is closely monitoring user and services behavior. During the course of 2017, Google will be disabling SHA-1 for Enterprise roots by Default

Google announces a stronger formalization of the trusted root store program, Salesforce will most likely be used to manage the CA related data, but a separate formal agreement will still be required.

With respect to the relation to the Android trust store, Google is working on a deeper synchronization of the different trust stores

Update on CT: Progress was achieved with one of the major milestones being that of 6962-bis going to WGLC, the implementation of the new spec version in log servers is ongoing and will likely be finished early next year. The focus for 2017 will be on onboarding of CT as a general feature as well as integrating additional logs servers.

Update on the Google PKI: new roots were generated and web trust audits were performed, the report on this is forthcoming,

Beginning October 2017, any newly issued certificates will need to be CT Qualified to be recognized as trusted in Chrome.

The feature ExpectCT, which allows sites to opt in to early enforcement of CT on a per-domain level, is going to be discussed at IETF 97.

A Mozilla implementation of CT is currently ongoing in cooperation with Google.

Mozilla

Note Taker: Doug

WoSign and StartCom

To start with the big issue: the assembled company will no doubt be aware of Mozilla’s announced plans concerning StartCom and WoSign, following our recent investigations. I won’t repeat them now, although I would be happy to take questions about those plans if anyone has any.

On October 21 Mozilla will no longer trust WoSign or StartCom certificates issued after that date, for all of their roots.
Existing certificates will continue to work (probably) until they expire
Mozilla has no plans to reach out to relying parties

Comments on Incident Handling

Many CAs may have been looking at Mozilla’s actions a little nervously, conscious that they have had an issue or two in the past, and wondering where the tipping point is which might lead to the production of a WoSign-style “issue list”, and if they will ever hit it. It might therefore be worth noting that while CA incidents have differing levels of seriousness, there are some components which every CA should be able to avoid which are red flags for Mozilla in terms of a continued trust relationship, and which would lead to an investigation. They are:

Deliberate violation of Mozilla or other applicable policy
Lying or deception

Mozilla will also assess how concerned we are about an issue in part based on how the CA reacts to that issue, and previous ones. In incident response, Mozilla is looking for the following factors:

A CA takes responsibility for their own actions.
Incidents are taken with an appropriate level of seriousness.
Incidents are handled with haste.
Root cause analysis is performed.
Any questions posed are answered quickly and in detail.
A reasonably-detailed report is made public on what happened, why, and how things have changed to make sure it won’t happen again.

The recent issue experienced by Comodo was a good (albeit small) example of this being done.

If people have further questions about this, they should feel free to ask, either now or privately.

SHA-1 Support

JC has recently published a blog post on our plans in this area. Firefox currently will show an overridable Untrusted Connection dialog any SHA-1 certificate issued from a public root whose notBefore is in 2016. Of course, there should be no such certificates on the web, because the BRs say issuing them is forbidden. (This makes this code path a little tricky to test

When 2017 arrives (FF51), we plan to show an overridable Untrusted Connection dialog for all SHA-1 certificates which chain up to publicly-trusted CAs, regardless of notBefore. This will happen in Firefox 51, due for release on 24th January 2017. We will then look at whether it’s possible to show the dialog for all roots, imported or not, at some time in the future.

Our telemetry shows the current rate of SHA-1 usage is 0.8% of all SSL connections, and falling.

Side note based on comments from Microsoft

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

Google input:

Telemetry on frame loads (not embedded content). See 0.8% of all resources, but .67% of frame loads and this includes enterprise case.
Some windows platforms take SHA-1 path when it shouldn’t.
Also might be visiting local web sites (enterprise) which would not be impacted
Will start turning off SHA-1 in phases starting very soon in certain segments (prior to 2017 date)

Back to Mozilla status:

If you want to experience a post-SHA-1 world now, you can go to about:config and set security.pki.sha1_enforcement_level to 1 (entirely forbidden) or 3 (forbidden for public roots).
60 month certificates are painful and will be the ones most impacted.
CAs should continue communicating to their customers

Short-lived Certificates and Must Staple

We’ve still had no feedback from CAs on either short-lived certificates or must-staple. It seems that Google believes must-staple is currently undeployable, and so has proposed “expect-staple”, a report-only mode for must-staple, to get more data. We are looking at that with interest but have not yet committed to implement it.

Public Key Pinning

Last week, we landed a change in Firefox Nightly to automatically update the list of static public key pins in Firefox via our daily updates, rather than it being compiled in. This should ship in Firefox 52, on 7th March 2017.

No More RC4

In Firefox 50, due for release on 8th November 2016, we have removed the pref which allows re-enablement of RC4.

Experimental Support for Windows Certificate Store

In Firefox 49, which shipped on 20th September, we added experimental support to Firefox on Windows so it recognizes certificates which have been manually added to the Windows certificate store by administrators. Documentation is available on our wiki. Please let us know if your customers use this and have feedback.

Warning for HTTP Password Fields

Code to implement a UI warning (crossed-out lock in URL bar) for password fields on HTTP pages has been in Firefox Nightly and Developer Edition since January 2016, and recently moved to Beta for Firefox 50. We are doing some user testing and implementing some more UI on the password field itself. We hope to turn on the warning in our release builds for Firefox 51 or Firefox 52.

Back in January, telemetry showed that 55% of pages that had password fields were HTTP. Now we are down to 35%.

Intermediate Certificate Disclosure

There are still unsubmitted intermediates which should be disclosed. Be aware that lack of action on this is due solely to lack of time on the part of our team, and not any form of forbearance or goodwill towards the situation Undisclosed intermediates which fit our criteria for required disclosure are at risk of losing trust without further warning. We strongly recommend the remaining intermediates are properly disclosed ASAP.

While 90% of intermediates which need disclosure have been disclosed, we believe at least the following CAB Forum members still need to disclose intermediates: Actalis, Asseco Data Systems, Camerfirma, Certinomis, certSIGN, Chunghwa Telecom, CNNIC, DigiCert, Entrust, E-Tuğra, Firmaprofesional, GlobalSign, Izenpe, Kamu Sertifikasyon Merkezi, QuoVadis, Secom Trust Systems, Swisscom, SwissSign, Trustis, and TurkTrust.

Non-members include: Atos, CatCERT, CyberTrust Japan, Dhimyotis / Certigna, EDICOM, Government of Japan, Government of Spain, Government of Taiwan, IdenTrust, Microsec e-Szignó CA, NetLock Ltd., RSA the Security Division of EMC, Telia Company, VISA, and WISeKey.

The following members have disclosed intermediates but with incomplete documentation: Asseco Data Systems, DigiCert, Firmaprofesional, Secom Trust Systems and SwissSign.

Non-members with incomplete documentation: NetLock and Wells Fargo.

Thanks to Rob Stradling of Comodo for putting together the necessary reports for us as part of crt.sh, and enhancing them at our request.

Revoked Intermediate Certificates

As of today, I can announce that we have taken the historical Revoked Intermediate Certificate data from Salesforce and used it to update OneCRL. From now on, the Mozilla process for revoking an intermediate is for CAs to update Salesforce, and then this information will get propagated to OneCRL. In other words, we don’t need a Bugzilla bug to be filed any more.

CA Communication

It is hoped that there will be another CA Communication in October or November. There was a call for questions in August, but participants are still welcome to submit more. The questions will be discussed in mozilla.dev.security.policy in the usual way.

Root Store Community

In Q4, we plan to update the common CA database to allow:

Entering of updated audit/CP/CPS/test URLs by CAs
Incident reporting

A common root store application process is on the list for the future.

URLs related to the above:

WoSign and StartCom investigation: https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/edit#

WoSign and StartCom decision: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/BV5XyFJLnQM

Firefox release schedule: https://wiki.mozilla.org/RapidRelease/Calendar

SHA-1 blog post: https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/

SHA-1 usage telemetry graph: https://ipv.sx/telemetry/general-v2.html?channels=beta%20release&measure=CERT_CHAIN_SHA1_POLICY_STATUS⌖=2&absolute=0&relative=1

Expect Staple: https://docs.google.com/document/d/1aISglJIIwglcOAhqNfK-2vtQl-_dWAapc-VLDh-9-BE/edit

Public Key Pinning dynamic list bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1306470

Windows store support bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1265113

Documentation on Windows store support: https://wiki.mozilla.org/CA:AddRootToFirefox

HTTP password fields warning bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1304224

Intermediate CA crt.sh report: https://crt.sh/mozilla-disclosures

CA Communication call for Qs: https://groups.google.com/d/msg/mozilla.dev.security.policy/pNw6eUk6gC8/jKnIwf4iCgAJ

Salesforce Root Store Community information: https://wiki.mozilla.org/CA:SalesforceCommunity:RootStoreMembers

Qihoo 360

Note Taker: Dimitris Zacharopoulos

Richard Wang shared some information that came to his knowledge with the room participants, during the 360 browser update. Richard stated that the information he shares is unofficial and that he does not officially represent anyone.

Here is a copy of the information that was presented to the participants:

BEGIN QUOTE

360 Browser will launch CA root program soon, maybe in the next meeting – Feb 2017
I like to share some information from China CA related government authority:
China will have its own Trusted Root List that all China browsers and other foreign browsers that like to be used in China must include it and must trust it;
China will have a central CT log server in China that all issued certificates for China subscriber must post to this log server, and all SSL certificates must embed this CT log servers’ SCT data;

iii. China will have its own CA audit standard, not WebTrust, not ETSI, maybe named as ChinaTrust, all CA that want to issue SSL certificates to China subscriber need to pass the audit. And China will have its own auditor company that must be licensed;

All CA and all OS and browsers that want to do business in China must support SM2 algorithm, including SSL certificate, code signing certificate and client certificate;
All CA that want to sell certificate to China market, must have a registered subordinate company to apply the CA license in China, and all CRL and OCSP servers must be hosted in China, all subscriber’s identity information and proof documents must be stored in China that can’t transmit out of China.

After the presentation, Gerv asked if this is a response to the WoSign incident and the proposed actions the Mozilla. Richard replied that the only CAs CNNIC and WoSign that were penalized came from China. Gerv answered that the reasoning for the Mozilla response was not because the CA’s geographical location. He repeated what he mentioned during the Mozilla browser presentation which is:

Deliberate violation of Mozilla or other applicable policy
Lying or deception

Mozilla will also assess how concerned we are about an issue in part based on how the CA reacts to that issue, and previous ones. In incident response, Mozilla is looking for the following factors:

A CA takes responsibility for their own actions.
Incidents are taken with an appropriate level of seriousness.
Incidents are handled with haste.
Root cause analysis is performed.
Any questions posed, by anyone, are answered quickly and in detail.
A reasonably-detailed report is made public on what happened, why, and how things have changed to make sure it won’t happen again.

The recent issue experienced by Comodo was a good (albeit small) example of this being done.

If people have further questions about this, they should feel free to ask, either now or privately.

Apple

Note Taker: Andrew

Recently shipped iOS 10 and macOS sierra with newly unified trust evaluation code and trust store. ! Made announcement about WoSign: Blocking the subordinate CA if not logged to CT before 2016-09-19. This will come into effect in an upcoming software update.

Still internally discussing further plans for StartCom.

In the process of updating root store requirements. They will be using the Mozilla CA Community in Salesforce. Policies for CA are changing a little bit: CAs must notify Apple on any change of control, and CAs shouldn’t assuming that trust is transferable. Please notify and notify early.

Communication is still the same – via certificate-authority-program@apple.com. Working to improve response time.

Questions:

Q: One CA has decided to withdraw one of its offerings because of trouble getting into Apple’s root store. Are you still processing new applications? Is there a queue? How long is it?

A: No comment. But yes, there is a queue, and the queue is moving.

Q: Do you intend to publish the queue so CAs understand where they are in the queue? Is it strict FIFO or is there ordering based on value to Apple customers? Any transparency?

A: No transparency of that sort planned.

Q: Does updating the list effect only new products?

A: Traditionally yes, only new products.

Microsoft

Note Taker: Gerv

Presenters were Jody Cloutier and Alec Oot.

eIDAS

Went into effect in July
Back and forth with the Commission about what browsers are going to do
Disconnect between (lack of) requirements in eIDAS and browser requirements
Particular focus on the 1-year full audit requirement in MS root program, which eIDAS did not require
Browsers took an action item to define the “state of the art”
There are no TLS-qualified CAs right now

SHA-1

June 2016 – HTTP treatment for any publicly-trusted SHA-1 in both IE and Edge
Feb 2017 – blocked by default with a click-through; sub-resource simply blocked
- This will apply to IE 11 and Edge only, on Windows 7 and above
- Can opt out using Enterprise Group Policy
- Other applications can also opt in to this sort of blocking
Graph shown which shows unique user/SHA-1 tuple count
Plan to reverse the code-signing SHA-1 block in the next few months
- Had a big impact when implemented, but no further change
- Feel they are out of parity with Chrome and Firefox, in which the download works

ETSI and eIDAS Update:

cab-forum-etsi-tsp-standards-2016-10_v3

Slide 3 – ETSI is a global standards body that has members all over the world, including the United States. It is most well-known for its work on GSM. ETSI drafts European norms.

Slide 4 – ETSI has created a detailed audit checklist for auditors who audit CAs. Slide 4 shows that ETSI’s checklist includes 395 specific controls. If for any reason you need help in reviewing the checklist, feel free to contact Arno, Iñigo, or Clemens an email.

Slide 5 – ISO 17065 is one of the foundations of the ETSI audit scheme. An 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, because ETSI is a standardization organization that does not oversee audits. The ACAB’C is now an organization that cares about the quality of the auditor.

Slides 6, 7, 8 and 9 – 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/). 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. If you need to track back, a certificate will indicate somewhere on it the source of the accreditation, which in Germany would be DAkkS and in France would be COFRAC. A CAB presenting an audit letter must have this accreditation to legally and properly issue a certificate of conformity under eIDAS.

Slides 10 and 11 – ETSI involves a two-stage, 3-month audit process. You start with a document assessment and then the auditor will come onsite to check what he/she has seen in the documentation and assess whether stated controls are fully and correctly implemented. Onsite the auditor will do tests and look for evidences that establish that what has been said is being implemented. That takes two months and then the final month is for finalizing everything and making sure that all evidences have been submitted. Then we issue a conformity assessment report (CAR), according to eIDAS, or an audit attestation (AA), which can be handed over to the browsers. If you need to be on the European Trust List, you need to hand the CAR over to the supervisory body. We now have about 1-year’s experience with this process. Let us know if you have questions.

Question: I noticed the QCP policy, are you doing any more audits on the LCP policies?

Answer: Yes. The standards have been transferred, so the ETSI technical specifications have been converted to European Norms, and what you are referring to can be found under 390-E and 390-411, and we can issue certificates under those.

Slides 12 and 13 – The diagram on Slide 12 shows that it is like a set of Lego blocks that can be added to and taken from depending on what your needs are. There are bricks dealing with technical devices, bricks dealing with interfaces, bricks dealing with trustworthy operations, bricks for validation services, etc. That is the big advantage of this modular framework. The green ticks on Slide 12 indicate that they have been adopted as European Norms. The process to make something a European Norm takes time, so ETSI first publishes it as a standard.

Slide 14 – Standards are available for download at http://www.etsi.org/standards%E2%80%90search. The most important standard for this group is EN 319 411. July 1, 2016 is the date when eIDAS comes into force.

Slide 15 – Current ETSI work includes the items on Slide 15.

Slide 16 – Shows additional work underway or planned.

Slide 17 – The diagram on Slide 17 presents a simplified scheme. Starting with the TSP, it has a checklist to review and use in order to evaluate and claim its conformance to eIDAS and CA/B Forum requirements. The TSP then enters into a contract with the Conformity Assessment Body (CAB). Then the CAB sends the report to the eIDAS Supervisory Body or the application provider / browsers, as the case may be.

Question: When the TSP sends the assessment report to the application provider, the application provider then verifies the report. There is a field in the Mozilla CA database for inputting the URL of the audit report and for the CAB’s accreditation. Let’s say that the TSP is located in the Czech Republic. If I look up the Czech Republic body’s list of certifications, there are all of these certifications for gas, textiles, etc. How do I find the certification for a TSP providing digital certificates?

Answer: Now with ACAB’C, it is their business to answer it. If a CAB is accredited in Europe, it can audit and certify in all European countries. First, ask for the certificate of the TSP and look for the Conformity Assessment Body’s accreditation. This will help you track back via the European accreditation scheme to the CAB’s accreditation. There will be an identification number for the body, and you can enter this into the database of the local country’s accreditation body.

Question: Isn’t this the same question we’ve asked before at other CA/B Forum meetings? As the parent CA, you’re expected to look through and make sure that all of your subordinates are adhering to the Baseline Requirements. So basically it is the same problem that root program administrators have had to deal with, and the answer from the past few meetings has been that you get the audit cover letter, the CAB’s conformance assessment report, and that CAB is accredited by the accreditation body, and then you want to validate the CAB’s accreditation with the National Accreditation Body (NAB). That is where the EA comes into play. Then, from the top down, it’s EA-NAB-CAB-CAR-TSP.

Answer: In order to make it even easier, we set up this Accredited Conformity Assessment Bodies’ Council, ACAB’C. We’re still starting and collecting information about accredited CABs, and we have some applications now.

Question: I am hoping you’ll have a solution, because I look at these CARs and AAs and sometimes I can’t see that seal that points to the NAB. And in the Mozilla database you want to be more specific, rather than general.

Answer: It is not a commercial system using a seal. It is based on regulation, so obviously it is more complex.

Comment: For all of the hassle that you have to do, even when you get a WebTrust report, you have to look very carefully at what it says. Were they omitting findings from reports, and such? So either way, you have to be diligent about the way that the auditor prepared that report, to escalate things with CPA Canada, etc. The ETSI reports are at least clean in that respect, but it is still hard to identify the provenance of them.

Response: To say it simply, there is no single way to establish trust in a global environment, but we’re working on a good solution.

Slide 20 – This map of Europe shows the number of TSPs/CAs in Europe issuing qualified certificates.

Slide 21 – As stated previously during the meetings, there are no CAs issuing Qualified Website Authentication Certificates (QWACs). However, several have audits performed. They are in the process of handing over the reports to the Supervisory Bodies.

Comment: The ACAB’C web page only has two CABs-TUViT and LSTI. It would help if the links provided were to the National Accreditation Body of the CABs, directly.

Response: This is the start of the site, and we’re working on a new web page, and we’ll certainly address your comment.

Question: Do you have more applications from CABs outside of Germany and France?

Answer: Yes. ACAB’C has received additional applications from Italy, Germany, and the Netherlands. There are also CABs that have been accredited in other countries such as Spain, Italy and Portugal.

WebTrust Update

Note Taker: Kirk

Don Sheehy and Jeff Ward provided the following WebTrust update.

Current Status of WebTrust Projects – ongoing

WebTrust for CA 2.x – being updated minor changes now
WebTrust – EV – developed in concert with CAB Forum Version 1.6 coming
WebTrust Baseline and NS version 2.1- update complete – to be issued shortly
RFC 5280 EV Code signing – no current update

Other Projects – Current Status

WebTrust for RAs – first significant draft being reviewed, will need CAB comments
WebTrust Code signing – under development
Practitioner Guidance for auditors – under development
Audit reporting package – completed – developing additional package under new auditing standards

Web page

List of authorized WebTrust practitioners updated
Web page is being changed to take out SOC 3 seal termination
Plan is for revamp of the page as part of CPA Canada

Some new and old issues

RFC 5280 inclusion – still waiting for guidance from Forum as to which RFCs are in scope.
Issues in Network Security leading to qualifications
Cloud questions continuing to surface
The attest/assurance standards are changing in US and Canada
Changes coming to Task Force
Audit reporting issues
Symantec – KPMG has issued point in time reports – clean reports
WoSign report – discussed at length at last WebTrust for CA meeting. Given clean report despite number of issues noted in report under emphasis of matter. Should have been qualified. Changes are expected
As part of reporting templates will be provided, will provide a sample report that discusses each section of the audit report to provide guidance to the browsers (what they should be looking for etc.)

Audit reporting issues – questions posed

Gap in how new CAs are reported – not covered in the prior audit and it could be a year or more before the next audit report is issued that covers the new CA. Group will propose that the CA operator publicly issue a letter, similar to a “gap” or “bridge” letter or continuing operations notice, which asserts they have created the CA and that they commit to covering it under existing controls.
The group would probably need to develop a template for consistency with the look and detail of content being reported. Another option – auditor to do a point in time report to covering the signing, transfer or cross signing of a new Root or Sub. It would be modeled on the existing Root Key Signing report that is in existence.
One of the illustrative audit reports, Example US1.4, includes and additional statement (“provided its CA services in accordance with its disclosed practices, including ABC-CA CP (including sections 1, 2, 3, 4, 5, 6, 7, 8, and 9) and ABC-CA CPS that is consistent with the ABC-CA CP (including sections 1, 2, 3, 4, 5, 6, 7, 8, and 9) “). Several browsers we have spoken with have made it clear that they already expect that this is something auditors are checking this already. What would it take to add this to the “standard” reporting?
The section was extracted from a specific federal bridge requirement. Technically the information is already included within the WebTrust report within first two bullets points of the auditor’s opinion.
SSAE No. 18 was released earlier this year. What impact will this have on WebTrust audits in 2017?
New standard should not impact the WebTrust examinations/audits. The reports themselves may look different or new words will be used but the content will be more or less the same. There will be some additional requirements for the auditor, such obtaining an understanding of internal audit or compliance groups as well as reviewing any audit reports issued. For the WebTrust examination/audit you should not need to do anything different or create any new documents. The standard change will have the biggest impact on Service Organization Type 1 reports.
We continue to be interested in any work that would clarify how a CA operator can receive WebTrust seal(s) when using service providers who are separately audited for portions of their operations. I know the Task Force has identified RAs as a key area here, but the other end of the pipeline (physical storage of HSMs and certificate manufacturing) is equally important.
Working on potential solutions based on current standards. WebTrust seal does require inclusive approach

Audit questions

Need to create English report for CPA Canada to attach to seal ( no matter what native language) – can also have native but must be one English
How to deal with qualified reports and seals
Associated subordinates etc. in audit report – audit report needs to be specific

CPA Canada Staff, Task Force Members, and Technical Support Volunteers: Gord Beal, Bryan Walker, and Lori Anastacio

Task Force Members and Technical Support Volunteers: Don Sheehy (Co-Chair), Deloitte; Daniel Adam, Deloitte; Jeff Ward (Co-Chair), BDO; 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
Bryan Walker – Task Force support, seal system responsibility, licensing advisor
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
Changes coming before next meeting

Guest Speaker, Patrick Donahue, Cloudflare

CA-B Slides – Patrick Donahue – 2016-10-19

Day 2 – Thursday, October 20

Review of IPR Procedures

Note Taker: Rick

Kirk provided a recap of where we’re at with the IPR Policy. He said that the current plan is to present three ballots simultaneously:

A: re-adoption of all BRs except for Section 3.2.2.4, which will be replaced with “any other method”. The goal is to get most everything re-adopted as quickly as possible.
B: includes Ballot 169 options that we believe won’t raise any Exclusion Notices
C: includes the other methods from Ballot 169 that have raised Exclusion Notices; this would also include the removal of “any other method”

Jeremy brought up his recent pre-ballot about CNAME-based validation, and asked how we should we handle that. Should we ballot it first so it can be added to Ballot C? He’d prefer not to wait until after A, B and C are resolved. He would like to get it in by Ballot 169’s effective date of March 2017.

Kirk said there’s been some discussion that we can’t do new ballots until we resolve A and B. He said that we could put it in C, but that might slow down C. Jeremy thought his CNAME ballot was ready to go, but he’s held off because of uncertainty about IPR. Someone asked Jeremy to summarize his proposal: he gave a brief summary, but this is the exact wording presented in Jeremy’s email dated 9/14/2016: Confirming the Applicant’s control over the requested FQDN by:

(1) Verifying the existence of a Validation Sub Domain of the requested FQDN that includes a pre-appended underscore character;
(2) Verifying the existence of a second Validation Sub Domain that is under an FQDN verified as owned or under Applicant’s control using one of the methods permitted under Section 3.2.2.4; and
(3) Verifying that the Validation Sub Domain under (1) has a CNAME record pointing to the second Validation Sub Domain verified under (2)

Jeremy thought that there wouldn’t be any Exclusion Notices, so he thought that it wouldn’t slow down Ballot C. Kirk asked if there were any objections to putting Jeremy’s method into Ballot C; no objections were raised.

Kirk went on to say that we expect Exclusion Notices to show up for Ballot C; if they do, we’ll form a PAG and discuss them. Then we’ll see what the PAG recommends.

Assuming that all three ballots get adopted, then we’ll be in compliance with our IPR policy. We could then have ballots on parts of the BRs and EVGLs. In the meantime, we can vote on ballots for non-IP issues like changes to bylaws.

Geoff raised an exception about Jeremy’s CNAME method – weren’t concerns presented on the list about the process? Jeremy thought that he had addressed concerns raised by everyone. Kirk suggested that we do a straw poll or informal vote to see if everyone agrees that it can go into Ballot C.

Kirk then showed a sample Review Notice, which would come out in the middle of every ballot review. The Notice would state whether it’s for Final maintenance Guidelines (which would have a 30 day review) or Final Guidelines (which would have a 60 day review). He also showed an Exclusion Notice sample form, in which the patent holder must state whether or not they grant a license. Dean asked if Virginia was in agreement. Virginia was on the call and agreed.

Kirk said he is going to clean up Ballots A, B and C. The bylaws say there needs to be a week of review and then a vote, but they say nothing about a straw ballot. He thinks that we can have a straw ballot that’s not binding under the bylaws. He’ll get that going in the coming week. And Jeremy said he would recirculate his ballot and ask for a straw vote to include it in C.

(After lunch, we briefly returned to this topic)

Jeremy asked about the impact of the date of Ballot 169 if we’re still dealing with Ballots A, B, C. Kirk said that the “any other method” would be added in Ballots A and B, even for EV (“any other method” is not permitted today for EV).

Ryan said that CA use “any other method” at their peril; that the goal should be to not go beyond methods 1-10 from Ballot 169. Jeremy said that he didn’t want “any other method” included, but their team (and presumably the teams of all CAs) has very little time to figure out a method that’s not encumbered by IP.

Ryan said that once Ballot A passes, CAs can perform unencumbered methods under “any other method”. If Ballot B is approved and we’re working on Ballot C, Ryan said that CAs have options available to them.

Doug asked Kirk about Ballot C: would it have an effective date, and if so, what would it be? Kirk said that a deadline would be relevant only if you can’t perform “any other method”. Kirk felt that Ballot C was going to change, once we get Exclusion Notices. Doug thought that the effective date wouldn’t be March 1.

Peter said that if Ballot B passes with at least one method, and “any other method”, then compliance for audit is set. But at a root program level, Ryan says it’s not an open set – CAs better use one of the known options from Ballot 169. Geoff agreed that he doesn’t want CAs to use methods not mentioned in Ballot 169.

Peter said that under the IPR, we’re not supposed to be passing ballots that are encumbered (stated as an objective). Gerv said that the objective was to allow compliance without IPR-encumbered methods. He didn’t think it was a given that every ‘or’ in a clause must be unencumbered. Virginia pointed out that this was modeled after the W3C policy, to ensure things aren’t encumbered.

Gerv said that if there are sufficient unencumbered methods, CAs that hold IP on methods should be able to use them. Ryan said that if we end up with the same Exclusion Notices in Ballot C, it will be an interesting conversation if those methods remain.

Wayne went back to Geoff’s statement that all methods used must be part of Ballot 169. Wayne said that 169 includes “/.well-known” and he suspected that not all CAs were using that path. Wayne asked if Geoff’s expectation was that all CAs will comply exactly? Geoff and Ryan agreed, that’s a good example, but by March 1, yes, everyone must use “/.well-known”. Ryan added that his expectation was that by March 1, CAs have switched to approved methods.

Jeremy asked Ryan if he was going to declare this in Google’s root program requirements. Ryan said yes, he have to communicate with program members. Like with their CT requirements, he would communicate it; but he can’t speak for other browsers. Wayne added that lots of CAs aren’t here to hear this. Ryan agree that yes, we’ll have to communicate this, regardless of compliance changes.

CT Redaction

Note Taker: Gerv

CT Redaction, Oct 2016 Dean: is this a question for the IETF, or for here? Opinions both ways. Let’s talk about it. Peter: This discussion is really about customer privacy. Peter then summarised what CT is and how it works, noting the CT log either has full certificates, or a “pre-cert” which has full certificates but no embedded CT info. Client support:

Mozilla Firefox – 2017
Apple – iOS 10 and macOS Sierra allows applications to require CT
Chrome – EV since 2015, all new certificates starting Oct 2017
OpenSSL 1.0.2 (no validation, just parsing)

Mozilla and Apple don’t have log policies yet. Jody: Microsoft has talked about CT, but lack of redaction was a deal-breaker up to now Geoff: For Apple, no info on trusted logs because we don’t do anything with the logs at the moment (so no policy). In the future, when we do more with CT, we will need a log policy. Privacy problems may occur with:

FQDN (secret.project.example.com or even secretproject.com)
Subject attributes (binding a company to a domain name, personal names)

RFC 6962-bis, produced by the “trans” working group at IETF, has two options for privacy:

Use wildcards (allows privacy for left-most label)
Use name-constrained subordinate CAs

A separate draft proposes a 3rd option:

Pre-certificates with some subject information omitted

Choosing a certificate profile with less subject information is also an option.

Ryan S: IETF tries very hard to avoid policy, and focusses on the underlying technical underpinnings.

Ryan H: Chrome is willing to implement policy and technical accommodations to allow for the concept of redaction in cases where it makes sense. The call for scenarios is about figuring out what those cases are.

Ben W: So the suggestion is just to use DV to redact subject information?

Ryan S: So the concern is the corporate binding.

Chris B: Hostnames are descriptive (payroll1.domain.com etc.) – larger customers are concerned that it’s a descriptive blueprint of network topology. Wildcards are a poor workaround.

Ryan H: Take hololens.com. You can issue a certificate without logging it, and have it not be trusted by UAs, but have a developer override to allow you to trust it. This allows for development, as you can tell the browser to just trust it.

Ryan S: Already today there’s a way in Chrome for orgs to indicate that they have no care for CT within a namespace.

Gerv: But that requires all browsers on all machines in your enterprise to understand this policy. Is there other technology like that.

Ryan S: Yes – enterprises might use their own roots, which you have to add.

Peter: Doesn’t Android N make it hard to add roots?

Ryan S: Yes.

Rick: We have one customer at least which is experiencing scalability problems with the Google policy mechanism, because they have thousands of domains they want to exclude.

Rick: What if you want to keep a certificate secret, but then use it publicly later?

Gerv: Log it later, then OCSP staple the SCTs. Or reissue the cert.

Rick: The former has compatibility and support issues. Reissuance is a pain.

Eric M: We need to exercise some leadership here; corps may say “I can’t do that”, but what they mean is “I can’t do that without workflow changes”. Be prepared to push back.

Ryan H: People who claim they absolutely need redaction also allow complete zone transfers from their DNS servers. So actually, they don’t realize their situation.

Peter collected use cases for privacy on a slide:

Binding of domain name to corporate entity (domain name uses proxy registration)
PII in certain certificate types (qualified?)
Overly-descriptive labels in FQDNs (provides a blueprint of network topology)
Disclosure of confidential projects (newthing.example.com or fordacquisition.gm.com – may be public at a future point)
Private DNS subtree (e.g. corp.example.com subtree is permanently private)
Split horizon DNS (e.g. two copies of the DNS zone)

Eric M: Once the certificate is deployed, the cat is out of the bag – redaction doesn’t really help you

Eric M: What’s the negative externality of revealing private DNS names, other than making security teams uncomfortable? If there is a threat, it’s not a privacy one, it’s a security one.

Ryan H: One of the (few!) beautiful things about DNS is that it’s a massively-distributed cache. People think split horizon DNS gives them DNS privacy, but that’s not really true. I could map a large portion of the internal Microsoft DNS by looking at the DNS queries made on the local Starbucks WiFi.

Kirk: Hasn’t CT had mission creep? Wasn’t the original reason for CT to allow domain owners to detect certificates mis-issued in their domain?

Ryan H: I used to be Jody, and I created the first root program contract with Microsoft. My biggest challenge is that I didn’t know what CAs were doing. People said what their practices are, but there often turned out to be an “except…”. There was no way I could tell what was going on. 5 years ago, there were 6 proposals to replace PKI, and the reason these proposals have gone away is that there’s now visibility into the practices and procedures of CAs. CAs have a chance to earn the trust of people, view what they do, and hold them accountable. The value of CT is to make CAs accountable to the relying party.

Ryan S: CT is first and foremost an accountability measure. We can use it to evaluate auditors, and whether CAs are following their stated policies.

Eric M: Anecdote – we made a list of all publicly accessible sites in the US Federal Government, and several agencies were like “Wow, we had no idea we had that”.

Ryan S: It’s useful to discuss the role of CT, but let’s circle back because the IETF is meeting next month in Seoul. Topic: what is the role of redaction and information hiding on a technical level, and a big driver is to have clearly-articulated use cases, so we can begin exploring technical solutions. Or decide we can’t solve the problem with tech, and it needs policies. So everyone needs to make sure they submit their use cases for redaction and make sure they are heard.

Network and Certificate System Security Requirements: Challenges, Interpretations

ncssr-slides

Peter Bowen Start: 11:18am, End: 12:09pm Note Taker: J.C. Jones

Peter Bowen: Don/Jeff brought this up originally. NCSSR passed some years ago in reaction to DigiNotar, effective 1 Jan 2013, and never amended. Started with SSL Baseline version 2.0, starting 1 July 2014. All WebTrust CAs have already been through this at least once. ETSI it was in 2013, and included in the new guidelines, so all ETSI CAs have too. NCSSR is pretty detailed. Definitions are very broad.

Gerv Markham: Your CDN needs to be in the audit?

Peter Bowen: That’s one of the questions – are you using a CDN for OCSP? Is it included in the audit? Since we’ve been so prescriptive, some of the requirements imply you must have a database server, etc.

We don’t define remote access. But then there’s an exception. Is the office network covered? Do they have to patch, if they can write that patching adds instability.

Don Sheehy: They have to make the argument.

Ryan Sleevi: It’s going to depend on the technical savviness of the auditor.

Don Sheehy: And it assumes they provide evidence.

Jeremy Rowley: How do we even know they’re monitoring patches?

Don Sheehy: They have to document it.

Peter Bowen: You can get around this by having a documented plan.

Jeremy Rowley: Perhaps the wording should have been that the CA evaluated each and made a decision.

Ryan Sleevi: If an auditor is not looking closely, there’s that element of auditor discretion that could result in different results. If there was an example of a bad patch, maybe the plan is to not apply any more patches.

Peter Bowen: Qualification – on the WebTrust side – we have at least one program that requires seals, so if you’ve a qualification, you don’t get a seal.

Jeremy Rowley: Maybe we should make the qualification less of a big deal, rather than have CAs feel they have to hide things.

Wayne Thayer: I think the structure of the process today where if you’re perfect you get a seal, it encourages people to do everything they can to find loopholes and reduce the transparency. We’d be much better off if we could come up with a process that encourages disclosure without making a qualified audit.

Jeremy Rowley: This has handicapped us in the past.

Arno Fiedler: We try to push our CAs to be a lot quicker than the 6 months in NCSSR.

Jeremy Rowley: 6 months wasn’t the original proposal, but it got put in there simply because nobody could get a qualified audit.

Alex Wight: Recommended by who?

Peter Bowen: I want to do the second part of this side. Regarding multi-factor authentication, every OS can do it, so what about machines that don’t have a network?

Jeremy Rowley: This came from the Microsoft root program.

Jody Cloutier: This got flushed from the guidelines in 2015.

Peter Bowen: Auditors tend to like words, and specificity. We have a Zone definition, a Secure Zone definition, and then they are used in a conflicting fashion.

Robin Alden: Are you suggesting that these are not perfect requirements?

Peter Bowen: I don’t have an answer to that, but we have this conflict.

Arno Fiedler: For us as auditors, this issue is very important. We need to harmonize.

Ryan Hurst: This is still my least favorite document.

Gerv Markham: Do you have more examples, or can we go on to how to fix it?

Peter Bowen: We also have some really _interesting_ requirements in this doc. For accounts that aren’t publicly accessible, we require 12 characters, but for publicly accessible, we require 8. Or you can implement another procedure.

Jeremy Rowley: This was designed this way, so that everyone could pass this audit.

Alex Wight: It seems disingenuous to write these requirements when this consortium isn’t the technical experts.

Ryan Sleevi: Yes, these were the concerns. We knew it would be odd. When it comes to something any/or, it shouldn’t be about making sure people pass their audits. It’s to provide relying parties the assurance they need to make reasonable and rational decisions. So you should publicly document how it works.

Jeremy Rowley: When this was adopted, it was intended that we’d revise these, and have one for operational vs physical security. It was supposed to be revised, and that wasn’t done.

Ryan Sleevi: Some of these things are holding back better security.

Jody Cloutier: What do we do about it?

Jeremy Rowley: A lot of CAs before this weren’t doing anything for security.

Ryan Hurst: I think we need a WG to work on this again. This was filtered from Symantec documentation. I participated, so I take blame in what has ultimately manifest here.

Alex Wight: Anecdote from Cisco, we passed our audit with no qualifications. We had pen testers internal hit from physical to all logical security and they found a number of critical things, so we changed our practices as a result, but we passed WebTrust without making those changes.

Gerv Markham: 3 months ago I would have said let’s get rid of this document. Then I investigated WoSign and found they hadn’t patched their servers for 5 years, and now I found I couldn’t complain about it without this document. I’m now of the opinion that we need something, but I’m also of the opinion that we shouldn’t have something that needs the CABForum to maintain it. We should find another group that maintains a good document.

Ryan Hurst: It’s the wrong solution to provide proscriptive guidance. We should provide a threat model and require it to be addressed. For example, my auditor can ask me to explain how I mitigate Threat 1.2.3.4.

Dean Coclin: These things exist today, not specific to a CA. Aren’t there things for high security environments?

Ryan Hurst: Our problem is that we’re substantially different than existing systems.

Dean Coclin: I’m not talking about this document. Speaking of the rest of the industry, is there a control list somewhere?

Ken Myers (phone): Federal government does have PKI-specific overlays to the 800-53 family of controls.

Eric Mill: There’s wide latitude on the part of the authorizing official on the part of 800-53. It’s not very proscriptive.

Ken Myers (phone): It’s just a risk assessment.

Peter Bowen: To Robin’s point before, I brought this up because it’s actively preventing forward movement on security practices. We could build a WG and produce a process, but it’ll take probably 2 years to fix that.

Jeremy Rowley: Perhaps amend this document to remove the parts that inhibit progress while also forming a WG.

Ryan Sleevi: Risk I’d see with that approach may be making the document worse.

Jeremy Rowley: Should we get rid of the network security guidelines?

Ryan Sleevi: There’s an element as to how much this actually improves things.

Jeremy Rowley: It affects sub-CAs, and this has improved for the sub-CAs.

Ryan Sleevi: A great topic for the next group!

Ben Wilson: One more thing, if we do away with the Network Security guidelines, there’s section 5 of the BRs that talk about doing annual audits and protecting the security of the system. We can look at that, as it’s a useful section.

Ryan Hurst: Many auditors don’t have the technical capability to evaluate the quality of the risk assessment, they can only evaluate whether an assessment was performed.

Jeremy Rowley: That language was in there before DigiNotar; they had a risk assessment. There have to be some minimum guidelines for CAs, or we go back to the wild west days.

Ryan Hurst: Re: HSMs, the FIPS statement is a proxy for a real guideline.

Dean Coclin: What are our next steps?

Peter Bowen: What can we do, as a Forum, that doesn’t result in a qualified audit problem?

Don Sheehy: In terms of our development, the expectation is you won’t create this thing overnight. We could expedite the changes pretty quickly.

Jeremy Rowley: Immediately after we complete our revisions, we could be evaluated it?

Don Sheehy: Browsers, are you more interested in the seal, or the list of what they found?

Jody Cloutier: It’s not an issue we’ve thought about very much. Speaking for Microsoft, I care most about being transparent about what’s going on with that CA. It’s nice to have a perfect CA so it’s nice to have a complete disclosure, and then we can make our own decision. We have to be careful with how we word that so that CAs know what to expect.

Governance Change

Note Taker: Tim

Discussion of “Summary and Open Questions 10-18-2016”

Gov Change WG – Summary and Open Questions 10-18-2016.pdf

We will create new working groups where actual promulgation guidelines will happen; nothing like that will happen at the forum level.

We will have three: Server Auth, Code Signing, S/Mime … may create more later.

People who are interested should start thinking about what the charter should say, who can be a member, what relying parties, and so on. There may be a draft template of how a charter should look.

Where do charters go? Appendix to BRs?

Q (Dean): How would a new working group be formed? Kirk: By ballot at the forum level.

Andrew: Rules around any document a group might produce, for example, how to de-conflict what rules apply to which certificates.

Kirk: the main forum is responsible to resolve conflicts between working groups.

Ben: Who is interested in working on the charter for S/MIME? (11 people). Ben will send an email out.

Dimitris: Timestamping is used by both code signing and document signing, and there might be conflicts there.

Various people: perhaps document signing should be included in code signing. perhaps client auth should be part of S/MIME. Timestamping definitely should be part of code signing.

Jeremy: If people are interested in these other topics, maybe we can get started earlier.

Dimitris: Should we expand code signing to object signing?

Ryan: Groups with expanded scope might cause the same sort of IPR concerns that caused problems in the first place.

Kirk: At this point, we are not going to try to impose a subset of the BRs on working groups; if it becomes a problem, we can revisit.

Ryan: How does IPR work with respect to in person meetings? Do you have to leave the room when a working group you are not part of is having a discussion?

Kirk: We have to be very tight about who can speak during a working group meeting. Can people who are not in the working group listen in?

Ryan: Is there a public/management distinction for working groups going forward?

Jeremy: I think you need a management only working group list.

Dean: why not one management list for whole forum?

Jeremy: there are IPR concerns if (for example) non-members of the working group comment on draft minutes.

Virginia: There should be a general license like the W3C has so that there are fewer concerns about who is/is not in particular meetings.

Ryan: Is there one in-person meeting for all working groups or separate meetings for each?

Tim: CAs will participate in almost all working groups, so one meeting makes more sense.

Peter: Some companies have patents that they want to reserve the right to assert, which is why we are moving to a participation model.

Kirk: Plenary sessions may end up being very short. Some working groups may choose to have extended or alternative meetings and that’s probably ok.

Chris: Is there some mechanism for working groups to share common work?

Ryan: We might need a baseline working group.

Kirk would like to work with Ben and Virginia on resolving the remaining IPR issues once the structural aspects of the re-organization are better defined.

Disclosure of Subordinate CAs

subca-slides

Note Taker: Wayne Thayer

Led by Peter Bowen

Mozilla has required that all subordinate CAs be disclosed. They also require audit reports covering all of these CAs – this is causing issues

Peter presented a few slides (Peter Bowen SubCA-slides.pdf): Slide #3: Some sub-CAs are not listed on audit reports but must be disclosed Slide #4 Each circle is an issuer Colors are signature type – colors are unrelated to previous slide

Issues with audit reports: – Many reports only list roots – Many CA “names” in reports are partial or abbreviated – New subordinate certificates are not added until next audit period after they are issued

Sleevi: CAs must disclose every CA they sign to Mozilla

Need to make sure we have some consistent binding between audit report and keys. One approach is to add explicit identifier of certificate into management report or CP/CPS

Gerv: a number of CAs are missing data (crt.sh has found around 230 certificates that have not been disclosed)

URL for the report: https://crt.sh/mozilla-disclosures

Doug: should we upload things that don’t need disclosure but are flagged on crt.sh?

Gerv responds: first talk to Rob Stradling and try to resolve the issue. Ultimately crt.sh should list zero undisclosed certificates.

Dean: do people outside the CA/Browser Forum know about this? Answer – yes, Mozilla contacted everyone in the Mozilla root program

Ryan: people have been busy but as time becomes available Mozilla will be scrutinizing this more closely

Peter: no guarantee that all subordinates listed in Mozilla database are covered by audit reports. Gerv & Ryan said that this will be checked

Wayne: what’s the problem that Peter has?

Ryan: when new subordinates are found, they’re not always in audit reports. It’s partially a timing issue.

Peter: Showing an example from Amazon, when a new CA is created it should be disclosed to Mozilla but it’s not in my audit report. What do I do?

Gerv: One end of the spectrum is adding another intermediate under existing policies. Other end is a new subordinate with entirely new processes & policies.

Don: CAs are obligated by WebTrust to advise auditor of significant changes, at which point the auditor is likely to conduct a point in time audit.

Gerv: do we need a definition for ‘significant’?

Ben: that doesn’t solve the problem. We need to know what URL to enter into Salesforce when we spin up a new CA. Use existing audit URL?

Gerv: that works for non-significant changes

Ryan: Need a solution across the spectrum that works for everyone.

Peter: I sent a proposal to the list modeled on SOC audits (https://lists.cabforum.org/pipermail/public/2016-September/008464.html ) – a “bridge letter” that covers the interim until the next audit. Linking to an existing audit from a past period without the intermediate doesn’t make sense.

Don: bridge letters only work when there’s no change – a new intermediate is a change.

Alex: is it okay with Browsers to just include in next report?

Ryan: looking for assertion of what CPS this will be covered under.

Clemens: isn’t that a question of how we maintain the validity of the certificate? Then should we require CA to enter maintenance agreement with auditor so that every change will have auditor involvement and in the case of a new sub CA the auditor would review the change and take appropriate action

Ryan: we already expect that auditors will evaluate changes to the CAs

Gerv: if there is a management assertion for every new CA, then there should be some delineation between situations that require a point in time audit versus just a letter

Steve Medin: Is it meaningful to state that a previous audit covers almost all of the controls applicable to the new sub-CA?

Ryan: that’s the question. We want to make sure your auditor will look at the new subordinate at next audit, showing the evidence that the CA is managed as expected.

Steve: can we just assert the old audit?

Ryan: we want to know which CP/CPS will cover this

Peter: showed sample management assertion that covers the information Ryan is looking for (see Word doc attached tohttps://lists.cabforum.org/pipermail/public/2016-September/008464.html)

Ben: who is the audience for these reports?

“”Peter: this is what you would link the Mozilla tracker to

“”Apple: what’s the timing on this?

Peter: I already have to go to policy authority to create new sub-ca

Ryan: within 2 weeks of CA creation, and before it issues any certificate

Wayne: what’s auditor’s involvement?

Peter: none, this is purely a management assertion

Don: add time period (one day?) to assertion that ‘Management is not aware of any material breaches’

Dean: there’s an opportunity to discuss this further at the next WebTrust meeting

Potential Change to Browser UI for Subject DN

potential-change-to-browser-ui-for-subject-dn-of-ev-certificate

CAA Consensus

Note Taker: Alex Wight

Rick A: 2 main issues:

Whether we should implement a capability for hard fail if a CAA records mismatch is discovered
Should the CAA check be performed at the time of certificate issuance of domain validation (LE does it at domain validation, Bruce suggested for Enterprise accts. w/pre-validated domain would it be OK to do it then)

Gerv M: 1 advantage of issuance time is that it allows a customer to impose it in real-time/immediately. Can a customer request the CA throw away the CAA cache?

Ryan S: Intent of CAA was to check it at issuance time. Spec is clear that you can’t retroactively evaluate a certificate against a CAA policy (it’s not future nor past-looking statement). 39 month use of cached info is concerning – perhaps a shorter window could be used if it’s not necessary to check at issuance.

Gerv M: Was the standard designed to address issuance vs. dv time? Issuance was the spirit of the spec.

Wayne Thayer: Issuance time is a nebulous term. Much cleaner to check CAA when in process of doing validation. Do you have to do it every time a certificate is issued?

Ryan S: Strawman–Can do CAA check at any point in I&A but can only rely on that check within 14 days of the check.

Peter B: Order-based CAs – no persistent relationship with a customer. CSR submitted, credit card, etc. CA initiates the process and at the end for EV, customer gets the cert.

Ryan S: 30 day “caching” of validated information for other registration data. Already an established practice in CABF.

Rick A: DNS TTL could be used?? No matter what the customer wants, the cache out there won’t reflect their wishes until TTL expires.

Gerv M: Should CAs always get an authoritative answer from DNS (non-cached)

Ryan S: Rick, how do you feel about the 14 day strawman?

Rick A: I’ll defer to my team. Bruce?

Bruce M: We have a long-term relationship from an Enterprise customer. If the CAA check was good yesterday it’s probably good for the foreseeable future.

Ryan S: We may not have articulated all of the potential use-cases for CAA. Once Ballot C finishes, we’ll have a bunch of validation methods. We have a technical measure to enforce org policy. There’s nothing in the BRs to allow a domain holder to express in their policy who can request certificates from. Most interesting for Google – exploring methods to obtain the cert, and the type of certificate to obtain, expressed via policy rather than technical (e.g. pinning). CAA is designed in a way to be extensible for precisely this purpose. What do we solve with tech vs. policy? Solving via paperwork requires a lot more work in the long run.

Phillip H-B: As far as going back to IETF is concerned, all it takes to create a new tag is to write up the spec. Can go draft but that isn’t essential. Merely needs to be something that says what has to happen. Request IANA for a tag to be assigned, reviewed by the expert (who is Phillip). As far as the type of additional restrictions, those have appeared in the spec at one time. Taken out to allow it to go through as easily as possible. Once you have “only these CAs can issue”, then you choose the CAs that implement the restriction that you want. If you have a subset of the CAs that enforce the tag, then that is sufficient.

Peter B: confused about what are we trying to work around? Hard fail is the question, but there’s isn’t much CAA usage today, what is the risk being mitigated?

Ryan S: How do I express to you in a way you must respect that only CA (x) is authorized? BRs only allow me to tell you if I’m already a Subscriber, but nothing if I’m just a domain holder.

Rick A: my objection to hard fail is where we check the record, it’s incorrect, customer says this is urgent, we need this right now!

Peter B: We have a list of domains that we consider high-risk. Our internal procedure is where we email the domain registrant only and say “will you authorize this AWS acct. to request certificates?” Not, “do you authorize issuance”, but, “do you authorize this AWS account to be a valid requestor”. Sometimes it takes weeks, they insist it’s important, but it’s part of dealing with high-risk domains, we think it’s important.

Gerv M: designing the process with companies who can’t change DNS quickly privileges the incoherent companies over companies that want to do things right.

Eric (GSA): For place that aren’t tech companies, locating important trust decisions in DNS isn’t in their DNA. DNS may seem like the center of the universe for tech companies, but it’s not necessarily the case for other types of companies.

Ryan S: It’s not necessarily saying DNS is better, just saying it’s better than, say, file-based.

Jeremy R: IT departments shouldn’t be able to express policy

Alex W: IT departments can express/break policy in all kinds of ways

Ryan S: If we enable hard-fail, we can enable policy enforcement technologically, and work through problems in the future as they arise.

Gerv M: The value CAA provides is the “weakest link” scenario. This allowing companies to set the policy and forcing CAs to respect it. CAA hasn’t achieved much adoption. I propose CAs respect it and document incidents where it causes problems. If there’s many problems then we’ll rethink it, otherwise let’s adopt and move forward.

Eric (GSA): There’s options with hard-fail that give you meaningful protection, but all aspects address the “weakest link” problem. Even a naive implementation will help, there’s clear value. There’s a middle ground.

Phillip H-B: One of the big problems we’ve had is that we’ve never had a clear model for how you go about the communication. You have an assertion about a domain name, it will go one place – DNS. If we move to that model where we come with clear rules, that’s easier for all concerned in the long run. There will always be people who come up with emergencies, but is a person’s emergency worth putting my brand/CA at risk? Will be rare. Want to get to the point where we shut down some of the vulnerability channels. If we do it industry-wide, then everyone plays by the same rules then the “weakest link” is solved.

Jeremy R: I see a huge middle ground between now vs. hard-fail. I’d much rather see implemented as a requirement for CAs to check and then re-evaluate it in the future. If it truly is a policy then a contract should be able to override/overrule it.

Ryan S: I think you’re missing the concern, if we go down the policy route we won’t find it acceptable. I’m open to figuring out a better policy solution if needed. I’m not saying tech overall, but if we want to go down policy-override methods, then let’s be very specific about them and document them clearly.

Bruce M: New vs. Existing customers – Enterprise RA, certificate approver, already defined. On board with Phil shutting down vulnerability channels. I thought we could define critical flag in CAA records where critical flag is your hard stop. Can a customer put in CAA a couple of ways, one that can be overridden with contract/policy, the other is hard fail.

Dean C: Core group active in discussion. Consensus on some, debate on some. Committee of interested parties could work more and come up with a core concept that hits the middle ground / sweet spot.

Gerv M: Mozilla is keen to see CAA serving a useful role in preventing mis-issuance. If the CABF can’t figure it out, then we will, but we’d prefer the CABF to figure it out. Let’s make it happen.

Core group/committee who will continue the discussion and draft a proposal: Bruce Morton, Gervase Markham, Jeremy Rowley, Phill Hallam-Baker, Rick Andrews, Ryan Sleevi

Non-FIPS algorithms for customer public keys and certificate signing

beyond-fips

Note Taker: Eric

Beyond FIPS.pdf

Ken Myers: 4096-bit is one of the things that FPKI is going to be coordinating on with NIST. They may have just gotten caught up with the NSA transition beyond ECC. Not sure, but something that FPKI is collaborating with NIST on.

Ben Wilson: In the past, industry may have been catching up with government, the DoD and FPKI set the standards along with NIST, but now it seems like industry has surpassed the government, so now if we try to stay with things that reference NIST, it’s holding us back.

Peter: Why do we talk about FIPS and FIPS 140? Ensures that when you do key pair generation and validation, proper generation procedure is followed.

Ryan S: That’s not everything. We require Level 3, and Level 3 requires enclosed hardware. What it gives you is private key zeroization (an assurance that no key material is left recoverable under an event, like a power event). Essentially assures that there is some role separation. Level 3 triggers physical protection, including electromagnetic interference, and differential power analysis. At Level 2, you don’t have to worry about EM shielding or DPA, it gives you tamper resistance for up to 30 minutes. Level 3 ratchets this up to 8 hours. Level 4 provides assurance about source control, development methodologies, etc. Another thing to touch on is that it’s overseen by a joint US-Canadian lab cooperation, but has mutual recognition in 16 other countries. Most important thing is that FIPS provides key protection - is it physically and logically protected? That said, FIPS is terrible. If you take a pure literalist approach to FIPS, it doesn’t prevent RCE or a backdoor in the source code. And if an RCE or backdoor is found, you are not allowed to patch without invalidating your FIPS status.

Ryan S: NIST will let you do a “fast track” approach to review patches in 6 months.

Chris Bailey from Entrust: All these standards, I have some healthy fear that some might not be as peer-reviewed as others.

Ryan S: NIST standards on random number generation had some notably suspicious operations, but don’t want to go into fearmongering so much as going into the threat modeling. Physical security, etc. are concrete threats that we’re defending against with FIPS. So we want to articulate what we’re defending against. In terms of standardization, it’s all awful. For all of NIST’s warts, they’re still way ahead of the curve than a lot of people (for example, deprecating SHA-1 much earlier than most).

Tim H: It’s largely the same people going back and forth between these meetings. The most interesting thing about FIPS is that people were saying things were AES when they weren’t AES, we’ve moved beyond that, but we’re calling it out on device protection. Being FIPS-validated vs being in FIPS mode is an interesting question, but for the most part FIPS mode exists to disable algorithms that don’t appear in FIPS.

Ryan S: Sure, FIPS mode is an interoperability profile more than anything. To be clear, only threat isn’t key protection. To Peter’s question, what’s the role of Common Criteria etc., there are some profiles that might give us some understanding of this without going through the special hell of reviewing every security patch.

Tim H: We should consider being explicit that you can run outside of FIPS mode.

Peter: I generally support that, but someone could factor all of the Singapore ID cards because Singapore didn’t use FIPS mode and the non-FIPS mode didn’t use a proper RNG.

Geoff: Maybe in non-FIPS mode they’ll turn off features to get better performance.

Peter: We’re definitely not running all CAs in FIPS mode today, if we have 4096-bit CAs in HSMs.

Tim Wight: FIPS can’t keep up with today’s pace of operations. We just can’t run stuff in FIPS mode, but we could say that it could use an HSM that has been evaluated by FIPS or Common Criteria, and then iterate through what security properties we expect. We should care more about security properties being met.

Peter: Current status with FIPS is, it’s interesting. Ken was pointing out that there’s work on it, a draft just got thrown out, another one may happen, there was some issue with a political appointee not being around to approve something. NIST is moving on to PQ, too.

Ryan S: One subtle correction, there’s “FIPS validation” (you’ve gone through the algorithm validation, ensures your i’s dotted and t’s crossed), you get a certificate. But in addition to that on your hardware, there’s a FIPS-approved “mode of operation” with a policy document that attaches to it. You don’t always have to enshrine policy in code. You can say, in order to consider something in FIPS mode by saying that you’re only allowed to log in more than twice a day. Some controls can be procedural. At the level 2 validations, this is common, you buy particular stickers and that’s part of tamper resistance. In level 3, there’s a spectrum, where the hardware physically won’t allow you to put the 4096-bit key in it, and some where it tells you *should* not do this.

Peter: Several of the large HSM vendors have tried to make it very simple to meet FIPS mode, so they have a boolean flag, which does things like reject keys larger than 3072 bits.

Curt Spann: You talked about listing security properties, but who’s going to audit it?

Ryan S: Same issue with FIPS, we want things with decent physical security, these are the first principles we’re trying to get. If the question is, who validates, there’s nothing to just grab off the shelf, so how do we transition from what we have now to what we want.

Tim H: Something we might want to look at is the more modern kinds of tamper resistance, some of those specs have been updated in various ISO standards. For example, in financial services industries, they have HSM certifications we could look into.

Peter: We’re talking about 4096, which is easy. But we also have ECDSA coming down the pipeline, we’re probably within 3 months of a CFRG draft of how to do signatures for ECDSA. Then by the end of 2017 by the worst, we’ll have the certificate ECDSA draft. Dunno if browsers will implement it in that timeframe, but we’re not far enough. Then we’ll have challenges, because it’s not just a parameter change. For Common Criteria, most of the protection profiles have expired. Secure signature creation devices (SSCDs) may or may not meet CA standards. For offline roots, we usually keep these things in safe. But physical protection of 30 minutes vs 8 hours, well, the safe provides more than that. For PQ, key size will be a thing - you couldn’t fit into e.g. SafeNet given their limit. There are these things called programmable HSMs, which give you the best of both worlds.

Tim H: As someone who’s programmed one of these, I think you misspoke, it’s the worst of both worlds.

Peter: Something we might want to make clear in our standards, that it doesn’t have to run in FIPS mode to qualify, and we should be explicit about this for audits.

Tim H: When a SafeNet had a critical vulnerability addressed, we had to do a firmware update, we have to apply that patch right now. It took another 9 months to go through FIPS, so if we’d been running in FIPS mode we’d have been out of FIPS mode til we got it evaluated.

Dean: Where should we go?

Peter: It sounds like non-FIPS mode is acceptable.

Dean: We could invite SafeNet or one of them to a future meeting.

Ryan S: Non-FIPS mode is useful, but I want to make sure we’re looking at the threat model. We’ve looked at other vendors and worked with several labs, and, for lack of a better word, “FIPS juicers” who help you work your way through the lab. There are things you can do that common sense says aren’t so great, but which can get you through the process. We want illustrative controls, we want to not let it be a free-for-all. We should say that the vendor has protections around key zeroization, features that are meaningful to the threat. The ambiguity in the current BRs is not ideal, so maybe what we’re talking about is a mechanical change. But if we do go to non-FIPS mode, we should have some basic agreement on what we’re trying to accomplish, so that when we try to capture that text, we’re evaluating it against that.

Tim H: Let’s find some other specifications to point at, to say you get his, this, and this.

Ryan S: Even if you’re not in FIPS mode, you get such and such. When I say short-term solution, hopefully it will not be controversial and takes 2 years. I realized adding requirements is controversial, but I’m talking about adding examples.

Dean: That’s one option. Is there another, could our federal partners help us, would that help solve the issue?

Ryan S: That gets at 4096, but it doesn’t necessarily get at other things like ECDSA that could take much longer. We’ll also want to get to Post Quantum. Also, NSA’s recommendation to go back from ECC to RSA was a big deal.

Peter: The good and bad news is, other than RSA 4096, for other things to even be usable we’ve got another year, so we have time to bash our HSM friends over the head.

Jeremy: Besides vendors, Microsoft and Mozilla have policy levers to affect those curves, any idea if these are going to change so we can start using new curves.

Peter: So 25519 and curves that require e.g. EDDSA, the question is when do we update the policy vs the hardware. Question is, should we amend the BRs to allow us to do this once we find the right hardware?

Ryan S: I don’t think this is something that has to be done in a serial fashion, vs waiting on the IETF to get standard guidance. NIST provides interoperability, and we don’t want one CA to sign with “ECDSA” but it looks mangled, etc. Those things aside, nothing that should gate browser acceptance.

Discuss F2F Meeting 40 in Cupertino, CA and future meeting volunteers

Note Taker: Arno

2017 February: USA, Host and exact date will be defined soon, suggested date February 7-9

2017 June: Germany, Berlin, D-TRUST, suggest date June 20-22

2017 October: Taiwan, Taipei, Chunghwa Telecom, confirmed Date October 3-5 Oct 2017

2018 Volunteers: Apple, Cupertino and HARICA, Greece

Latest releases

Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed CSC-25: Import EV Guidelines to CS Baseline Requirements by @dzacharo in https://github.com/cabforum/code-signing/pull/38 Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.6 - Ballot SMC08 - Aug 29, 2024

This ballot sets a date by which issuance of certificates following the Legacy generation profiles must cease. It also includes the following minor updates: Pins the domain validation procedures to v 2.0.5 of the TLS Baseline Requirements while the ballot activity for multi-perspective validation is concluded, and the SMCWG determines its corresponding course of action; Updates the reference for SmtpUTF8Mailbox from RFC 8398 to RFC 9598; and Small text corrections in the Reference section

Network and Certificate System Security Requirements
v2.0 - Ballot NS-003 - Jun 26, 2024

Ballot NS-003: Restructure the NCSSRs in https://github.com/cabforum/netsec/pull/35