This is a message addressed to the CA/Browser community related to the request to transfer the ownership of the Roots currently held by WISeKey, to the OISTE Foundation.
My name is Pedro Fuentes, Chief Security Officer at WISeKey. I’m sending you this message as primary contact for WISeKey, as an organization registered member at the Mozilla Root Certificate program. WISeKey SA is a proud member of the CA community since more than 10 years, and we consider it’s the right moment to make some changes in our Trust Model to accommodate the new strategy of the company. As declared in our CPS, there’s a tight historical relationship of WISeKey as CA with the “OISTE Foundation” segregating the Trust Model with commercial CA activities (which I’ll introduce in the next paragraphs), and we want to continue leveraging this relationship in a way that we can empower our Trust Model, as per that new strategy I’ll also explain later. OISTE stands for “Organisation Internationale pour la Sécurité des Transactions Electroniques (International Organization for the Security of Electronic Transactions). The OISTE Foundation, created in Geneva in 1998, is a not-for-profit organization regulated by article 80 et seq. of the Swiss Civil Code. OISTE is recognized by the United Nations as a non-profit organization with an ECOSOC status, which allows the Foundation to participate in international programs promoting the democratization of access to new technologies, especially in what respects to giving access to the digital identity as a fundamental right. In respect to the relationship with the WISeKey PKI, OISTE acts as “umbrella” for our Trust Model, paying a role supervising and approving certificate policies and practices, by means of a “Policy Approval Authority” which, for example, monitors WISeKey adherence to its CPS. In other words, acts as “independent regulator” of the Trust Model and WISeKey is the “operator” of this Trust Model, running a number of Root Certification Authorities that are recognized in your Program. Last year the company embarked in a growth strategy that started by creating “WISeKey International Holding Ltd” (WIHN), an entity that is listed in the Swiss stock exchange and that owns a 100% of WISeKey SA, who remains as a member of the Holding. Recently WIHN also acquired the “QuoVadis Holding”, a group of companies that is also recognized in different Root Programs. Until now, the public role of the OISTE Foundation wasn’t really promoted in front of the CA Community, as WISeKey was assuming all the responsibilities, but due the recent focus on Trust Models, Internet Governance and Net Neutrality we’d like to change this situation and to give a bigger visibility to the Foundation, and for this we’re sending you this communication, in order to address this change in the best way, while ensuring full compliance with your Root Program. In short, the change that we’d like to do is the following: * OISTE to be declared as the owner of the Root Certification authorities that are currently registered by WISeKey * WISeKey would remain formally as the owner and operator of the subordinate CAs This change would imply to perform a series of coordinated actions that we detail a draft plan included in the message as appendix. It’s important to highlight the fact that no material change would happen with the proposed new scenario: The physical infrastructures would remain the same and the same team would keep the operations for the full hierarchy (as all the operations, including Root hosting & operation, would be delegated to WISeKey). For this we assume the need to have an independent assessment during the process and we already engaged our WebTrust auditors. WIHN plans are to incorporate in the Holding other companies that could own and operate also Certification Authorities (for example, a WISeKey company operating in a certain jurisdiction, and providing certification services in that country). If these subordinate CAs wouldn’t be “Technically Constrained”, it’s assumed the need for these companies to be independently audited and appropriately incorporated in the Root Program. In all this cases, OISTE would act as an independent guarantor of compliance with the Trust Model. In respect to QuoVadis, we aren’t requesting to involve QuoVadis in any change, as this WISeKey affiliate would continue to operate as an independent CA. If at a given moment there's a change affecting the relationship of QuoVadis and WISeKey, it would be initiated the appropriate process according to the Program policies. It’s important to highlight also that is not the plan to create a “Super CA” that would have as role to sign CAs of other companies. The role of OISTE would remain closely linked to the activities of WIHN, and the main benefit that we want to obtain is to provide a layer of independence and protection to the Certificate Subscribers, by protecting them against aggressive take-overs of the Holding or parts of it. In terms of Certification Policies and Practices, our vision is that OISTE would define the CP for all the certificate profiles allowed in the Trust Model and, separately, a CPS for the Roots, while the operators (WISeKey SA initially) would define its own CPS that would adhere to some of the CP set by OISTE. In terms of WebTrust compliance, once we have acceptance to initiate the change and before OISTE starts taking its desired role in the Root Programs, we foresee the need to audit from one side the activities of OISTE as Root and from another side to audit separately WISeKey (or other subordinate companies running unconstrained CAs). I hope this mail provided enough background on the change that we’d like to address. For us is critical to have the “green light” and support of the community in order to get this done. Thanks for your patience reading this long message and best regards, Pedro Fuentes —————————————— APPENDIX: DETAILED TRANSFER PLAN (DRAFT) Please note that we have as constraint the procedure to follow for the Mozilla Root Program, which implies a public discussion of our intention and plan. Therefore, only after the outcome of that discussion we'd do a final planing for the fulfillment of the plan. For your information, the plan below has been initially discussed with the representatives of the Mozilla Root Program.We’d greatly appreciate any comment you have on this plan, in terms of possible modifications to be introduced to be compliant with your program, so we can include those considerations before starting the public discussion. #1. Chronogram of actions We can’t provide a detailed calendar with dates, as we’d be still pending on having an OK from different Root Program Managers and the CA Community to start the process, but we’d like to express the expected sequence of tasks and approximate schedule, expressed in weeks (W) after the start date (so W-5 means the 5th week after the start date). * Start of Project. The transfer process starts once we have an OK to go ahead from the Root embedders and CA/Browser community. * W3. Release for public review the new CP & CPS documents, according to the following approach: - OISTE will define all CP documents in the Trust Model - OISTE will publish a CPS as Root CA - WISeKey will adhere to the OISTE CP and will publish a separate CPS to disclose how the different CP are implemented * W5. Adjust operational and policy documents to reflect the splitting between Root and Intermediate/Issuing CAs. It must b understood that WISeKey assumes the role of operator and there’s no material change in infrastructures or team involved in the CA management. * W9. Execute a Point-in-Time Audit to ensure that the transfer keeps compliance with the WebTrust audit criteria. * W24. Execute a 3-Month Period Audit to re-validate the WebTrust compliance * End of project. Annual audit cycles start, synchronizing audit periods for both OISTE and WISeKey. #2. Audit strategy Apart of the PiT and Period audits required during the transfer process and stated above, the audit strategy for the trust model is as follows. * We’d continue pursuing compliance with: - Webtrust for CA - Webtrust Baseline Requirements and Network Security - Webtrust for EV * We foresee the need to audit from one side the activities of OISTE as Root and from another side to audit separately WISeKey (or other subordinate companies running unconstrained CAs). Given the fact that all the operations would be assumed by WISeKey, we’d unify the auditor firm and synchronize audit periods, but issuing separate audit reports. The audit schedule will ensure that no gaps are produced. #3. Aspects related to existing certificates In terms of the CA certificates, the current Root CA Certificates include as “O” field the value “WISeKey” and in one of the “OU” fields the value "OISTE Foundation Endorsed”. We understand that it would be cleaner to have “OISTE” in the Organization field, but this would imply a re-issuance of these certificates that, even keeping the same key pair would have too much impact in customers, therefore our plan is to leave the existing Root CA certificates as they are. In terms of end-user certificates, as stated above, we want to separate the CP documents and those to be dictated by OISTE. We’d define in these CP documents the adequate certificate profiles for personal, applications and IoT certificates, which will be initially the same, or compatible, with the ones currently specified in the WISeKey CPS. In terms of OID management, and in particular for the EV OID already considered in Root Programs, in our understanding OISTE will have the responsibility to manage the OIDs, so it would take ownership of the current EV OID (together will all the rest we currently use) and assign the required OID to WISeKey as CA operator. 4. Technical details of the process We don’t expect any relevant change derived of this transfer, as all operations would keep using the existing physical infrastructures and team. —————————————— _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
