Final Minutes for CA/Browser Forum Teleconference – 17 May 2018 Attendees: Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson (DigiCert), Bruce Morton (Entrust), Cecilia Kam, (GlobalSign), Christopher Kemmerer (SSL.com), Daymion Reynolds (GoDaddy), Dean Coclin (DigiCert), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Fotis Loukos (SSL.com), India Donald (GSA), Iñigo Barreira (360), Jeff Ward (WebTrust), Jos Purvis (Cisco), Ken Myers (Federal PKI), Kirk Hall (Entrust), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom), Michele Coon (OATI), Mike Reilly (Microsoft), Nick Pope (ETSI), Patrick Tronnier (OATI), Peter Miscovic (Disig), Rich Smith (ComodoCA), Rick Andrews (DigiCert), Robin Alden (ComodoCA), Ryan Sleevi (Google), Tim Hollebeek (DigiCert), Tim Shirley (Trustwave), Tyler Myers (GoDaddy), Virginia Fournier (Apple), Wayne Thayer (Mozilla), Wendy Brown (Federal PKI).
1. Roll Call 2. Read Antitrust Statement 3. Review Agenda. Agenda was approved. 4. Approval of Minutes of CABF Teleconference of May 3, 2018. The Minutes are not complete, and will be reviewed at the next meeting. 5. Updated CA membership application of Certigna (DHIMYOTIS). Kirk noted that Certigna’s application had been considered on the last call, but there were questions about the form of ETSI audit submitted, and some additional information was acquired. Kirk reviewed the additional information received, and said it appeared to be in order. Certigna (DHIMYOTIS) was approved as a CA member by consensus. 6. Browser membership application of Brave. Brave’s application as a browser member was reviewed and approved by consensus. The Forum may consider clarifications to the Bylaws on membership criteria for the future. Ben said that may by handled for each of the new working groups under the new Forum governance structure, as each group defines its own membership criteria. 7. TuV Austria’s application to join as Associate Member. It was agreed by consensus that TuV Austria could participate in the Forum, but the Forum needs to discuss in what capacity. The Forum’s past practice on admitting individual audit firms as Associate Members in their own name or as representatives of the audit scheme they follow (e.g., ETSI / ACABc) has not been consistent. This matter will be discussed further on the next call. 8. Future VISA membership application as returning CA member (Information only). Kirk informed the members that VISA is interested in renewing its membership in the Forum as a CA, and will resubmit all required information in a new CA application in the future. 9. Response to GDPR requirements. Kirk noted that the GDPR regulation would take effect on May 25, and would affect CA operations. He asked if other CAs had an opinion on whether a CA would be viewed as a “controller” or “processor” under the regulation. Iñigo said that in Spain they could be both, taking into account that a CA processes the data provided by the applicant or subscriber but also generates and controls data provided by the CA. In the end a CA must keep all the data under its control, so maybe controller is the right approach. Robin said “controller” seemed the right designation – not least because a CA can send its relevant policies to certificate customers and resellers, but pragmatically a CA cannot review and agree with tens of thousands of inbound policies from customers and resellers. Dimitris thought a CA is probably a "controller" as well, as it determines the purposes and means of the processing of personal data, even though it follows guidelines and requirements mostly set by others (for example eIDAS, CA/Browser Forum, ETSI, WebTrust). A "processor" refers to an entity that handles/processes personal data on behalf of a Controller, which probably doesn't apply to CAs. Jeff Ward pointed out that there are provisions in the GDPR that may override some of the Forum’s Baseline Requirements provisions (e.g., rules on data retention). Such potential conflicts have been coming up with other clients of his firm. Ryan said that BR 9.16.3 may also apply, which allows a CA to deviate from a BR requirement if required by other law such as GDPR, but only if the CA publicly notifies the Forum of the deviation – it’s up to CAs to determine how to proceed. As a separate matter, Jeff noted that WebTrust is now finishing its Guidelines for WebTrust Practitioners. 10. ETSI questions to Forum: Nick said ETSI has been working to align its work to a more global approach, and would like input on two issues. First, third party payment services in Europe must be identified using a “qualified certificate” that includes a special authorization number, which is different from its company registration or serial number already specified in the EVGL. For these certificates, the issuers are using the X.520 organizationIdentifier for this additional number, and ETSI would like clarification from the Forum that this is allowed under EVGL Section 9.2, which could be interpreted as restricting what can be included in that field (see EVGL 9.2.8). ETSI wanted to inform the Forum of this, and see if the Forum could confirm that ETSI’s interpretation of EVGL 9.2 allowing this is correct. Ryan thanked Nick for the clear presentation of the problem statement. The difficulty is this interpretation is necessarily going to have a local interpretation under the ETSI context that may disagree with other interpretations and use cases – the field could have different meanings and validations under different contexts, potentially resulting in confusion – that’s the risk from ETSI’s interpretation. Nick acknowledged this possibility, but said the number only has meaning in the context of the EU rule and is likely to have no meaning or interpretation to anyone else. Ryan noted that other EV cert fields, like the O or Organization field, have a common understanding by all, and there is common expectation of what is allowed there or not in the specifications – and the other organization fields in the cert all relate to each other. He is of two minds – because the BRs don’t specify the field, perhaps a special use would work, but on the other hand the EV Guidelines also specify various data field OIDs which interpret what the data in a field is for. If the EU introduced a new OID as the subject attribute for this field, then the contents of that field would always be unambiguous – that could be an alternative but it might conflict with other X500 naming schemes. Ryan suggested the introduction of a new subject attribute which would avoid the ambiguity of reusing an existing attribute. Tim agreed and pointed to EVGL 9.2.8 – Other Subject Attributes which suggests it’s legal if the EU wants to create its own OID and start using it, after which the EV Guidelines could be updated to state what that OID means. Nick said they were sort of stuck with this approach of putting the number in the way they do it now because of certain EU legal documents which say the number has to be part of the naming and not just an attribute. ETSI would like to make certain that doing it as they are doing now is not interfering with EV systems. It seems there are two ways of addressing this: (1) is it necessary that everyone can interpret what the number means, or (2) is it sufficient if people in the ETSI scheme understand it – it’s part of the name, and is part of a unique identifier – even if no one else understands it. Dimitris said that he reads BR 9.2.8 to say that using existing OIDs like organizationIdentifier doesn’t necessarily conflict with anything, so if the number is in an EV certificate and people don’t understand how to process it, they could just ignore it. There doesn’t appear to be a conflict with any existing requirements. Ryan said it’s not a matter of customers or clients being able to just ignore it, it’s a matter that no other party can use that field because if they see the field in an ETSI certificate it will mean one thing, and if they are using that field in a different context, it will mean a different thing. The field could have a different meaning depending on who the CA was that issued it – he asked Nick if ETSI said the CA had to use that specific OID. Nick said yes because of the way the regulations are worded – ETSI itself can’t change that. The question is whether the use of the OID in that way makes it an acceptable EV certificate. It seems to ETSI that the interpretation of that field is open, just as the interpretation of the organization serial number and place of incorporation may means different things in different jurisdictions and registration scheme, with no absolute way of interpreting that registration number. Putting a number in the organizationIdentifier field just means this is an organization that has been registered somewhere, but does not itself mean there is a problem or conflict. Ryan thought there was still the possibility of confusion and conflict, and was hoping to find a way of resolving the potential conflict. The organization serial number will be understood in the context of the data on the place of incorporation, consistently and reliably validated and unambiguous. The risk from putting an ETSI number in the organizationIdentifier field is that it does not have that same standard – that could mean essentially that no one else can use the field – or is this an instance where BR 9.16.3 applies and allows this as a local requirement of law. It’s possible that if someone else wants to use the same field in the future for a different purpose, the Forum could update the EVGL to enumerate what the permitted cases are and how to distinguish those cases. Ryan thought there was a way forward here, but it was not fair to say there’s not an issue with use of the data field as ETSI is doing. Wayne thought that what Ryan proposed was the most obvious way forward. Wayne reads EVGL 9.2.8 as not allowing use of this field because it’s subject organization information, but an update to the EV Guidelines could change that and could reserve the field for this specific case and could specify a little bit about how it gets validated and what information it would have to contain – that’s the minimum of what needs to be done. Tim agreed and said he would put that issue at the top of the list for the next Validation Working Group discussion. Kirk suggested that Nick and Arno work with Tim on a proposal. Arno noted that there is now a Supplement to ETSI EN 319 403: Draft TS 119 403-2 which will result in better audit reports. This will be an appendix to the European norm specifying what ETSI audit reports should look like. They checked with the browsers and got some very good feedback from Mozilla (including having a management assertion in the audit report) – other feedback from other browsers would be welcome. There will be further discussion at the London meeting. Nick noted that this Supplement also moves ETSI audits to annual rather than the current bi-annual which is normal in Europe, and will clarify “period of time” from “point in time” audits, as well as form of auditor attestation. ETSI would welcome further comments from the Forum. 11. New CABF Working Group on maintaining the website. Jos, Dimitris, and Ben suggested the Forum’s website needs updating, as does the wiki, and he recommended we create a new Working Group for maintaining the website, maybe called the “Working Group for Infrastructure”. Kirk asked if that should really be its own Working Group, or instead a Working Group or subcommittee directly under the Forum. Others liked the proposal of a new Working Group to serve all the Working Group infrastructure needs. Jos said he will draft a charter for review by the members. 12. Validation Working Group update. Tim said the VWG had discussed Bruce’s and Doug’s suggested new validation method, the IP ballot, RDAP, the London meeting agenda, and potential EV improvements – members can consult the WG meeting notes for more details. Kirk noted that he had received input from working groups on how much time they each needed for the Tuesday meeting in London, and will draft the day’s agenda accordingly. 13. Network Security Working Group update. Ben said the WG reviewed the comments from WebTrust on the NetSec requirements as to certain definitions and system classifications, including a chart showing how they would be divided among systems. The WG is refining some of the definitions and the way they are organized. The work will be continued at the London meeting. 14. Governance Change Working Group – Tim said the WG was working on getting people to submit their IPR Agreement v1.3 updates in by July 3. Kirk said quite a few had been submitted, and he would update the list shortly. 15. Policy Review Working Group update – no update. 16. Ballot Status - Discussion of ballots. Kirk reviewed the voting status of some recent ballots. There was no other discussion. 17. Agenda, logistics for London F2F – June 5-7, 2018. Robin provided additional meeting details, which will be posted to the wiki. He said we were already at the maximum capacity for the room. 18. Any Other Business. There was no other business. 19. Next call: May 31, 2018 20. Adjourn
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
