I am satisfied with the response to my questions. If no additional comments are received by Tuesday, 8-January 2019, I will consider this request to have been "resolved with a positive conclusion" as required by Mozilla policy section 8.1.
- Wayne On Fri, Nov 30, 2018 at 2:46 AM Pedro Fuentes via dev-security-policy < [email protected]> wrote: > Hi Wayne, > thanks for your prompt reaction. I insert my comments below. > > El jueves, 29 de noviembre de 2018, 19:01:16 (UTC+1), Wayne Thayer > escribió: > > 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. > > Yes, this is correct. We need to ensure full compliance with the Mozilla > Program and therefore we'd process to execute the transfer plan only after > having this approval. > > > > > 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. > > > > Indeed there will be changes in the CP/CPS. I tried to explain this in the > above request, but I'll provide here more details. > > The current CPS is published by WISeKey and integrates the CP for the > different certificate profiles issued. This CPS is already endorsed by the > OISTE Policy Approval Authority (PAA), as explained in the first sections > of the current CPS, because OISTE had always a role in our PKI (e.g. you > can see in the Root Certificates the OU "OISTE Foundation Endorsed"). > > We already wanted time ago to separate the CPS into different CP and CPS > documents, and we'll profit this transfer process to do a full refactor of > the policies and practices documents. > > The final picture we envision is: > * OISTE will publish a set of CP documents that regulate the different > certificate types issued by the trust model. A priori I foresee a CP for > personal certificates, another CP for SSL certificates and another CP for > device certificates (IoT). OISTE will play a supervisory role to grant > permission to a subordinate CA to adopt one or more CP and issue such types > of certificates. > * OISTE will publish a CPS that covers the Root CAs and provides an > "umbrella" for the whole trust model. > * WISeKey will publish at least one CPS that regulates the operation of > the Issuing CAs, in accordance to the OISTE CPS and the CP implemented by > these issuing CAs > > Therefore a certificate subscriber will be still affected by the WISeKey > CPS, as it is now, and our main intent will be that, in terms of > "Certification practices", for the subscriber there won't be any practical > change. It's just that, when evaluating our new practices, the readers will > need to consider not only a single CPS document, but also the CP documents > separately. > > I think this change will be positive, because a CPS covering different > types of certificate policies can end up by being complex to read, as it > needs to contain all possibilities for identity validation, certificate > profiles, etc. for certificate profiles that can be quite different, in a > single CPS document. I think the new documentation framework will be > clearer and more in line of the new best practices and requirements. > > BTW, it happens that I'm member of the OISTE PAA, so I'll be personally > involved in all the changes. > > I hope this clarifies the question, but don't hesitate to ask for more > information. > > Regards, > Pedro > _______________________________________________ > 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
