Thank you for making this announcement Pedro. This change of legal ownership is covered by section 8.1 of the Mozilla Root Store Policy, including the following statement:
If the receiving or acquiring company is new to the Mozilla root program, it must demonstrate compliance with the entirety of this policy and there MUST be a public discussion regarding their admittance to the root program, which Mozilla must resolve with a positive conclusion in order for the affected certificate(s) to remain in the root program. I would like to begin the discussion period for this change in legal ownership of the WISeKey root certificates by requesting thoughtful and constructive feedback on this request. I will plan to keep the discussion period open for a minimum of 3 weeks. Questions for OISTE/WISeKey: Your plans for new audits will largely cover the requirement that OISTE demonstrate compliance with the entirety of our policy. I believe that you are asking for "approval" from Mozilla in the form of a "positive conclusion" to the public discussion prior to conducting those audits - is that correct? If so, I think that is a reasonable request. If the audits uncover problems, they can be addressed via our normal processes. Section 8.1 also states: "Mozilla MUST be notified of any resulting changes in the CA's CP or CPS." Are you able to tell us what those changes will be? I am understanding that OISTE would like to have Mozilla's "approval" prior to the change taking place, and thus the new CP/CPS taking effect, but I think it is reasonable for us to know the specifics of what changes are planned prior to ending this discussion period. - Wayne On Thu, Nov 29, 2018 at 5:30 AM Pedro Fuentes via dev-security-policy < [email protected]> wrote: > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
