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]( 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⌖=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 {#Day_2_-_Thursday.2C_February_18}

Attendance: https://public.etherpad-mozilla.org/p/cabf-scottsdale

EV Wildcards

Note Taker: Robin

Dean summarized the discussions we’ve had so far on the pros and cons of EV wildcards which we have held at several F2F meetings.

(slides page 2) Current State • EV Guidelines say: – 9.2.2 Subject Alternate Name Extension:<

– This extension MUST contain one or more host Domain Name(s) owned or

(slides page 3) Points for Wildcard EV. •EVWC would permit greater adoption of EV and SSL –Convenient for customers; allows for securing an unlimited number of sub-domains, eliminating the need to know up front and requiring the issuance of separate certificates –Wildcards are easy to manage: Same cert for all servers –Wildcards provide a pre-determined price for securing all sub domains that SAN or individual certs do not offer –EVWC help those that have standardized on EV to be able to secure a broader portion of their website with less overhead and potentially, cost –Some orgs (i.e. Facebook) want to do sharding for performance (RS) •EVWC would allow easier issuance •Customers are increasingly asking for EVWCs –Would like to use EV throughout their environment –WCs are the fastest growing segment of SSL certificates –EV should have all the benefits of OV (JR) –EVWC allowed for .onion today (JR)

It was thought that EV wildcards would allow greater adoption of EV in general. They want to use EV, but can’t get a wildcard. Why should I go DV or OV to get wildcard. It is Counter-intuitive – because wildcards allowed only on the least vetted product.

Sub-section on Domain Sharding: From: https://www.maxcdn.com/one/visual-glossary/domain-sharding-2/ In an http 1.1 world (i.e. pre SPDY, pre HTTP2.0), by default, web browsers limit the number of active connections for each domain. When the number of resources to download (images, CSS, JavaScript, etc.) exceeds that limit, users experience slow page load times as downloads are queued. To work around this limitation, web services split content across multiple subdomains. Since browsers reset the connection limit for each domain, each additional (sub-)domain allows an additional number of active connections. This lets the user retrieve files from the same source with greater throughput. E.g. ww1.domain.com ww2.domain.com www3.domain.com images.domain.com there are also security reasons to do with scoping and sharing of cookies. Place your static resources on one sub-domain, user resources on another Each sub-domain gets its own certificate. That’s part of why EV lacking wildcards gets in the way.

page 4 Concerns Raised and Counterpoints •Wildcards have potential to be exploited in a phishing attack; can be used on subdomains like bankofamerica.foo.com (Kirk, Wayne)

Counterpoints:<

–Applicant has passed EV vetting and phishers don’t like to be identified

The wildcard would allow a homograph attack, whereas the explicit EV certificate would catch it.

•Hosting sites (i.e. *.appspot.com) that allow subscribers to upload a file and display that file to users driven to that page can use EVWC for phishing

Counterpoints:<

–Propose disallowing EVWC for such hosting sites. Restriction in subscriber agreements?

Ryan: If the propose mitigation is in the subscriber certificate, why would we not extend that same restriction to sites that allow the user to upload user content. – to prohibit them.

Wayne: I don’t think this is different from a multi-domain EV cert. This gets to the point of the entity identified in the subject is not necessarily who is running the website.

GM: That’s one of the counterpoints – that it leads to the problem, but maybe the subscriber limit addresses both. It’s not necessarily about user-uploaded content, e.g. I can register anything-i-want.appspot.com as long as noone else has it. Surely that is the problem rather than the content uploaded.

Ryan: Disagree. Google sees phishing attempts through google docs and forms. user controlled content (wordpress) not just uploaded..

That risk exists regardless of EV wildcards. Any 3rd party content is dangerous.

Gerv: Let’s focus on the differences between EV WC and standard EV

The difference between and EV WC and standard EV is the ability for the user to control what the star represents. It would be a resonable way to mitigate this issue, and probably to a great degree the issue of who’s in the O field, if you say that EVWC cant be issued to people who delegate subdomains to their customers – eg appspot.com

JR – what about universities..?

Gerv: Sure, but we can say that you can have any subdomain, but as soon as the customer gets to pick the name then EV WC is not suitable.

RS disagree. A variety of sites where the user has some control over the name. first 4 chars, or hash, … GM sure, where do we put the boundaries. The difference between EV and EVWC, the CA doesn’t get to see what goes where the star is. Need to make sure the entity named in the cert gets to choose the name. PZB – You say ‘control’ the name , but users can ‘effect’ the name by choosing a username of xn – – (blah) and therefore create an IDN. Amazon uses account number , dash, stuff you choose.

GM we need to decide whether we permit any control or all control of the names..

GM looking for a way forward.

GeoffK (Apple) – don’t see why there’s a need. whole point is stricter control and better security than OV. Gerv: The point is stronger real-world identity vetting. EV stronger than OV. GeoffK: Apple’s UI – EV says ‘Symantec identified www.apple.com as owned by Apple Inc, Cupertino, CA’ That statement doesn’t work with a wildcard. Symantec hasn’t heard of www.apple.com. They saw *.apple.com Gerv: Would require a change to the declaration, but the risk profile is the same. GM the wildcard would imply ownership of everything underneath. GK – but that now becomes a more nuanced and complex message to portray.

(discussion around www) If the cert includes apple.com and www.apple.com, EV only verifies the authorized domain – apple.com.

GM – as GK said, as long as we codify the browser statement in the EV standards, in that case then EV and EVWC has the same risk profile.

GK we don’t support EV for WC certs today. It would get downgraded. No plans to do change that..

Dean – our customers are asking for this. Could we try this for a while – say 2 years & see if the restrictions work. Straw Poll: Would you do a 2 yr trial? Previous straw poll results: For: Trustwave, Symantec, Google, Opera, Globalsign, Izenpe Against: Comodo, TurkTrust, Godaddy, Entrust, Trend Is that still the case? (on EV WC with restrictions to prevent WC issuance when anyone other than the subscriber gets to control any element of the (sub-)domain name. ) Robin: Comodo would probably vote ‘For’ Jeremy: We’re neutral. Kind of persuaded by the CDN issues. We would probably abstain. Wayne: Neutral too. Reservations about enforcing the restrictions. Bruce: Would have to think. Chris Bailey – no, can’t put it back in the box after a 2 year trial. Inigo: In favour of EVWC, but not of 2 year trial. – It would mean a change to ETSI standards – can’t cope with a 2yr trial.

Michael (Symantec) – objections seem to be where there is user-influenced creation of sub-domain names, and then enforcement of it. Ryan – the danger is in the definition of what is permitted. If you accept that any form of user control is bad, then any analytic scripts and ads could cause the content to change. All the same risk model. Phishing ads would be a risk. If you ban ads then that threatens the model of the web. Michael – i was talking about subdomain name, not the content. Ryan – the problem is the same

Michael – nothing stopping anyone with an EV site having 3rd party content on the site today.

Ricard Wang (WoSign) – imagine three sites, one DV, one OV, one EV. It is easy to identify the company name with EV. Ryan S – the point is that bankofamerica.facebook.com would show an EV name of Google, not BoA. Richard Wang – Yes, if you use EV it is easier for the customer to identify that this site is not ‘the real’ BoA.

Objections? Chris Bailey – We’ve had a lot of hosters in the past who have 0 control. They allow anything. We don’t want our name against that hosting company. EV is special. That’s the key. There is the potential to make more money with EVWC, but even so, we’d rather not. We (like others) look for (e.g.) ‘google’ in the subdomain as a possible indication of phishing. We couldn’t do that with WC. I don’t like WC. not a big fan.

Jeremy Rowley – RFC6125 came out and tried to deprecate WCs. The gist is that it’s too hard to do the matching properly. CABF considered it 4 years ago. Ryan – HTTPS and LDAP and XMPP had different policies on WC. 2818 allows foo.bar..com LDAP allows fr.domain.com RFC6125 says the same as the BRs – if the * appears it must be the entirety of the leftmost label. Always *.something. It’s the only sane matching. FF and chrome used to support ‘funky’ (i.e. pre-RFC6125) matching but (I think) doesn’t now.

Dean – we could consider proposing a ballot. but not sure it will pass.

Domain Validation Ballot

Note Taker: Doug

The latest ballot detail is documented in Domain Validation Draft (2-16-2016)

During the meeting we reviewed ValidationMethods-2016-02-17

Kirk presented the introduction:

• The group has been working on the technical details for the ballot for the last 9 months
• During this meeting we look to gain input and collect comments
• We can always add more methods later as they are needed
• The goal is to submit a final ballot in the next month or two.

Intro slide:

• No comments

Validation #1: Applicant is domain Registrant

• No comments

Definitions of Authorization Domain Name, Base Domain name and Random Value

• No Comments

Validation method #2: Use of Written Challenge: Send random Number via e-mail, Fax, SMS or Postal mail address.

• There was a short discussion about changing the definition to include RDAP, but this was determined to be un-necessary

Validation method #3: telephonic Challenge. Place a phone call

• The definition needs to be updated to indicate the CA receives a confirming response, as it stands the CA could place a phone call and then approve the request.

Validation method #4: Construct an email based on the Authorized Domain and one of the 5 approved values

• It was noted that you must use a random value for this method

Validation method #5: Domain Authorization Document

• This method was an existing method, but cleaned up. No comments

Definitions, Request Token:

• Robin pointed out that the Request token can be used in certain cases where the reseller is between the Applicant and the CA because the use of a random number might not be secure.
• The Request token binds the token to the key in the CSR
• Rock pointed out that the list of 4 examples is just that, an example, and that making this list might cause confusion. After some discussion we agreed to change the text to: Examples include, but are not limited to

Definition: Authorized Ports

• No discussion

Validation method #6: Validate content in a specific location

• Change “Either” to “One of the following”
• The following points were discussed in reference to item c):
• There is no time for reuse specified
• Does the certificate need to contain the same public key as was used in the CSR to construct the Request Token? Robin said yes, that was his intent, so this will be updated.
• There was general agreement that the Request Token should be changed from time to time, even if the applicant does not change their public keys. It was suggested that we update the request token to include a random component, maybe a date/time stamp, so the request token could have a defined lifetime.
• The VWG will work on this and address these comments

Validation method #7 (any other method) was deleted and replaced with the DNS method

• The group felt that the entry in DNS should have a tag prior to the Random Value or Request Token. Nothing needs to be “Registered” for this, we just need to define and document the value. The Validation Working Group will come up with a recommendation on the value of the tag.

Validation method #8: IP address control

• No comments

Validation method #9: Use of a Test Certificate

Ryan recommended the use of a defined Poison Extension, similar to PreCertificates, to make test certificates un-useable by browsers.

• There was also a recommendation that the Test Certificate have a defined period of use. Since it contains a validity period, the recommendation was to set this to no more than 3 days and require the certificate not be expired when validated.
• The VWG will review both recommendations and update Method #9

Guest Speaker Devdatta Akhawe, Dropbox

Dev’s presentation

Compliance Assessment Coordination with auditors and browsers

Note Taker: Bruce

Reviewing audit reports is done for new roots and on annual updates. Would like to change audits or audit reports to show what was audited.

ComSign applied for root inclusion. Within their CP/CPS, they list many items, provide policies and practices; however, many items appeared to be questionable. The CPS did not meet the format requirements for either RFC, but the audit was passed. Auditors appear to be looking at CA controls and evidence and that are not the CPS.

Some CAs say they were audited to an older version of the BRs; therefore it would appear that the CA only thinks the need to comply with the older version of the BRs. This is not correct as the BRs state that the CA has to have a CPS statement that they comply with the latest version of the BRs.

Would like a solution where the Auditors examine CP/CPS and state which parts of the documents were audited. This might be the best solution, but would like to agree to a solution which will satisfy all parties.

Comments: How do we create the perfect CPS? How does the auditor interpret what the CPS to what the CA is actually doing? Federal audit is to confirm that the CA meets the CPS. The first step is that the CPS matches the CP, the second is that the CA is audited to the CPS. Apple would like a simple audit report, basically Yes or No. Don stated that the current audit is close to the Yes or No format.

Ryan wanted to know, what is the CA position as to when the CA puts the BR changes in process? Don stated that some browsers wants the changes effective immediately and some when there were audit criteria created. There is always an issue that the audit criteria does not keep up to date with the BR changes. Bruce stated that the BRs are the policy and that practices should change in accordance with the effective dates. The audit criteria may follow along and be updated later.

Could the auditors make a report to determine that the CA has changed procedures for when the CA implemented changes from ballots.

Ryan wants the expectation that the CA will follow the latest version of the BRs even though the audit criteria have not been updated.

Proposal to change definition for Sub CAs

Note Taker: Michael

Rick presented the attached slides.

• Case study
• Reviewed current BR language on naming
• Issue is that the BR language is highly subjective
• Reviewed the feedback from others
• Based on feedback recommendation to narrowly scope follow up to just Sub-Cas (not revisit all trade name/trademark usage, including in end entity certificates)
• Discussion on updates to be made on the public mailing list.
• Rick to follow up with proposed ballot

Question on the problem: Issue is that this displays to relying parties to see who issued the end-entity cert.

Tools Demo

Note Taker: Rick

Peter Bowen (Amazon) and Rob Stradling (Comodo) demoed three relevant tools that make use of the good amount of CT data that we now have:

1. crt.sh (written by Rob) This tool looks at all known CT logs, gathers new records from them every 10 minutes, and allows searching of data from these records. It allows you to search all known certs by domain or by CA (or substring of CA name). Once you find a CA you can drill down into specific certs issued by that CA.

2. Peter created a tool called certlint that checks technical details about a cert for compliance with X.509, RFC 5280 and the BRs. Rob incorporated certlint into crt.sh. Once you find a certificate using crt.sh, you can click a link to run certlint on that cert.

crt.sh includes a dashboard that searches all certs issued in the last 7 days, and shows results (grouped by issuing CA) of errors, warnings and info flagged by certlint.

Mozilla has begun asking CAs to review the errors flagged by this tool for any new root certificate pending inclusion in Mozilla’s root store.

Someone asked about a message seen in certlint: “Cowardly refusing to run checks…” Peter said it means that certlint found a bad error and stopped checking to avoid cascading failures.

As an example of the checks performed, certlint flags certs with a Country Code that is not PrintableString, or is an invalid ISO 2-letter country code (for example, UK -invalid- instead of GB -valid-).

Mozilla’s maintenance policy says that if you issue too many bad certs, you may get impacted, so it will be helpful for CAs to check crt.sh’s weekly dashboard.

Could this be a replacement for audits? Don mentioned in Istanbul that tools like this that leverage CT data will help future audits. It could have significant impact. Don says it’s a tool that all three parties (CAs, browsers, auditors) could use. Gerv noted that audits currently sample 3% of issued certs, but with these tools you can search all certs for violations.

GoDaddy asked that if they leverage this, could they get assurances that the data is valid? That’s a challenge. Peter pointed out that there are two tools here: certlint, on github, under Apache license; which can run on your desktop, and crt.sh. Anyone is free to get and maintain their copy of certlint. Auditors should have their own version of certlint because the public versions could change over time. They could augment it with extra checks if desired.

3. Another cert database that CAs and auditors might be interested in is https://www.censys.io. It’s different from CT (where CAs submit to logs and Google’s crawler submits certs that it finds). Censys does its own web crawls to gather their cert data. They record every cert, whether or not it is trusted or even used in the chain.

crt.sh allows you to search in censys by clicking on a link on a cert details page. The authors are considering adding the data they find to CT. Rick explained that he had used censys.io to find sites that still returned a Symantec cross-certificate.

Peter indicated a desire to hear from anyone who wants to report bugs or enhancements in certlint (at https://github.com/awslabs/certlint/issues).

Michael Klieman announced that Symantec’s CT log servers are now open to all CAs. Send email to DL-ENG-Symantec-CT-Log@symantec.com to apply.

Proposal to change definition for Sub CAs

Note Taker:

What should be represented in the “O” Field? Definition of Applicant {#What_should_be_represented_in_the_.22O.22_Field.3F_Definition_of_Applicant}

Note Taker: Ben

What Should go in the “O” Field:

Dean gave an example. Who can request the certificate for “dean.example.com”? There are various entities who could arguably request the certificate–the registrant, the logical operator of the domain, the hosting company, the CDN, the marketing company, etc. So, what should go in the “O” field?

Geoff – there is “should” and “could”. It is pretty clear that the owner of the domain, the person who is responsible for it, and creating the content should be the one requesting the certificate and the subject of the certificate. The owner is the one, even if they’re not actually creating the content.

Peter – the domain owner might not be the party creating the content. They might CNAME it off to someone else.

Dean – another example is the CA Security Council. The CA Security Council has a marketing company that creates the content. So who should request the certificate?

Geoff – the certificate is an expression of who is responsible for what users see on the web site. So, in terms of who should, who says they want to be responsible?

Gerv – we need to distinguish between who can request the certificate from who can go in the “O” field. For example, if I go into the control panel of my web hosting service and I click on “get me a Let’s Encrypt certificate”, it’s really my web hosting company that is doing all of the work to obtain the certificate, but they are doing it for me because I have asked for it. Not only can they request the certificate, but they should be doing it.

Ryan had listed the methods for requesting certificates in an email, taking the existing Baseline Requirements, and looking at the different technical capabilities of parties who could request a certificate-file-based method, validation on WHOIS, DNS-based method, etc. Peter had then responded via email that BR section 7.1.4.2.2 requires that the Org name and other Subject attributes contain information verified as per section 3.2.2.1 (“if Subject identity information is to include name, address, etc. … that the Applicant’s address of existence or operation”).

Peter – there are actually three parts here in the Baseline Requirements– (1) the Subject Alternative Names, the Fully Qualified Domain Names, (2) the Subject Identity information, such as the Organization name field, and then there is (3) the Applicant or Subscriber. Section 9.6.3 lays out what it means to be the Subscriber, and there is other language in the Baseline Requirements that says the Subject has to be the Subscriber. The Subscriber has to do things like maintain sole control of the Private Key, which makes the scenario of “click this button” problematic.

Geoff – The Subscriber can maintain control of the Private Key, even if someone else has it, as long as you have suitable relationships with them to ensure that they don’t misuse it. It happens often. There are lots of ways that you can have Private Keys in HSMs in clouds or whatever. What it means is to control it with the right kinds of legal relationships.

Peter – can the person claim “sole” control of the Private Key if they didn’t generate it?

Robin – you can assert control, even if you authorize someone else to operate it.

Kirk asked previously over email what the problem is that we’re trying to resolve. Peter responded that CAs need to have a clear understanding of the obligations they are expected to meet. Doug responded by saying that we weren’t asking the right question. It’s not who can request it, but the relationship between the Org field and the CN / SAN in the certificate. Gerv said the question is how the “O” field relates to the party that owns or is operating the web site. Dimitris had written to Dean noting that the O could either be the owner of the web site content or the owner of the domain. Dimitris suggested that since it is not easy to reach consensus and the CA/B forum members feel that users should be aware of who is responsible for the content just as equally as of who is responsible for the private key or the domain (etc), the EV Guidelines could be amended to allow additional fields in certificates that allow for the representation of additional certificate information about the identity of technical operators, etc. Finally, Ryan had suggested that due to lack of consensus on what the “O” field and the desire not to let the validation methods get hung up on this, we review the BRs in their entirety for spots where the language is inconsistent and update language to coincide with a current understanding with work toward consensus on these goals.

Geoff- not only are we asking the wrong question, there isn’t a question to be asked. The way it works-you start with an Applicant who has the desire for a certificate. Then the O field is the name of the Applicant. And the CA has to verify that it is really their name. They may or may not have ownership or control of one or more domains, but if they do, then you can issue them a certificate for one of those domains. At no point is it the case that you go the other way-you don’t say, “Hey, , I have a domain, I wonder who the Applicant should be?”

Gerv – If you were going to take that view, then anyone who “could” get a certificate would have an equal right to be listed in the O field as the Subscriber.

Geoff – But, if the person gets the certificate with their name in the certificate, it should mean something to users who come to the website. If that’s what they want it to mean, but if that’s not what they meant it to mean, they shouldn’t have got the certificate.

Peter – ran a scan of CT to see how many certificates had an organization name with two or more base domains. Then he sorted it by the number of certificates and SANs with common base domains. His results showed that CloudFlare and other CDNs and web hosting companies had the most of these types of certificates.

Dean – when we kicked this off, we asked, how would a relying party use this information to find the content owner based on the certificate. Obviously, when there are so many of these in a CloudFlare certificate, it’s hard for them to tell who it is.

Doug – at least you have more information of who it is than if it were a DV certificate-at least you have CloudFlare. Cloudflare is the owner and protector of the keys. If there is an issue, if I need to revoke, if I need a SAN removed, I can go to them.

Dean – but if I want to return the shirt I bought, that’s difficult.

Gerv – the other question is “what do people use the O field for?” Well, sometimes the party in the O field isn’t the information a user would want to have. We end up looking at use cases for O field information to try and determine the right person to list in the O field, and then we try to write some rules to ensure that, as much as we can, the right person gets the certificate. It’s a difficult problem.

Geoff – Yes it is. If the problem is who do I call if the shirt I ordered is the wrong size? That is difficult with a certificate with multiple SANs.

Kirk – It is not that different than giving your car keys to someone and allowing them to drive your car for the night. If anything happens, they come back to the car’s owner, who must respond to questions about who was in control of the car. It is simply ownership or control, and the owner of the domain can designate who has the right to get certificates.

Ryan – The methods provide ways for site operators to limit and control that, because at least for web sites there are so many people who can influence content on the page. Our tools are currently limited, and the way things work today, we cannot control it that way.

Ben – The model that Geoff set is a good one for the way things are. If we focus on the Applicant and the process that an Applicant goes through, then that is the best way to approach this. The first step is do they want a certificate, and the second step is do they have ownership or control.

Peter – or authorization, because we have that domain authorization document.

Ben – yes, authorization, right.

Robin – the O field is the Applicant because they become the Subscriber.

Ben – they have the key-an Applicant with a Key

Geoff – or a hold over the key.

Kirk – and various agents of the Applicant. So Peter, if you are seeing a specific case or instance where this looseness is leading to a distinctly bad result, then you should bring this up.

Peter – I agree with the “start with the Applicant” position, my concern was that we have requirements in the BRs that we need to meet, and there is this issue of key control here, that we need to resolve. We’ll have to go back to the Validation Working Group and look at our exact wording, given that there appears to be consensus that the Applicant does not have to be the domain registrant. Is that correct?

Geoff – no, we’re sticking with ownership, or control, or authorization.

Bylaws Review / Organization Business {#Bylaws_Review_.2BAC8_Organization_Business}

Note Taker: Neil

Dean asked Kirk if there were any bylaw changes to be brought up. Kirk replied that he had nothing specific.

Dean: Per bylaws, Chair and Vice Chair roles are coming up for renewal as the end of the 2 year service period approaches. The Vice-Chair will automatically be nominated for the role of Chair, but nominations for both roles is open to the membership. The current Chair cannot become chair for another 2 years. Previous chairs are eligible for nomination, e.g. Ben (Wilson).

In the event of only a single nominee a confirmation ballot will be held. If multiple nominees are put forward, a membership run-off ballot is then required to elect to the roles. This would be a closed ballot, going to Don (Sheehy), representing WebTrust, and Arno (Fiedler), representing ETSI, to adjudicate the result.

Discuss F2F Meeting 38 in Bilbao Spain

The next meeting will be in Bilbao, Spain. Attendees are responsible for booking their own hotels. More information is available at https://frozen.cabforum.org/Meeting%2038

Review accomplishments / list of tasks {#Review_accomplishments_.2BAC8_list_of_tasks}

Note Taker: