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 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
