Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
I believe that all of the concerns related to this request for inclusion of the OISTE WISeKey Global Root GC CA have been addressed. I am now closing this discussion with a recommendation to approve this request. Any further comments should be added directly to the bug [1]. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1403591 On Tue, Aug 14, 2018 at 3:49 PM Ryan Sleevi wrote: > Sorry for the delay in responding. I think this resolves the ambiguity as > to the gaps and is a good path forward. > > On Wed, Aug 1, 2018 at 7:37 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Having received the audit reports covering the period from the creation of >> this root, I would like to resume this discussion. Please post any >> remaining comments that you have on this inclusion request by next Friday, >> 10-August. >> >> - Wayne >> >> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Having received the audit reports covering the period from the creation of this root, I would like to resume this discussion. Please post any remaining comments that you have on this inclusion request by next Friday, 10-August. - Wayne On Tue, Jul 31, 2018 at 2:47 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > please note that if you didn't check this already, the above links only > work now from the WISeKey website. You can access to the seals from the > footer at any page at wisekey.com or you can use these direct links: > Webtrust for CA: > https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions.pdf > Webtrust for BR/NS: > https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-SSL.pdf > Thanks, > Pedro > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hello, please note that if you didn't check this already, the above links only work now from the WISeKey website. You can access to the seals from the footer at any page at wisekey.com or you can use these direct links: Webtrust for CA: https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions.pdf Webtrust for BR/NS: https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-SSL.pdf Thanks, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hello, we successfully completed the new audits. As requested, we modified the audit period to ensure that there aren't gaps since the creation date of the new Root. The Webtrust seals are available here: Webtrust for CA: https://www.cpacanada.ca/webtrustseal?sealid=10026 Webtrust SSL BR: https://www.cpacanada.ca/webtrustseal?sealid=10027 Thanks and regards, Pedro El martes, 26 de junio de 2018, 23:11:08 (UTC+2), Wayne Thayer escribió: > On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió: > > > > Hopefully the audit report will be just as boringly positive as usual... :) > > > > I'll come back then in a few weeks, once the audit process is over and we > > get the result. > > > > Thank you Pedro. My understanding, then, is that we will be placing this > inclusion request on hold until we receive the audit report covering the > period beginning on 9-May 2017. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
El martes, 26 de junio de 2018, 23:11:08 (UTC+2), Wayne Thayer escribió: > On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió: > > > > Hopefully the audit report will be just as boringly positive as usual... :) > > > > I'll come back then in a few weeks, once the audit process is over and we > > get the result. > > > > Thank you Pedro. My understanding, then, is that we will be placing this > inclusion request on hold until we receive the audit report covering the > period beginning on 9-May 2017. Well, I'm afraid this is the only solution given the current situation, but being a solution, we are more than happy with it. I must say that this is not what we expected when the inclusion request was accepted in Bugzilla, because the audit requirements should be just met or not met, and I still have the feeling that the inclusion request was filed in accordance to the Mozilla Policy and the BR, on the dates the request was sent and processed, else we shouldn't have arrived to the public discussion phase. As per my understanding and according to our auditors, it also happened to us that the new illustrative reports weren't yet enforced on the dates we did the audits for GC, as per the publication dates of these illustrative reports, and it also happened that there were ulterior discussions in the forum about the need to consider unbroken audit periods in the Mozilla Policy, but because these discussions were ulterior, we couldn't be aware when the inclusion request was sent. Nevertheless, for us its always a chance to learn new things and the feedback received is always considered positive to improve our practices. And I also hope our case helps other CAs to understand better this new criteria. In summary, we're happy to do as requested and get the new Root hopefully accepted soon. Thanks for your support and time dedicated to our case. I'll come back when the new audit reports are ready. Best regards, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió: > > Hopefully the audit report will be just as boringly positive as usual... :) > > I'll come back then in a few weeks, once the audit process is over and we > get the result. > > Thank you Pedro. My understanding, then, is that we will be placing this inclusion request on hold until we receive the audit report covering the period beginning on 9-May 2017. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió: > > To be fair, you can align those periods by having one report prepared for 9 > May 2017 to your current audit period, and then include GC in with your > normal audit - without having to alter your period. It allows you to > maintain your current audit cycle entirely. > I'll check with the auditors, but I don't think it will make a difference, as in this case we'd have to engage (and pay) for an additional audit report, so losing one month of the annual audit by advancing the start date isn't that bad. > > > Is it too adventurous of me to say that we have a deal? > > > > With a heads up that we'll be looking very closely compared to illustrative > reports to understand if any deviations are meaningful and significant, I > think that sounds like a way of addressing the uncertainty gap present :) Hopefully the audit report will be just as boringly positive as usual... :) I'll come back then in a few weeks, once the audit process is over and we get the result. Best, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
On Tue, Jun 26, 2018 at 4:29 PM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > My comments below. > > El martes, 26 de junio de 2018, 21:12:44 (UTC+2), Ryan Sleevi escribió: > > > > I just want to make sure - the plan is to provide a Period of Time report > > from when the key was created to 1 year after (i.e. 9 May 2017 to 8 May > > 2018)? > > If so, that definitely closes the gap. > > Yes, we are formulating s solution to close the gap. The proposal that we > made to solve the issue is to change the start date of our annual audit > period, so it coincides with the creation of the new Root GC and covers 12 > months after this date, but being in scope the whole certification practice > and the three roots (GA, GB and GC). > > This implies an overlap with the periods already audited, but closes any > perceived gap. > > > Alternatively, a report on the 9 May 2017 to 15 September 2017 period > would also close it. > > This is not appropriate as it would imply having to run two audits, one > for GA+GB and another for GC. The above solution allows us to have a easier > follow-up next year. > To be fair, you can align those periods by having one report prepared for 9 May 2017 to your current audit period, and then include GC in with your normal audit - without having to alter your period. It allows you to maintain your current audit cycle entirely. > Is it too adventurous of me to say that we have a deal? > With a heads up that we'll be looking very closely compared to illustrative reports to understand if any deviations are meaningful and significant, I think that sounds like a way of addressing the uncertainty gap present :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hi Ryan, My comments below. El martes, 26 de junio de 2018, 21:12:44 (UTC+2), Ryan Sleevi escribió: > > I just want to make sure - the plan is to provide a Period of Time report > from when the key was created to 1 year after (i.e. 9 May 2017 to 8 May > 2018)? > If so, that definitely closes the gap. Yes, we are formulating s solution to close the gap. The proposal that we made to solve the issue is to change the start date of our annual audit period, so it coincides with the creation of the new Root GC and covers 12 months after this date, but being in scope the whole certification practice and the three roots (GA, GB and GC). This implies an overlap with the periods already audited, but closes any perceived gap. > Alternatively, a report on the 9 May 2017 to 15 September 2017 period would > also close it. This is not appropriate as it would imply having to run two audits, one for GA+GB and another for GC. The above solution allows us to have a easier follow-up next year. Is it too adventurous of me to say that we have a deal? Thanks, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 3.- The key ceremony of this Root was witnessed by the same auditors. I > would say that the mere fact that an auditor issues a point in time WT BR > report implies undoubtedly full compliance with this requirement, as with > any other one set by BR. Therefore, the fact that the PiT exists, means > that the key ceremony was executed according to the rule. > The issue is not that the key ceremony wasn't executed - although it's worth calling out, the key ceremony does not test every BR issue - but about the gap between when the key ceremony was conducted to present. > 4.- Please check in this link (https://filevault.wisekey.com/d/412f61ab26/) > the redline intermediate versions. It must be noted that not all versions > are formally adopted and go public (i.e. version 2.7 was a working > version). These are mostly changes to include the GC hierarchy, properly > reflect latest BR (i.e. validity periods, reflect the contact point for > incident reporting, etc) and also to correct minor glitches. > Thanks! > 6.- As a result of these discussions and open concerns, and based in the > auditor recommendation to advance in this inclusion process, we already > proposed here to change the audit period so it starts the 9th of May 2017 > instead of the planned annual renew. Fortunately it was only one month > difference, but I must say that I'd have preferred to take this decision > based in a formal compliance issue that I could understand, because if it > had been several months overlap it would have had a much bigger > I just want to make sure - the plan is to provide a Period of Time report from when the key was created to 1 year after (i.e. 9 May 2017 to 8 May 2018)? If so, that definitely closes the gap. Alternatively, a report on the 9 May 2017 to 15 September 2017 period would also close it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
I hope you realize that these discussions were happening well after we started the inclusion request in Bugzilla, and I can't even see how what we did wasn't compliant with BR 8.1, even with the current wording. Nevertheless, can we at least agree that our plan to advance the start of the annual audit period to 9th of May will satisfy both the previous and the current criteria? Thanks, Pedro El martes, 26 de junio de 2018, 0:00:29 (UTC+2), Wayne Thayer escribió: > On Mon, Jun 25, 2018 at 2:45 PM Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > 7. In my humble opinion, I think that these requirements must be formalized > > > in audit criteria or explicitly in the BR, and not raised "ad hoc". Any > > CA > > > embarking in an inclusion process should know all requirements > > beforehand. > > > > > > But they're already arguably part of the BRs, as I showed, and it's up to > > the relevant groups (WebTrust, ETSI) to ensure that the criteria they adopt > > reflect what browsers expect. As we see with ETSI and ACAB-c, if the > > auditor fails to meet those requirements, it's the auditor that's at fault. > > > > 8.1 is the relevant section of the BRs, and the issue was recently > discussed on this list: > https://groups.google.com/d/msg/mozilla.dev.security.policy/rR9g5BJ6R8E/Gwzqquv6BgAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
On Mon, Jun 25, 2018 at 2:45 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 7. In my humble opinion, I think that these requirements must be formalized > > in audit criteria or explicitly in the BR, and not raised "ad hoc". Any > CA > > embarking in an inclusion process should know all requirements > beforehand. > > > But they're already arguably part of the BRs, as I showed, and it's up to > the relevant groups (WebTrust, ETSI) to ensure that the criteria they adopt > reflect what browsers expect. As we see with ETSI and ACAB-c, if the > auditor fails to meet those requirements, it's the auditor that's at fault. > > 8.1 is the relevant section of the BRs, and the issue was recently discussed on this list: https://groups.google.com/d/msg/mozilla.dev.security.policy/rR9g5BJ6R8E/Gwzqquv6BgAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > thanks for your time reviewing this. I really appreciate your comments. > > As I have this week the auditors in the office, I prefer to check with > them before issuing a more formal answer, because you're expressing > concerns related to the audit practices that I'm not qualified enough to > respond. > > In the meantime, please let me advance the following initial comments: > 1.- I can't really understand how it can be expected that a CA is able to > issue a point in time including BR dated the same day of the issuance of a > Root, because that seems not possible. Any CA needs a minimum time to > prepare an issuing CA, OCSP responders and doing SSL certificate tests, and > AFAIK, this lapsed period is not regulated by BR nor Webtrust. > I agree - but WebTrust at least provides a reporting mechanism for this, by indicating the scope of the audit and the (verified) non-performance of certain activities. For comparison, you can look at how the latest illustrative reports formalize what many were already doing (or specifically requested to do), by calling out things like the explicit (and verified) non-existence of RAs or key escrow services. For a new root being spun up, you need to verify that, at the moment the key was created, the policies and procedures were in place to safeguard that key, and then going forward, that those policies and procedures have been examined consistently. This is part of the requirement for an "unbroken series of audits". How it's reported on is an issue - and that's why browsers have been working to communicate directly with the WebTrust TF about these concerns so that they can make sure that their practitioner guidance and illustrative reports call this out, for practitioners working for CAs that wish to be trusted by browsers. I realize that, as a CA, you can be caught unawares if the auditor is not following these discussions or best practices, and we're always keen to make sure there's better understanding. That said, I think the communication of the concerns around root key generation and its ongoing proof of continued compliance is one that browsers have well-represented to auditors, so when there's breakdowns, it's either between the Task Force and the individual practitioners, or between practitioners and their customers. 7. In my humble opinion, I think that these requirements must be formalized > in audit criteria or explicitly in the BR, and not raised "ad hoc". Any CA > embarking in an inclusion process should know all requirements beforehand. But they're already arguably part of the BRs, as I showed, and it's up to the relevant groups (WebTrust, ETSI) to ensure that the criteria they adopt reflect what browsers expect. As we see with ETSI and ACAB-c, if the auditor fails to meet those requirements, it's the auditor that's at fault. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hi Ryan, thanks for your time reviewing this. I really appreciate your comments. As I have this week the auditors in the office, I prefer to check with them before issuing a more formal answer, because you're expressing concerns related to the audit practices that I'm not qualified enough to respond. In the meantime, please let me advance the following initial comments: 1.- I can't really understand how it can be expected that a CA is able to issue a point in time including BR dated the same day of the issuance of a Root, because that seems not possible. Any CA needs a minimum time to prepare an issuing CA, OCSP responders and doing SSL certificate tests, and AFAIK, this lapsed period is not regulated by BR nor Webtrust. 2.- In our particular case we had some issues delaying the readiness of proper BR compliance for GC, mainly for two reasons, one was the summer holidays and also we had to fight with a bug in Microsoft Certificate Services that made the CA certificate to include a '\0' character after the policy qualifier URL, and this delayed the process (you can find a reference here: https://pkisolutions.com/2012r2hotfixes/ check for "Bug 5298357 – Bad ASN.1 encoding of certificate issuance policy extensions"). The auditors detected this issue and only accepted the issuing CA for the point-in-time once this problem was solved. 3.- The key ceremony of this Root was witnessed by the same auditors. I would say that the mere fact that an auditor issues a point in time WT BR report implies undoubtedly full compliance with this requirement, as with any other one set by BR. Therefore, the fact that the PiT exists, means that the key ceremony was executed according to the rule. 4.- Please check in this link (https://filevault.wisekey.com/d/412f61ab26/) the redline intermediate versions. It must be noted that not all versions are formally adopted and go public (i.e. version 2.7 was a working version). These are mostly changes to include the GC hierarchy, properly reflect latest BR (i.e. validity periods, reflect the contact point for incident reporting, etc) and also to correct minor glitches. 5. In 25/July it happened that we published a new version of the CPS, including some changes recommended by the auditors. You can see the differences in the PDF file and judge yourself the relevance of the changes. Any further comment will be welcome. 6.- As a result of these discussions and open concerns, and based in the auditor recommendation to advance in this inclusion process, we already proposed here to change the audit period so it starts the 9th of May 2017 instead of the planned annual renew. Fortunately it was only one month difference, but I must say that I'd have preferred to take this decision based in a formal compliance issue that I could understand, because if it had been several months overlap it would have had a much bigger 7. In my humble opinion, I think that these requirements must be formalized in audit criteria or explicitly in the BR, and not raised "ad hoc". Any CA embarking in an inclusion process should know all requirements beforehand. I'll provide further comments after checking with the auditors. Thanks again and best regards, Pedro El lunes, 25 de junio de 2018, 19:25:34 (UTC+2), Ryan Sleevi escribió: > Hi Pedro, > > I followed-up with folks to better understand the circumstances of your > audits and the existing practicioner guidance. From these conversations, my > understanding is that WebTrust is working to provide better practicioner > clarity around these scenarios. > > To recap, the particular scenario of concern is: > - A new root key is generated (May 2017 - presumably, May 9, 2017 as > expressed in the cert) > - Under BRs 6.1.1.1, this should be witnessed by the auditor (or a video > recorded), and the auditor should issue a report opining on it > - Under WebTrust, using ISAE3000 reporting ( > http://www.webtrust.org/practitioner-qualifications/docs/item85806.pdf ), > that illustrative report is IN5.1 > - The first audit, on September 15, 2017, is a Point in Time assessment > - The next audit provided is for the period of September 16, 2017 to > December 4, 2017 > - The report is based on the CPS dated July 25, 2017 > - Thus, we lack any reporting or opining on the set of controls or > processes, minimally from the period of May 2017 to July 25, 2017 - but > potentially from May 2017 to September 2017. > - As a consequence, we cannot have reasonable assurance that BRs 6.1.1.1, > p3, (5) was upheld - that is, for the period of May to July/September, that > OISTE maintained "effective controls to provide reasonable assurance that > the Private Key was generated and protected in conformance with the > procedures described in its Certificate Policy and/or Certification > Practice Statement and (if applicable) its Key Generation Script" > > In an "ideal" world, for a new CA (since this is not being paired with your > Gen A/Gen B
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hi Pedro, I followed-up with folks to better understand the circumstances of your audits and the existing practicioner guidance. From these conversations, my understanding is that WebTrust is working to provide better practicioner clarity around these scenarios. To recap, the particular scenario of concern is: - A new root key is generated (May 2017 - presumably, May 9, 2017 as expressed in the cert) - Under BRs 6.1.1.1, this should be witnessed by the auditor (or a video recorded), and the auditor should issue a report opining on it - Under WebTrust, using ISAE3000 reporting ( http://www.webtrust.org/practitioner-qualifications/docs/item85806.pdf ), that illustrative report is IN5.1 - The first audit, on September 15, 2017, is a Point in Time assessment - The next audit provided is for the period of September 16, 2017 to December 4, 2017 - The report is based on the CPS dated July 25, 2017 - Thus, we lack any reporting or opining on the set of controls or processes, minimally from the period of May 2017 to July 25, 2017 - but potentially from May 2017 to September 2017. - As a consequence, we cannot have reasonable assurance that BRs 6.1.1.1, p3, (5) was upheld - that is, for the period of May to July/September, that OISTE maintained "effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script" In an "ideal" world, for a new CA (since this is not being paired with your Gen A/Gen B CAs), we would have - Root Key report issued on Day X - Point in Time assessment issued on Day X - Period of Time assessment issued from Day X to Day Y - If the CA was not issuing certificates / not all controls could be reporterd on, then the scope of the audit would indicate as such, until such a time as the CA does. - Y should not be greater than 90 days after the first publicly trusted certificate was issued. Unfortunately, not all WebTrust practitioners have been given this guidance, and as a result, have not passed it on to the CAs that they are auditing. While some auditors do practice this chain of evidence/audits from the birth of certificate, not all auditors do. At this point, it's a question about how the community feels about the set of changes between the following CP/CPS versions: 2.7, 2.8, 2.9, and 2.10. In particular, the set of changes in 2.9 call out "Minor changes after WebTrust assessment" - which suggests that, prior to the September 15, 2017 PITRA, there were issues or non-conformities that required addressing, before the full engagement. - Can you speak more to what happened on July 25, 2017? - Can you provide diffs for 2.7 to 2.10? Basically, what are things that can the community be confident in the management and scope of the root certificate between May 9, 2017 and September 16, 2017. Examples of considerations can be the adoption of the same CP/CPS, the inclusion in scope of a previous audit (for example, was this included in the scope of the Gen A/Gen B CAs audit for the period ending September 15, 2017?), or other documentary evidence. On Sat, Jun 16, 2018 at 11:45 AM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > Sorry for my insistence, but our audit is scheduled in less than two weeks. > I'd appreciate some feedback in the case there's any deviation with BR-8.1 > that prevent keeping the planned audit scope. > Thanks! > Pedro > > El martes, 5 de junio de 2018, 9:02:42 (UTC+2), Ryan Sleevi escribió: > > Hi Pedro, > > > > I think the previous replies tried to indicate that I will not be > available > > to review your feedback at all this week. > > > > On Mon, Jun 4, 2018 at 9:18 AM, Pedro Fuentes via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > Kind reminder. > > > Thanks! > > > > > > ___ > > > dev-security-policy mailing list > > > dev-security-policy@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hello, Sorry for my insistence, but our audit is scheduled in less than two weeks. I'd appreciate some feedback in the case there's any deviation with BR-8.1 that prevent keeping the planned audit scope. Thanks! Pedro El martes, 5 de junio de 2018, 9:02:42 (UTC+2), Ryan Sleevi escribió: > Hi Pedro, > > I think the previous replies tried to indicate that I will not be available > to review your feedback at all this week. > > On Mon, Jun 4, 2018 at 9:18 AM, Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Kind reminder. > > Thanks! > > > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hi Pedro, I think the previous replies tried to indicate that I will not be available to review your feedback at all this week. On Mon, Jun 4, 2018 at 9:18 AM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Kind reminder. > Thanks! > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Kind reminder. Thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Dear all, As a reminder... WISeKey has three Roots "GA" (Generation A), GB and GC. GA and GB are already included and covered by annual audits. GC is the new one, only included by now by Microsoft. I got some inputs from the auditors, that I add here: "For the next annual audit, covering the period starting the 3rd of June 2017, it was already planned that it would consolidate the three Roots and hierarchies, even if this implies an overlapping period with the point-in-time and 3-month period audit for the new GC Root. Nevertheless, if there’s a concern on the period after the GC Root was created (25th of May), it would be possible to adapt the period of the consolidated audit to start that day, so doing it from 25th May 2017 to 24th May 2018." Therefore, I'd appreciate if you analyze the auditor's comment and state your position in front of this perceived issue. Said that, I'd like to point out this personal comment... According to BR-8.1: "If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.1, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.1. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate." For this new GC Root we did a Point-in-time, and I'd say that a PiT for BR can only be dated once there's capability to issue SSL, and after the PiT, we did the 3-month subsequent audit... I would dare to say that all this seems in line of BR. But, as already said, please kindly state your opinion and we'll dutifully do whatever is required. Thanks and regards, Pedro El viernes, 25 de mayo de 2018, 11:57:16 (UTC+2), Pedro Fuentes escribió: > Thanks a lot, Ryan. > > I see there's still an open concern, so I'll add a first comment to it. > > > > > * As noted, the key generation was performed in May, and this audit is a > > > > period of time audit beginning in September. This does mean that there > > > is a > > > > gap in the audit coverage - from May through September - that's > > > > difficult > > > > to reason about. Are there any other supporting documents that would > > > > help > > > > assuage these concerns? > > > > > > COMMENTS FROM WISEKEY: > > > We had a pause period between the Root CA Ceremony and the creation of a > > > first issuing CA, so actually there weren't operations to audit. > > > That’s the reason of the “gap”, as the Root didn’t issue any certificate > > > and was just left deactivated, so the first period audit started with the > > > effective start of operations and verified a first three-month period > > > after > > > this start of operations, during which we only issued a few test > > > certificates. > > > > > > > > > > So, one area that we've discussed with WebTrust about this is the Root Key > > Generation Ceremony Report (IN5.1 from the Illustrative reports), along > > with reporting on the CP/CPS that governs that key and its physical > > protections, and then on to actual operations. > > > > The goal here is roughly: How, as a community, do we make sure that when it > > was left deactivated, it wasn't just left under someone's desk with no key > > protections, and which might have signed things that come back to bite us > > later? We've seen CAs in the past fail to maintain physical access logs, > > for example, and thus there's no way anyone can be really sure what > > happened to or with that key material. > > > > There is the challenge that you mention - which is how do you opine on > > operations when it's just sitting unused - but there are still controls in > > place (such as physical security, auditing, access controls) that > > presumably are being practiced. > > > > I'm a bit uncertain on how best to proceed here on this. I'd like to seek > > feedback and understanding from our WebTrust & CPA Canada colleagues about > > how, procedurally, this is handled - as this has been a topic of discussion > > for several years, and we've heard several statements about what the > > expectations are for situations like this. > > > > >From my humble perspective I didn't find the issue, as this is not a new > >Root coming out of the blue, but a Root added to an existing (and included > >in CCADB) set of roots and a consolidated PKI covered by a single CPS. This > >means that all CA are managed immediately after the Ceremony under the same > >existing Trust Model, security policies, procedures, team, datacenter, etc. > > I also see the "deactivated" status as the one that should be naturally > expected for an offline Root CA during the 99.9% of its life-time, so > a
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Thanks a lot, Ryan. I see there's still an open concern, so I'll add a first comment to it. > > > * As noted, the key generation was performed in May, and this audit is a > > > period of time audit beginning in September. This does mean that there > > is a > > > gap in the audit coverage - from May through September - that's difficult > > > to reason about. Are there any other supporting documents that would help > > > assuage these concerns? > > > > COMMENTS FROM WISEKEY: > > We had a pause period between the Root CA Ceremony and the creation of a > > first issuing CA, so actually there weren't operations to audit. > > That’s the reason of the “gap”, as the Root didn’t issue any certificate > > and was just left deactivated, so the first period audit started with the > > effective start of operations and verified a first three-month period after > > this start of operations, during which we only issued a few test > > certificates. > > > > > > So, one area that we've discussed with WebTrust about this is the Root Key > Generation Ceremony Report (IN5.1 from the Illustrative reports), along > with reporting on the CP/CPS that governs that key and its physical > protections, and then on to actual operations. > > The goal here is roughly: How, as a community, do we make sure that when it > was left deactivated, it wasn't just left under someone's desk with no key > protections, and which might have signed things that come back to bite us > later? We've seen CAs in the past fail to maintain physical access logs, > for example, and thus there's no way anyone can be really sure what > happened to or with that key material. > > There is the challenge that you mention - which is how do you opine on > operations when it's just sitting unused - but there are still controls in > place (such as physical security, auditing, access controls) that > presumably are being practiced. > > I'm a bit uncertain on how best to proceed here on this. I'd like to seek > feedback and understanding from our WebTrust & CPA Canada colleagues about > how, procedurally, this is handled - as this has been a topic of discussion > for several years, and we've heard several statements about what the > expectations are for situations like this. > From my humble perspective I didn't find the issue, as this is not a new Root coming out of the blue, but a Root added to an existing (and included in CCADB) set of roots and a consolidated PKI covered by a single CPS. This means that all CA are managed immediately after the Ceremony under the same existing Trust Model, security policies, procedures, team, datacenter, etc. I also see the "deactivated" status as the one that should be naturally expected for an offline Root CA during the 99.9% of its life-time, so actually I don't see it as something extraordinary. Probably the problem here is that we just considered that when starting a three-month period audit we should start it after the systems where capable to issue SSL certificates, and therefore we decided to start it around the creation of the first Issuing CA. Probably the easiest approach would have been to produce an audit report of 4 or 5 months instead one of 3, and include the initial period where there wasn't yet any Issuing CA, but just the new offline Root. Nevertheless, I can understand your comment, and I think the question requires a more formal approach, so I requested again the assessment of our auditors and I'll come back with their inputs. Thanks, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Pedro, Thanks for the quick and detailed replies! A few responses inline. On Thu, May 24, 2018 at 8:19 AM, Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > * 1.5.4 requires a full meeting of the CAA to convene for updates, which > > may make it difficult to have the CPS (and the attendant CA policies) > > reflect the BRs > > I understand you mean the PAA. As we say in the CPS “Minor versions only > require the participation of a single member of the PAA in order to approve > the publication of a new version.” This accelerates the process for quick > amendments like the ones derived of your kind review (I’m myself member if > the PAA). > > Thanks. I did mean PAA (had CAA on the brain), and mostly wanted to make sure that we don't have the same process overhead that other CAs have reported with updating CP/CPSes for compliance. The structure of the OWGTM suggested an independent policy authority that then set policy for WISeKey to implement, which sounded like it could lead to these problems. > > * 3.2.6 notes an accreditation process for interoperating, but doesn't > note > > whether that includes audits consistent with section 8 of the BRs > > We set the requirements for audit and compliance and audit in section 8 of > the CPS, and that has to be respected in any case. This particular section > is just pointing some additional controls related to interoperation, but > frankly speaking I don’t see of much relevance, I could easily change it to > “No stipulation”. > > Thanks for clarifying. Understandably, there's usually several places and ways that one can express information in the CPS, and that's part of why we do these detailed reviews - to make sure that things are both internally consistent and contain the relevant information. I'm supportive of including more details about the operational aspects, and so I think it's good that you included this. My main concern was "They list these additional controls, but how do they validate they are followed" - so perhaps it's as simple as just mentioning Section 8? To be clear, this is minor (meh) - I think your explanation suffices, and you could change to "No stipulation", make no changes, or make changes to reference other sections, and I think they'd all be good. > > * 4.3 states "The OWGTM is not responsible for monitoring, research or > > confirmation of the correctness of the information contained in a > > certificate during the intermediate period between its issuance and > > renewal, ", which in one read, is entirely consistent with 9.6.1 of the > BRs > > (consistent in that it's at time of issuance), but in another read, could > > be seen as conflicting with 4.9.1.1 of the BRs > > Maybe is a problem of language or interpretation, but we say that once the > certificate is properly validated and issued, we can’t control the ulterior > correctness of the information (i.e. change in domain ownership) until a > new validation round (I.e. for a renewal) is performed. I would appreciate > more details in your concern and I’m afraid I couldn’t find the > relationship with BR-4.9.11 which is related to revocation status. > > Yeah, I think it's just a language/interpretation issue. This wasn't a big concern (hence meh). Section 9.6.1 of the BRs makes it clear that the issuance of a certificate is a certification at a point in time - that CAs can't continually monitor the information for change (as you mention). That said, the BRs also obligate Subscribers to notify CAs of changes (9.6.2) and for CAs to act upon such notifications (4.9.1.1, revoking for material changes), so I was calling out that one possible interpretation is a suggestion that OWGTM *won't* revoke if they become aware that the information changes (4.9.1.1). I don't think that was the intent, but it was ambiguous enough that I wanted to call it out and make sure we're on the same page :) > > * Section 5.2.2 / 5.2.4 don't detail the minimum number of people > required > > for certain activities. > > The fact of mandating separation of duties would imply a minimum of two > persons, but I never saw these details on the number of people per task in > other CPS… Is this really needed? > > You'd be surprised - there are some who argue separation of duties can be met by the same person, acting in different roles. I've sadly had this come up in other compliance exercises (FIPS), in which duties are split between 'logical' roles and 'physical' roles - in which the same physical person can (not simultaneously) operate many logical roles. I agree that it's not something consistently applied through CPSes - the sheer number of them make it hard to make sure we give consistent and reliable feedback on each and every one for the same issues, and especially as patterns change over time, different issues come to the forefront. It was from recently dealing with compliance issues (unrelated to CAs) that the physical/l
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Dear all, please find bellow our responses to the "Meh" and "Bad" issues raised by Ryan. In respect to the points related to our auditors, we got their feedback and we're inserting also their responses here. Some of the points implied a change in the CPS, which is going to be published in less than 24h in our site, but already available for your review at this link https://filevault.wisekey.com/f/c7b0d13153/ It was really good for us having some new eyes to review the document, so we really appreciate your contribution. Let us know if there's any other clarification required. Thanks and regards, Pedro El martes, 22 de mayo de 2018, 21:11:51 (UTC+2), Ryan Sleevi escribió: > Thanks for the reminder, Wayne. (...) > == Meh == > * 1.4.1.2, which details the validation process for server certificates, > explicitly calls out domain verification for DV, but not for OV/EV. Checks for OV/EV are “Additional” to the ones done for DV, as explicitly mentioned in section 12.2.2 so domain validation of OV is done as for the DV, and then there are additional controls for the specifics of OV/EV. I’ll see maybe about making this more explicit in next versions. > * It's unclear if this implies the use of the (deprecated) 3.2.2.4.1 / > 3.2.2.4.5 as demonstrations of domain "ownership" independent of domain > "control" > * Annex E makes it clear that .1 and .5 are in scope as validation > methods, which should be phased out by August. Yes, we mention that these methods are still accepted, but as I explained in Bugzilla, this is for us always a complementary check, we never rely on this as a sole validation method, so being complementary we think that it was actually positive to keep it by now. > * 1.5.4 requires a full meeting of the CAA to convene for updates, which > may make it difficult to have the CPS (and the attendant CA policies) > reflect the BRs I understand you mean the PAA. As we say in the CPS “Minor versions only require the participation of a single member of the PAA in order to approve the publication of a new version.” This accelerates the process for quick amendments like the ones derived of your kind review (I’m myself member if the PAA). > * 3.2.6 notes an accreditation process for interoperating, but doesn't note > whether that includes audits consistent with section 8 of the BRs We set the requirements for audit and compliance and audit in section 8 of the CPS, and that has to be respected in any case. This particular section is just pointing some additional controls related to interoperation, but frankly speaking I don’t see of much relevance, I could easily change it to “No stipulation”. > * 4.3 states "The OWGTM is not responsible for monitoring, research or > confirmation of the correctness of the information contained in a > certificate during the intermediate period between its issuance and > renewal, ", which in one read, is entirely consistent with 9.6.1 of the BRs > (consistent in that it's at time of issuance), but in another read, could > be seen as conflicting with 4.9.1.1 of the BRs Maybe is a problem of language or interpretation, but we say that once the certificate is properly validated and issued, we can’t control the ulterior correctness of the information (i.e. change in domain ownership) until a new validation round (I.e. for a renewal) is performed. I would appreciate more details in your concern and I’m afraid I couldn’t find the relationship with BR-4.9.11 which is related to revocation status. > * Section 4.9.1 lists 13 items, but there are 15 in the corresponding BRs. > Item #4 from the BRs is combined with Item #3 in the CPS, and Item #7 is > missing from the BRs as an explicit callout. #14 and #15 in the BRs are > seemingly not present, as the place where they would be expected - #12 and > #13 - from the CPS are different. Well… Instead of making an exercise to match here our wording and the BR, I just updated the CPS and copied literarily the BR. I can’t see any conflict and it won’t affect our operations, so I think it’s the cleanest solution. > * Section 5.2.2 / 5.2.4 don't detail the minimum number of people required > for certain activities. The fact of mandating separation of duties would imply a minimum of two persons, but I never saw these details on the number of people per task in other CPS… Is this really needed? > * Section 6.2.4 states that CA backup keys are "typically" store encrypted. > What protections are in place if they're not encrypted? Sorry, I just realized about this language problem… this has been edited to “always” in the new CPS update. We say in the same section that these backups are kept in hardware cryptographic modules, so obviously it can’t be in unencrypted form. > * Section 7.3.2 misunderstands OCSP extensions as being about the > certificates, rather than extensions within OCSP responses (such as CT > extensions, s
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Thanks Wayne and Ryan, your feedback always helps us to improve. I'll respond in a separate message to Ryan concerns/questions. Only about the audit periods... it's not easy to synchronize everything, so what we did is the following: - A point-in-time audit after the Root was created - A three-month first period audit, as required by the different root store policies We supplied the positive audit reports for these PiT and Period audits, but not the seals, as we typically would do that once the Roots are included and part of the annual audit. From that point on, the Root and its hierarchy is included in the annual audit, that already engaged with the auditors. This would produce the adequate audit reports and the respective Webtrust seals. As said, more answers to come in a while. Best, Pedro El martes, 22 de mayo de 2018, 22:38:42 (UTC+2), Wayne Thayer escribió: > On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi wrote: > > > Overall, I think this would be good to proceed, but there's certain > > discrepancies called out under Questions that I think should be resolved > > before doing so. I would suggest contacting WISeKey for follow-up on these, > > and not proceed until we've got a satisfactory response. With the upcoming > > CA/Browser Forum F2F, I think that effectively means a delay of > > approximately two weeks, to allow both WISeKey to respond and the community > > (and maintainers) to review for sufficiency. I think that, provided a > > response is provided, than barring any further feedback raising additional > > concerns, proceeding by June 14 would be a reasonable timeframe? Does that > > seem like a reasonable set of expectations and timing? > > > > This sounds reasonable, but I will note that there is no time limit on > public discussions - this one will end after WISeKey has responded to these > questions and sufficient time has passed for any additional concerns to be > raised. > > > > > * As noted, the key generation was performed in May, and this audit is a > > period of time audit beginning in September. This does mean that there is a > > gap in the audit coverage - from May through September - that's difficult > > to reason about. Are there any other supporting documents that would help > > assuage these concerns? > > > > I would have expected this new root to be included on WISeKey's next > regular audit statements for the period ending June 2nd 2017, but WISeKey > apparently chooses to perform separate audits (or at least procure separate > audit statements) for each of it's roots. Given these circumstances, I > share Ryan's concerns and would like an explanation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi wrote: > Overall, I think this would be good to proceed, but there's certain > discrepancies called out under Questions that I think should be resolved > before doing so. I would suggest contacting WISeKey for follow-up on these, > and not proceed until we've got a satisfactory response. With the upcoming > CA/Browser Forum F2F, I think that effectively means a delay of > approximately two weeks, to allow both WISeKey to respond and the community > (and maintainers) to review for sufficiency. I think that, provided a > response is provided, than barring any further feedback raising additional > concerns, proceeding by June 14 would be a reasonable timeframe? Does that > seem like a reasonable set of expectations and timing? > > This sounds reasonable, but I will note that there is no time limit on public discussions - this one will end after WISeKey has responded to these questions and sufficient time has passed for any additional concerns to be raised. > > * As noted, the key generation was performed in May, and this audit is a > period of time audit beginning in September. This does mean that there is a > gap in the audit coverage - from May through September - that's difficult > to reason about. Are there any other supporting documents that would help > assuage these concerns? > > I would have expected this new root to be included on WISeKey's next regular audit statements for the period ending June 2nd 2017, but WISeKey apparently chooses to perform separate audits (or at least procure separate audit statements) for each of it's roots. Given these circumstances, I share Ryan's concerns and would like an explanation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Thanks for the reminder, Wayne. I've reviewed the CPS and Audit Reports and have the following comments. I will note that, due to having already had someone else look at it, I only focused on information validation related to domains and IPs, and did not examine the policies around OV and EV, as those are generally not applicable to trust on the Web. Overall, I think this would be good to proceed, but there's certain discrepancies called out under Questions that I think should be resolved before doing so. I would suggest contacting WISeKey for follow-up on these, and not proceed until we've got a satisfactory response. With the upcoming CA/Browser Forum F2F, I think that effectively means a delay of approximately two weeks, to allow both WISeKey to respond and the community (and maintainers) to review for sufficiency. I think that, provided a response is provided, than barring any further feedback raising additional concerns, proceeding by June 14 would be a reasonable timeframe? Does that seem like a reasonable set of expectations and timing? == Good == * 2.1 notes that they make a public repository of issued certificates available, which is good to see positive affirmation of certificates being public * 3.1.4 and Annex B provide ample detail about the certificate fields and their validated context, which provides a reasonable basis for understanding their certificate profile and validation practices * 3.1.6 "In any event, the OWGTM will not attempt to intermediate nor resolve conflicts regarding ownership of names or trademarks." - It is good to CA recognize its role in not independently trying to determine trademark issues, and instead defer those to proper adjudication. I wish all CAs would recognize this. * 4.9.7 publishes CRLs in 3 days, effectively half the BR-required time (of 7 days), leading to more effective revocation distribution. * 7.2.2 notes a quality profile for CRLs * Note: It could be improved to document the maximum size (worst case) of CRLs or how sharding is done (across issuerDistributionPoint extensions), to ensure that the worst case CRL size (if all certs pointing to that CRL were revoked) is kept within a reasonable size limit, such as 64K. That's an opportunity for improvement, but admittedly requires more careful engineering design to implement. * 9.4.2 notes that "private information" does NOT include information contained within a certificate or CRL, which is the correct interpretation * 9.6.1 explicitly notes MITM is prohibited. While implicit, it's also encouraging to see this explicitly called out. * Annex E notes that they support IODEF, and the supported methods (this is a SHOULD, not a MUST, in the BRs) == Meh == * 1.4.1.2, which details the validation process for server certificates, explicitly calls out domain verification for DV, but not for OV/EV. * It's unclear if this implies the use of the (deprecated) 3.2.2.4.1 / 3.2.2.4.5 as demonstrations of domain "ownership" independent of domain "control" * Annex E makes it clear that .1 and .5 are in scope as validation methods, which should be phased out by August. * 1.5.4 requires a full meeting of the CAA to convene for updates, which may make it difficult to have the CPS (and the attendant CA policies) reflect the BRs * 3.2.6 notes an accreditation process for interoperating, but doesn't note whether that includes audits consistent with section 8 of the BRs * 4.3 states "The OWGTM is not responsible for monitoring, research or confirmation of the correctness of the information contained in a certificate during the intermediate period between its issuance and renewal, ", which in one read, is entirely consistent with 9.6.1 of the BRs (consistent in that it's at time of issuance), but in another read, could be seen as conflicting with 4.9.1.1 of the BRs * Section 4.9.1 lists 13 items, but there are 15 in the corresponding BRs. Item #4 from the BRs is combined with Item #3 in the CPS, and Item #7 is missing from the BRs as an explicit callout. #14 and #15 in the BRs are seemingly not present, as the place where they would be expected - #12 and #13 - from the CPS are different. * Section 5.2.2 / 5.2.4 don't detail the minimum number of people required for certain activities. * Section 6.2.4 states that CA backup keys are "typically" store encrypted. What protections are in place if they're not encrypted? * Section 7.3.2 misunderstands OCSP extensions as being about the certificates, rather than extensions within OCSP responses (such as CT extensions, should that be supported, or nonces, if that should unfortunately be supported [and it shouldn't]) * Annex B, 11.3.1, lists SAN in the base certificate profile, rather than as an X.509v3 extension, and doesn't explicitly list the CN as being one of the SAN values == Bad == * Annex B, 11.3.1, does not list the extendedKeyUsage in the profile for SSL certificates which is mandatory per the BRs 7.1.2.3. * Other profiles under Annex B do list it (under the misnamed "E
Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Reminder: there is one week left in the discussion period for this inclusion request. On Tue, May 1, 2018 at 12:02 PM Wayne Thayer wrote: > This request is for inclusion of the OISTE WISeKey Global Root GC CA as > documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1403591 > > * BR Self Assessment is here: > https://bugzilla.mozilla.org/attachment.cgi?id=8912732 > > * Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8955363 > > * Root Certificate Download URL: > https://bugzilla.mozilla.org/attachment.cgi?id=8912737 > > CP/CPS: > https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf > > * This request is to turn on the Websites and Email trust bits. EV > treatment is not requested. > > * EV Policy OIDs: Not EV > > * Test Websites > https://gcvalidssl.hightrusted.com/ > https://gcexpiredssl.hightrusted.com/ > https://gcrevokedssl.hightrusted.com/ > > * CRL URL: http://public.wisekey.com/crl/wcidgcas1.crl > > * OCSP URL: http://ocsp.wisekey.com/ > > * Audit: Annual audits are performed by AUREN according to the WebTrust > for CA and BR audit criteria. > WebTrust: > https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf > BR: > https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf > EV: Not EV > > I’ve reviewed the CPS, BR Self Assessment, and related information for the > OISTE WISeKey Global Root GC CA inclusion request that are being tracked in > this bug and have the following comments: > > ==Good== > * This root was created in May of 2017 and the intermediate appears to > have only signed test certs since then. > * Problem reporting mechanism is clearly labeled as such in the CPS. > > ==Meh== > * The older OISTE WISeKey Global Root GA CA that is in our program has > issued a few certs containing linting errors (some are false positives for > OCSP signing certs): > https://crt.sh/?caid=15102&opt=cablint,zlint,x509lint&minNotBefore=2010-01-01 > Two notable concerns are: > ** Valid wildcard certificate for a public suffix: > https://crt.sh/?id=76535370&opt=cablint (BR 3.2.2.6 permits this only if > “the applicant proves its rightful control of the entire Domain Namespace“) > ** Valid cert containing a non-printable string in the Subject : > https://crt.sh/?id=308365498&opt=x509lint,ocsp > * WISeKey was the subject of one misissuance bug for “invalid dnsNames” > and “CN not in SAN” errors to which they responded promptly: > https://bugzilla.mozilla.org/show_bug.cgi?id=1391089 > ** They also failed to respond to a problem report during this > incident. > Domain validations procedures are listed in an appendix instead of section > 3.2.2.4 of the CPS and they include the soon-to-be-banned 3.2.2.4.1 and > 3.2.2.4.5 methods. A note indicates that 3.2.2.4.5 will be discontinued > after August 1st. The reference to 3.2.2.4.1 appears to be a documentation > error. > During my initial review, the CPS was missing CAA information and still > referenced 3-year validity periods. WISeKey quickly made the needed changes > but indicated that they update their CPS during an annual review rather > than regularly as new requirements come into effect. > > ==Bad== > Nothing to report > > This begins the 3-week comment period for this request [1]. > > I will greatly appreciate your thoughtful and constructive feedback on the > acceptance of this root into the Mozilla CA program. > > - Wayne > > [1] https://wiki.mozilla.org/CA/Application_Process > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
OISTE WISeKey Global Root GC CA Root Inclusion Request
This request is for inclusion of the OISTE WISeKey Global Root GC CA as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1403591 * BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8912732 * Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8955363 * Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8912737 CP/CPS: https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf * This request is to turn on the Websites and Email trust bits. EV treatment is not requested. * EV Policy OIDs: Not EV * Test Websites https://gcvalidssl.hightrusted.com/ https://gcexpiredssl.hightrusted.com/ https://gcrevokedssl.hightrusted.com/ * CRL URL: http://public.wisekey.com/crl/wcidgcas1.crl * OCSP URL: http://ocsp.wisekey.com/ * Audit: Annual audits are performed by AUREN according to the WebTrust for CA and BR audit criteria. WebTrust: https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf BR: https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf EV: Not EV I’ve reviewed the CPS, BR Self Assessment, and related information for the OISTE WISeKey Global Root GC CA inclusion request that are being tracked in this bug and have the following comments: ==Good== * This root was created in May of 2017 and the intermediate appears to have only signed test certs since then. * Problem reporting mechanism is clearly labeled as such in the CPS. ==Meh== * The older OISTE WISeKey Global Root GA CA that is in our program has issued a few certs containing linting errors (some are false positives for OCSP signing certs): https://crt.sh/?caid=15102&opt=cablint,zlint,x509lint&minNotBefore=2010-01-01 Two notable concerns are: ** Valid wildcard certificate for a public suffix: https://crt.sh/?id=76535370&opt=cablint (BR 3.2.2.6 permits this only if “the applicant proves its rightful control of the entire Domain Namespace“) ** Valid cert containing a non-printable string in the Subject : https://crt.sh/?id=308365498&opt=x509lint,ocsp * WISeKey was the subject of one misissuance bug for “invalid dnsNames” and “CN not in SAN” errors to which they responded promptly: https://bugzilla.mozilla.org/show_bug.cgi?id=1391089 ** They also failed to respond to a problem report during this incident. Domain validations procedures are listed in an appendix instead of section 3.2.2.4 of the CPS and they include the soon-to-be-banned 3.2.2.4.1 and 3.2.2.4.5 methods. A note indicates that 3.2.2.4.5 will be discontinued after August 1st. The reference to 3.2.2.4.1 appears to be a documentation error. During my initial review, the CPS was missing CAA information and still referenced 3-year validity periods. WISeKey quickly made the needed changes but indicated that they update their CPS during an annual review rather than regularly as new requirements come into effect. ==Bad== Nothing to report This begins the 3-week comment period for this request [1]. I will greatly appreciate your thoughtful and constructive feedback on the acceptance of this root into the Mozilla CA program. - Wayne [1] https://wiki.mozilla.org/CA/Application_Process ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy