Day 1 – Wednesday, February 17
Attendance: https://public.etherpad-mozilla.org/p/cabf-scottsdale/timeslider#690
Browser News
Google
Note Taker: Bruce
Chrome 48 shipped dev tools security panel, connection tab is going away and will go to developer tools.
Chrome 49 deprecating the key gen tag and ability to install client certificates will be going away. Note that client certificates are incompatible for HTTP/2 or connection multiplexing. An alternative for client certificates would be the FIDO standards.
Expect CT will be launched as the preliminary for MUST CT. There are some issues with receiving the OCSP responses for CT. Site administrators can turn on Expect CT for testing. This is just for test, before we go to MUST CT. Plan for a preloaded list of sites for those that are interested. MUST CT would mean that the site must be logged. If the site is not logged, then connection should fail as the certificate must have been miss-issued. It was asked, how will Expect CT be gated? It will be gated on public roots as the CT logs should not use private roots.
Preloaded HSTS has gone significantly more mainstreamed. It has doubled from 3600 to 7000. This list is also used by Apple and Mozilla. The preloaded list will help with first use and for renewal.
Google has noticed problems with OCSP Stapling. Issues for OCSP Stapling are discussed on the Mozilla discussion group.
Google is still experimenting with the removal of EV. Google may remove EV treatment in the future. Continued user research shows that the users do not know what EV means and there is some confusion. EV is currently benefiting Google as the certificates have been publicly logged, so EV is hanging on.
Google plans to deprecate SHA-1 as of January 1, 2017 for Chrome on all platforms. Google may plan to accelerate deprecation to June 1 or July 1.
As a follow to the presentation, Ryan provided more information on how Chrome is continuing to investigate the root causes of clock skew to better understand the risks, particularly with respect to OCSP stapling and short-lived certificates. https://groups.google.com/a/chromium.org/d/msg/chromium-dev/owc7DJkg098/d8k0LyrgAgAJ has more details on this.
Mozilla
Note Taker: Jeremy
1. Mozilla has removed the last 1024-bit root. Several other roots were removed as well. https://bugzilla.mozilla.org/show_bug.cgi?id=1156844
2. RC4 is entirely disabled by default. Telemetry of RC4 usage: http://mzl.la/1Kqbh70 RC4 deprecation blog post: https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/
3. SHA-1 support for SHA1 certs with a notBefore date after Jan 1, 2016 was disabled. SHA-1 disablement bug: https://bugzilla.mozilla.org/show_bug.cgi?id=942515 SHA-1 MITM problems blogpost: https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/
4. Short-lived certificate support is enabled. Anything with a maximum lifecycle of 10 days will not check revocation information. Short-lived certs implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1141189 Short-lived certs enablement: https://bugzilla.mozilla.org/show_bug.cgi?id=1228451
5. Must-staple is enabled in Firefox 45. Must-staple implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=901698
6. OneCRL was deployed a while ago. Firefox checks for updates to this list every 24 hours. Mozilla plans to have this backed by salesforce data. CAs should enter revoked info into salesforce right away.
7. Mozilla is moving towards its long-term plan for revocation. CA certificates are currently checked by OneCRL. EE certs use OnecRL for high profile certs, short-lived certs for validity periods less than 10 days, stapled OCSP responses, must staple, and hard-fail with OCSP. The only one done is the hard-fail with live OCSP. Currently, 17% of responses use stapled OCSP responses. Before they will turn on hard-fail, they want a union of (1) stapled, (2) short-lived, and (3) successful live OCSP to be > 99.9% (i.e., a < 0.1% failure rate). RevocationStapled OCSP telemetry: http://mzl.la/1UKs4SO Stapled OCSP trend line: https://ipv.sx/telemetry/general-v2.html?channels=%20release&measure=SSL_OCSP_STAPLING&target=1 Certificate Lifetime histogram: http://mzl.la/1UKsgS4 Plan: https://wiki.mozilla.org/CA:RevocationPlan
8. Mozilla implemented its plan to continue providing seamless downloads of Firefox to browsers which support only SHA-1, while avoiding certificate warnings or errors in new browsers. For your interest, the components of the solution were as follows: (A) Move www.mozilla.org to Cloudflare, which offers cert switching based on ClientHello fingerprinting. (B) XP SP2 clients get a download of Firefox 43.0.1, which is the last version we signed with SHA-1. The internal updater then takes care of bringing them up to the latest version. Our updater understands SHA-2, so it’s not a problem. This means we don’t have to keep doing SHA-1 codesigning. (C) Our download service continues to use SHA-1 certs; links to this service are never rendered in the browser address bar and so do not cause warnings. So we can continue using SHA-1 on the download service until the end of 2016. In 2017, when browsers will refuse such connections entirely, if we continue to support XPSP2, we will probably make www.mozilla.org redirect clients to two different download servers.
9. Mixed Content Blocking. By default Mozilla blocks active mixed content and lets through passive mixed content, but in each case it affects the state of the lock, adding a warning triangle. It’s now a few more clicks to override the blocking, as Mozilla has streamlined the top-level UI as part of the package of UI changes we made, by removing the separate mixed content indicator.
10. Kathleen plans to finish issuing CA Community Salesforce licenses to included CAs around end of February. All CAs that already have their CA Community license should be entering their non-technically-constrained intermediate certs as described in the instructions on the wiki. They should also enter their revoked intermediate certs, for them to be added to OneCRL. Salesforce Root Store Community information: https://wiki.mozilla.org/CA:SalesforceCommunity:RootStoreMembers
Kathleen plans to send a CA Communication in Q1. It will include target dates by which both of these two filing processes will need to be completed. On a related point, we have been observing some inaccuracies in replies by CAs to questions in the CA Communication. This is concerning to us, and we are pondering what action we can take. I’m sure all the CAs here know that misleading or incorrect answers might lead to a sense of humour failure.
11. Kathleen is working on a policy and getting legal agreement for multiple root stores to share Salesforce – a Root Store Community. The idea is that CAs would be able to enter their data into one place and indicate which root stores they wish to be updated. The root store operators will be able share in verification of data, but will make independent decisions. Once the policy and agreements are in place, the root store operators will need to meet to design the customizations for Mozilla’s instance of Salesforce to do this. So, it will be a while before this common shared data system is ready. Microsoft, Google, Apple, and Oracle are all aware of this idea. Opera uses Mozilla’s root store as-is, so they won’t need it.
12. Mozilla is working on revising its root store policy to version 2.3
13. Mozilla decided to remove the code-signing trust bit from the Mozilla program. This will be done after the next version of the policy (i.e. 2.3) is published. The email trust bit will be retained for now.
14. Certlint. Mozilla recently added https://cert-checker.allizom.org/ (certlint) to the Information Verification process for root inclusion/change requests. So make sure certs pass certlint.
15. Mozilla is developing SCT checking but is not sure what they will do with it.
Opera
Note Taker: Cecilia
Message from Håvard Molland
We are making changes, but mostly those we inherit from Chromium, and some other changes in our independent UI, so this time our news will be mostly covered in the Chromium section.
We don’t have CT in stable yet, but it is out in dev. Other than that we have the same changes as Chromium regarding ciphers and other lower level protocol changes.
Apple
Note Taker: Rick
Geoff reported: Since the last meeting we attended, we released iOS 9, it has:
name constraint checking
OCSP stapling
CT SCT checking (checks the signature on the SCT, no reporting back of certs without SCTs, no announced policy).
He said that they expect to bring these to OS X in the future. They Will eventually use same trust evaluation code across both platforms, so if a TLS certificate fails on one it will fail on the other.
Apple announced that they are interested in improving revocation checking. At present only EV certificates are revocation checked for SSL and a soft-fail only removes the EV treatment.
Mat said that they care deeply about the transition to SHA-2. They would like all CAs to communicate their plans about SHA-2 for each root. All CAs should be issuing SHA-2 certs at this point, but Apple would like to see the distribution of expiration dates of SHA-1 certs from each root. For example, under Root A, we have 900 SHA-1 certs expiring in June 2016, 750 SHA-1 certs expiring in July 2016, etc. Mat requested that CAs send info to certificate-authority-program@group.apple.com .
Rick asked about Safari support for the keygen tag; Safari does support it. Geoff said that there was talk of removing it, but he didn’t know of any plans to remove it.
How does Apple feel about EIDAS? – Geoff said he was thankful for suggestions on UI change. He said that the other part related to trust stores was a very interesting concept. Apple would be interested in how liability works in that model. If an EU CA went horribly wrong (which has already happened) would that be resolved via a democratic process in the European country, and would Apple get a vote on it?
Microsoft
Note Taker: Arno Fiedler
Browser News: Microsoft Christy McKinley
1. Microsoft Trusted Root Certificate: Due to new Program and Audit Requirements, and the new Program Agreement, Microsoft released an update in January removing all CAs who had not signed the new Agreement. However, only a few Roots and CA are removed.
2. MS uses actually “Friendly Names” for tracking the CA´s, this will potentially change to “Common Name”, looking for procedures to keep the tracking consistent when Roots and CAs changes ownership and/or Brandname like Verisign did. Feedback welcome. Question: Is the UI changing when showing the CA name? No Ben suggest to check and compare tracking of Roots with Mozilla Database.
3. SHA-1 deprecations, couple of issues using SHA-2, caveat: if a SHA-1 CA is issuing SHA-256 EndEntity Certs its treated as SHA-1, the treatment with SHA-1 Roots in the chain needs clarification.
4. For CodeSigning Certs SHA-1 is deprecated, also Certs issued before 2016 are covered
5. Couple of CA use different company names, CAs must choose and use one company name in correspondence/requests to Microsoft.
6. eIDAS: MS is still reviewing the opinion on qualified Trust Services, now checking if products can benefit from eIDAS like Office 365, adopting a non Microsoft Trust-service Status List is difficult.
Working Group Reports
Validation Working Group
Still trying to eliminate #7 “Any Other Method” by updated existing proposed methods. The proposed methods were discussed again by the working group on Tuesday.
A new draft will be discussed tomorrow, then the draft will be returned to the working group for one or two meetings before a ballot.
This will be a dynamic process, with continued improvements after the ballot, but Kirk would like to finalize the existing ballot and remove #7 within a month or two.
Policy Working Group
Note Taker: Robin
Policy. brief overview earlier today on mail list from Ben.
The group looked into requests by several members that the Baseline Requirements and EV Guidelines be amended to address what should be in the locality field and the state/province field when the Subject’s country does not have those political subdivisions, the organization is chartered or operated at the national level, or other similar situations. Examples discussed included: U.S. Government entities, entities in Singapore, Taiwan, Greece, Vatican City, etc. The consensus of the group was that for the Baseline Requirements (see BR Section 7.1.4.2.2. subsections d. and e.), it is not an insurmountable hurdle for to have a locality or state/province for the physical location (and jurisdiction of organization is not an issue like it might be under the EV Guidelines) and moreover, that for the EV Guidelines, Section 9.2.5 adequately describes how to handle the use case scenarios presented in the requests made—i.e., for an entity chartered at the national level, the locality and state/province are omitted.
E.g. FBI headquartered in NYC, but talking about the Kansas city office – which address do you put – probably not important.. Kirk: we authenticate the customer. We don’t care where the server is.
The group also reviewed section 7.1 and addressed serial number entropy. Suggested language was
“Serial numbers for certificates must be greater than zero (0). For End Entity Certificates and Certificates issued to Intermediate CAs after , CAs MUST use a Certificate serialNumber containing at least 64 unpredictable bits.” (changing from SHOULD and 20 bits)
The group decided we need a definition for “End Entity Certificate” and that we should review our documents and use the term “End Entity” instead of Subscriber when needed to distinguish end entities from subscribers who are subordinate CAs.
Code Signing Working Group
Note Taker: Neil
Dean: Following the Code Signing BR Ballot failure, the group is now considering next steps. Prior to Jody’s sabbatical leave, there were discussions with Microsoft regarding making Code Signing requirements part of CS root programme, but any change in programme will need to wait until Jody returns.
Since there is still a desire in the working group to continue the development of standards for Code Signing, various forward-looking options were outlined:
1. Hand over the existing draft document to Microsoft as is, so that it can adopt it as a compliance standard. This did not attract much support, since it would seem unlikely that Application Software Subscribers would wish to continue development on it.
2. Keep document in the existing WG, but as non-ratified. Similarly, this did not attract widespread support.
3. Hand over to a CS sub-forum or committee, with interested CS parties. This committee would maintain its own IPR documents, ideally becoming more amenable to bodies who did not favour the existing CA/B Forum IPR regime. This attracted some support. Some concern was expressed that the existing CA/B Forum owns relevant IP rights, e.g. EV Code Signing. Consequently, some form of licensing transfer to the notional sub-forum/committee would need to be effected.
4. More broadly: to restructure the governance model of the entire CA/B Forum: the idea being that CA/B Forum be divided into multiple sub-fora or committees.
An example structure was suggested.
CA/B Forum as a supervisor or overarching governance unit. Example subordinate units could be:
SSL committee
S/MIME committee
Code Signing committee
Document Signing committee
Each committee would possess its own IPR, develop and maintain its own membership criteria, bylaws and document repositories.
The SSL committee would likely contain the existing CA/B Forum membership.
Code Signing would be those parties already in WG, plus such organisations which feel unable to participate under the existing aegis.
Since the scope of this option is complex and far-reaching, lots of discussion would still be required.
The adoption of the requirements by Microsoft will not be held up by any governance reform. Thus code signing CA members are urged to comply with the BR document as it exists today. Auditors are working with the draft from ballot, creating audit requirements based upon that.
Information Sharing Working Group
Ben revised the existing Memorandum of Understanding for Information Sharing, walked through the draft with the working group on Tuesday. He still needs to finish taking out the U.S. specific parts like references to the Cybersecurity Information Sharing Act of 2015. It was discussed whether using New York Law for interpretation of the MOU is ok, working group had no objections. Ben wants members to forward the MOU to their legal counsel for review and feedback. Sharing in the context of the MOU is voluntary, but the MOU provides uniform ground rules for sharing and the use of a uniform, agreed upon framework may reduce liability.
Kirk: How would sharing happen in practice? Ben: At first, information would be shared via email. Working group will also write up a series of use cases and scenarios for how information should be shared and what the privacy issues are.
Gerv: It seems to me most of the plans are CAs sharing information among CAs about threats to CAs; are browsers expected to participate in information sharing? Ben: It depends on the use cases. Gerv: Confidentiality and NDAs provide a particular problem for Mozilla, so we are unlikely to participate for now, but we will reconsider if there are compelling use cases where browser participation would be helpful.
ETSI Presentations
Note Taker: Connie
ETSI presentation is provided by Inigo
This is the last ETSI Presentation in this way – because CAB is not a legal entity and that makes it difficult for ETSI. The reason for the “possible” last presentation is because the STF is finished due to the entrance of the eIDAS in July this year. So, from now on, is probably that ETSI will be represented by ETSI employees, for example, the ESI secretariat.
There were some open questions from the last meeting but those were related to audit/auditors issues, and this is not a task of ETSI. At the STF we´ve been trying to give a response but since the ACAB-c is formed then those questions should go to this organization and not to ETSI because it´s not an ETSI task. ETSI only develops standards but does nothing to do with audits, auditors, templates, etc.
The website to comment on the attestation letters is available – input from the browsers is welcome
Question and Answer
Question (Moudrick): Is the TSL in the eIDAS a new? Is there a difference between national and European TSL?
Answer: Arno answered this, but the new TSL is based on the TS 119 612 v2.1.1 whilst the current one is also based in the same standard but in prior versions. Basically the information will remain the same, but in the new one, there are new “qualified” services that are not covered in the current one, which is only focusing on the issuance of certificates.
Question: Where can I find the CABs?
Answer (Inigo): It was said that browsers should go to EA (European for Accreditation) to find the NAB of that country and there the accredited CABs, but with the new tasks assigned to ACAB-c it was decided to provide that information in the documentation to the browsers, in the certificate document.
Guest Speaker Session: Presentation on RDAP (Francisco Arias, ICANN)
Note Taker: Gerv
Presentation: 
ICANN_update
A formal presentation was given; these notes supplement the slides.
RDAP is a replacement for WHOIS.
WHOIS is such a simple protocol it’s barely a protocol:
There is no standardized format
It’s not internationalized
…
RDAP was designed by the IETF WIERDS WG in order to replace WHOIS. Use it to find data about domain names, IP addresses and Autonomous Systems.
There is a feature list in the presentation.
Has been in development for nearly 5 years, starting with a SSCA recommendation in Sept 2011
No date yet set for sunsetting WHOIS for gTLDs (ccTLDs will decide themselves anyway)
Also migrating to Thick WHOIS for all gTLDs (i.e. all information being available from registry rather than having to refer to the registrar). But a complex migration – will take time.
Q: Is differentiated access in use today? Only 3 TLDs (.name, .cat and .tel) have provisions in their contracts which allow this; the rest have to show all info to anyone who asks. And those 3 haven’t implemented RDAP.
Q: What are the use cases for differentiated access? And isn’t 1300 different logins a management nightmare? Yes – there have been called for federated login. But also differentiated access is controversial – right to privacy vs. right to know who owns a domain, law enforcement etc.
Q: What consideration has been given to the problems of differences between the two data sources, given that RDAP is richer than WHOIS? Yes, it’s difficult.
Q: Could you use the extensibility of RDAP to do a domain ownership proof protocol by putting a token into the response? Yes, interesting idea.
Lunch Break
Guest Speaker Session: Potential Updates to new gTLDs (Francisco Arias, ICANN)
Note Taker: Andrew Whalley
Presentation: ICANN_update
A formal presentation was given; these notes supplement the slides.
ICANN maintains a CSV file of the new gTLDs at https://newgtlds.icann.org/newgtlds.csv, which is updated a few times a day.
For the first time a new gTLD is going to be removed (.doosan)
ICANN is proposing a V2 CSV file format, with an updated schema including a removal date, and a boolean denoting if it’s a Brand TLD (specification13)
It was noted that knowing if a gTLD was valid at a point in time, as well as specification13 information, is useful when validating certificate requests that include wildcards.
Q: Will .doosan be removed from the V1 schema file? A: Most likely
Q: Is there an intention to backfill the file with previous gTLDs?
There was discussion about if it would be useful to have the file be a comprehensive resource of all valid TLDs.
A: ICANN has information about some other TLDs, but not in the same backend system. Also things like .mil and .int aren’t gTLDs and don’t have a relationship with ICANN, and ccTLDs are managed by IANA. Francisco will investigate.
Q: Is it possible for a new gTLD to drop specification13 after acquiring it? A: Yes, it can change either way. But it’s not expected to be common.
Q: Are there plans to create another big batch of gTLDs? A: Yes, though the next round is going to take some time to launch, a couple of years. There are <1300 remaining applications and about 800 have been processed so far.
The forum warmly thanked Francisco for presenting.
WebTrust Update
Note Taker: Kirk Hall
Presentation: WebTrust Update
WebTrust for CA Update
Don Sheehy of Deloitte and Jeff Ward of BDO presented an update for WebTrust.
• WebTrust for CA 2.x – This is being updated for minor text changes at present – eventually will be modified based on issues with virtualized environment and other issues, as needed
• EV WebTrust – Version 1.5.6 coming
• Baseline Requirements WebTrust and Network Security – updating based on RFC 3647 changes and updates by CA/Browser Forum and increased inclusion of RFC 5280 requirements referenced in the BRs.
• EV Code signing – no current update
• WebTrust for Registration Authorities (RAs) – first significant draft being reviewed. What does Forum want to do with RAs for EV, etc.?
• WebTrust Code signing – starting development
• Practitioner Guidance for auditors – under development
• Audit reporting package (sample template audit letters, etc.) – almost complete 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 Brian Loney – seal billings and legal support
Task Force members all have experience in delivery of WebTrust services to clients.
Next, the rules for use of the WebTrust Seal were reviewed.
• Issuance of the Seal is strongly supported by CA/Browser Forum and Browser Community
• The Seal is a registered mark of CPA Canada
• CPA Canada grants the right to use the Seal under the license agreement
• Seals are issued by CPA Canada
• Auditor’s report and management assertions hosted by CPA Canada
• Auditor’s report and management assertions publicly available
• Seals valid for audit period plus 3 months
• CPA Canada can revoke seal at any time
• Providing all required information is submitted on a timely basis, the process to issue the seal will take 24 to 48 hours
The rules and requirements for being a licensed WebTrust auditor were reviewed.
• Licensees now provide information about the qualifications of the senior staff on the engagement.
• License is valid for one year. No automatic renewal of license.
• If license not renewed name will be removed from list of licensed practitioners.
• Licensees can be pre-qualified.
• Licensees must declare the professional standards that they will be reporting under (IFAC, AICPA or CPA Canada).
• Licensees must report based on the standards identified.
• Recent license changes
• License is valid for one year. No automatic renewal of license.
• If license not renewed name will be removed from list of licensed practitioners.
• Licensees can be pre-qualified.
• Licensees must declare the professional standards that they will be reporting under (IFAC, AICPA or CPA Canada).
• Licensees must report based on the standards identified.
• Recent license changes
Finally, Don provided information on understanding the WebTrust audit – what an audit does, and what it does not do.
A WebTrust audit is designed to provide reasonable assurance as to whether management’s assertion about meeting the relevant criteria is met. It should be noted that the auditor does not plan audits to achieve 100% reliance and the profession cannot reasonably build an audit to the level. The Task Force and CPA Canada do not have the ability to police the auditor procedures performed. CPA Canada retains the right to perform a quality review however.
Audit findings are based on a materiality concept – there can be issues found in an audit that do NOT cause a criteria not to be met. However, any significant exception/deviation should normally cause a qualification to an audit opinion (if the exception is relevant to the criteria being tested). An audit does not give 100% assurance of compliance on all issues.
Don then discussed the scope of the audit. For public SSL – WebTrust for CA v2.0 and WebTrust Baseline with Network Security. These are separate audits that cover distinct criteria, disclosures and control requirements, and they are reported upon separately. Only WebTrust for CAs v2.0 is required for CA/B membership. However, both are required to keep status in applicable Trusted Root Programs in most cases. For CAs with multiple SSL-related products, disclosures, policies and controls can be included in one CP/CPS – but will separated for the purposes of audit and reporting as required. Depending on the service there can be a number of audits.
Scope of the audit – again, WebTrust audits are based on criteria developed based on the CA/B requirements for each and are required to satisfy trusted root program requirements. A CA’s program can be part of one CP/CPS or separate ones, and will be reported upon separately by the auditor. There also can be specific additional criteria that are required by specific Browsers – this requires separate reporting where applicable
There are also Extended Validation and other audits. This raises the issue of disclosures, policies and controls relevant to a CA’s business that are the focus of a number of different and separate WebTrust audits. An issue in one audit will not normally require disclosure and impact assessment in a different audit (Baseline Requirements versus WebTrust for CAs, for example). There can also be unauditable items/disclosures that are CA-Browser Forum requirements but not WebTrust requirements.
Next, there was a discussion of the time coverage for an audit. The main difference is between point in time and period of time audits. A point in time audit covers design and implementation of policies, procedures and controls at a specific point in time (say June 30). No assurance on period before or after that date, and no assurance on effective operation of control of the CAs actual operations. A point in time audit is used for some first reports for trusted root programs.
A period of time audit covers design and implementation of policies, procedures and controls and their effective operation over a period of time. Coverage needs to be at least 2 months (with sufficient evidence), but normally cover a 12 month period. These audits are used for ongoing root requirements.
Finally, Don discussed how to report audit issues and problems. He recommended reporting an issue to the auditor, to the CA, and to CPA Canada as appropriate for investigations.
The WebTrust for CA Task Force does not have an obligation to validate the auditor or audit, because that would create a conflict of interest. However, questionable audit reports (e.g., not following standards) can be sent to the Task Force for comment but should also be sent to auditor, CA and CPA Canada.
CAA: Moving Forward
Note Taker: Marcelo Presentation: CAA Revisited Feb 2016
The topic was also discussed at Meeting 34 in Cupertino.
Pros:
It’s relative simple
Can be used to enforce corporate policy
It’s a preventive measure. Allows CAs cuting off issues before they actually happen
Cons:
Lack of CAA support in popular DNS servers and DNS hosting
It’s not effective unless all CAs check
Rick listed all CAs that currently are checking CAA Records.
It was provided a list of DNS solutions that support the CAA Records, including Bind 9.9.6 & 10.1.2, NSD 4.0.1, PowerDNS and Akamai that would like to inform its customer about CAA.
Critical mass of CAs now checking CAA records. Even with CAA checking mis-issuances are still possible.
Next Steps:
CAA support should be required of all CAs (straw poll)
It was about a year that it was discussed in the Forum and it was decided to leave a ballot for a later on.
We should formalize the process in BRs, including exceptions.
Mozilla has been unable to deploy CAA because their DNS provider does not support the record types.
Gerv: I would expect CAA to be deployed on High Value Sites only.
Complexity for enterprise trying to get it configured. They don’t have actually the whole understanding what they are doing.
Gerv: One can use CAA to get warnings about possible (although not certain) misissuance. Check CT log first, then CAA record to see whether it existed at the time when the CT log was captured the checking, and then if there is a possible mismatch you can investigate further.
Peter: For cert high value domains. They created a list of some “High Value Domains” For whatever reason, they are approving these things after a better thought. Contacting the Registrar Domain owner. The first reaction was no, then the customer called back asking to issue… Talking about the mis-issuance/Suspect of mis-issuance for specific domain, and also it would be applicable for the CAA records. People don’t tend to be willing to issue certificates that will affect DNS records.
Jeremy: 6 Records changed in just one day.
Rick: 120 hits against the DNS server on the CAA Records. Positive point it’s that it helps to validate whether the CA is authoritative.
Jeremy: Cases when issues happen related to CAA due to DNS that they tend to blame the CA and not the DNS Management company.
JC: Mentioned some issues on encryption error due to DNS error on CAA records.
Marcelo: We have 600 Domains, and we issue certificates for all of them, including DV and EMV Certificates. They are hosted in multiple DNS Services Providers. Then are some concerns on the DNS infrastructure that supports all these domains. The company has 2K+ Partners, with thousands of domains. I think it’s a good resource, but the issue I see is to make it a BR requirement. It’s not supported widely by all DNS providers. We are definitely not able to help them troubleshoot any DNS issues, or even accept the risk on they blame the company for any CA validation issue.
Straw poll: 11 Yes votes, 2 No Votes, 0 abstentions.
A ballot will be proposed for:
CAA Records to be required
Evaluate whether it should appear in CPS
If a mismatch occurs, it would be logged somehow.
Additional details are available from Rick’s presentation.
Membership applications and revisions to qualifications/categories. Nuanced to “trusted/non trusted” in root stores
Note Taker: Michael K
Should membership in CABF be limited for orgs running name-constrained CAs?
– Gerv: Suggestion that if CA is a government membership should not be limited but otherwise, would not qualify. – Ryan: Ideally get in front of the issue instead of dealing with specific requirement
Should membership require BR audit? – Suggestion was no (Google/Mozilla)… discussion dropped
Point in time vs. Period of time audit requirement – Suggestion that PIT would naturally be followed quickly by period in time audit so no point in requiring both – Proposal of codifying existing practices… Dean to put a ballot together
Forum scope and participation. Should other constituencies be represented?
Question: do the bylaws need to be changed to accommodate non-browser encryption uses? Note Taker: Mat
Example of other uses: ATM terminals and banks. Dean explains that there is an incident involving 100,000 terminals in March and 70,000 ATM’s and the associated party expressed interest in CABrowser involvement.
“Browsers lead the way” but the politics non-browser uses may drag us down.
Rob Alden: suggested everything must remain the same with the higher level CABrowser structure, these would be working groups or some sub-structure
Jeremy: IPR signature would be needed
Rick Andrews: with iOT there is a migration to private roots not a part of public CA roots.
Should we have a vote on :
Creation of working groups Deprecation of working groups
Ryan Sleevi noted that Scott Peterson attorney worked on W3C patent policy, and two approaches:
1. IETF and IESG where IPR is specific to working group approach – disclosures are tied to participation in that group. 2. W3C has an advisory board that does not have the obligation to trigger disclosure to documents, some W3C groups have high volume and high noise to signal at times.
Jeremy: EKU conflicts are to be managed by the top level.
Geoff K: Scope the working groups very finely for specific purposes.
Dean: how would membership of these working groups be determined?
Ben Wilson: let’s keep working group limited
Michael Kleiman: two questions, are we working with point in time or an ongoing need?
Marcel: mainframe certificate use is also troublesome. 2000 certificates issued to clients are involved. Maybe a working group is what is called for?
Dean: in 2 weeks, these groups want a solution. The specific request will be considered tomorrow.
Gerv: doesn’t scale well to set up specific groups that are all different.
Dean: advantage of smaller groups is speed, we could leave things where they are and address short term concerns with a document.
Wayne: just code-signing hack wouldn’t work as well as dedicated groups. Having two meetings at the same location could work. Let’s structure this right for the long term.
Kirk Hall pushes the point: what happens next? Let’s discuss scope tomorrow.
Diagram referenced:
CAB Forum non-Browser Groups
SSL
IPR
ByLaws Members
Document Signing Code Signing SMIME
Day 2 – Thursday, February 18
Attendanc