Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer]

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 <wth...@mozilla.com> 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
>

[Ryan Sleevi]

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 "Enhanced
Key Usage"), so this should be corrected to include id-kp-serverAuth (and
optionally id-kp-clientAuth)
* 11.3.2 lists it under "Key Usages"
* Annex B, 11.3.2 / 11.3.3 lists the Netscape Certificate Type as optional.
There's no reasonable need to support this extension. Let's let it die :)
* Annex E, 14.1.4 / 14.2.4, notes the use of "Any Other Method" for IP
validation


== Questions ==
* I've confirmed that AUREN is a licensed WebTrust practitioner, as per
[1]. When reviewing the audit report, I note that a WebTrust seal was not
provided (which is not a requirement), but that may have masked other
review items. In examining the report, [2], I noticed some deviations from
the IASE 3000 illustrative reporting provided by WebTrust [3] for such
reports, particularly IN1.1 (which is for WebTrust for CAs) in [3].
* In the illustrative reports, it calls out being engaged in a reasonable
assurance audit, while in the AUREN report, it states it has audited
management's assertion. Is there significance in the deviation of language?
* [2] does not list the location of the CA services, although [4], oddly
enough, does. This is worth following up on.
* It notes that external RAs are used, but does not note that key escrow
or certificate suspension are out of scope - meaning they are in scope.
This is consistent with the CPS [5] in Section 4.9, which notes that
non-SSL certificates may undergo suspension, and Section 4.12, which notes
non-SSL end-entity certificates may undergo escrow.
* In listing auditor responsibilities, it explicitly notes that it did
not test the operating effectiveness of these controls (Item 3 in the
illustrative report, which is explicitly called out as out of scope in [2])
* 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?
* Similarly, comparing [4] with [3] produces some deviations for IN 2.1
(which is for SSL BRs):
* Like [2], it calls out that testing operating effectiveness was not
part of the scope, in this case, entirely omitting (2) from IN 2.1 and
modifying (3) to exclude testing.
* The hierarchy within the reports calls out the "OISTE WISeKey Global Root
GC CA", which is presumably the "OWGTM Root CA GC" mentioned in the CPS
[5], and the "WISeKey CertifyID Advanced GC CA 1", which tracks with the
diagram on Page 13.
* However, the fingerprints listed in the audit report differ from that
in the CP/CPS for the root CA
* E0:11:84:5E:34:DE:BE:88:81:B9:9C:F6:16:26:D1:96:1F:C3:B9:31 in the
audit
* E8 11 84 5E 34 DE BE 88 81 B9 9C F6 16 16 26 D1 96 1F C3 B9 31 in the
CP/CPS
* Note the two typos - E0 vs E8 and 26 vs 16. Which is correct?
* WISeKey CertifyID Advanced GC CA 1 is not disclosed in the CP/CPS


[1]
http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx
[2]
https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-CA-GC.pdf
[3] http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf
[4]
https://cdn.wisekey.com/uploads/images/Audit-Report-and-Management-Assertions-Webtrust-BR-GC.pdf
[5]
https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.10-CLEAN.pdf

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Wayne Thayer]

On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi <ry...@sleevi.com> 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.

[Pedro Fuentes]

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

[Pedro Fuentes]

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, should that be supported, or nonces, if that should
> unfortunately be supported [and it shouldn't])

****
Yes, we misunderstood this. I saw in the past that other CPS put here “No stipulation” so maybe I’ll do the same after studying this more carefully.
****

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

****
Thanks, I improved the CPS based in your comment. I moved that line to the extension group. The common name was set as optional, but I added the reference of matching one of the SAN.
****

>
> == 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 "Enhanced
> Key Usage"), so this should be corrected to include id-kp-serverAuth (and
> optionally id-kp-clientAuth)
> * 11.3.2 lists it under "Key Usages"

****
Yes, the EKU was missing for the Standard SSL (DV) section and and there were some formatting issues in the other tables that didn’t help to show this clearly. I solved these issues.
****

> * Annex B, 11.3.2 / 11.3.3 lists the Netscape Certificate Type as optional.
> There's no reasonable need to support this extension. Let's let it die :)

****
Yes, there’s no reason to keep this, as it’s been years we don’t use it. I removed it in the updated CPS
****

> * Annex E, 14.1.4 / 14.2.4, notes the use of "Any Other Method" for IP
> validation

****
Actually we never use any other method, so I removed it of the edited CPS.
****

>
> == Questions ==
> * I've confirmed that AUREN is a licensed WebTrust practitioner, as per
> [1]. When reviewing the audit report, I note that a WebTrust seal was not
> provided (which is not a requirement), but that may have masked other
> review items. In examining the report, [2], I noticed some deviations from
> the IASE 3000 illustrative reporting provided by WebTrust [3] for such
> reports, particularly IN1.1 (which is for WebTrust for CAs) in [3].

****
COMMENT FROM AUREN:
These reports were generated around the time of publication and adoption period of the new templates, being this is the reason of some possible deviations. Auren is already adopting the new models for newer reports.

COMMENT FROM WISEKEY:
We get the Webtrust seals for annual audits, but not for point-in-time or first 3-month period audits.
****

> * In the illustrative reports, it calls out being engaged in a reasonable
> assurance audit, while in the AUREN report, it states it has audited
> management's assertion. Is there significance in the deviation of language?

****
COMMENT FROM AUREN:
There are two types of reports, the “attestation engagement” and the “direct engagement”, as indicated in IN1.1 e IN 1.3 (http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf). Traditionally we always did the first one and it’s also the one that the rest of practitioners commonly adopt.
****

> * [2] does not list the location of the CA services, although [4], oddly
> enough, does. This is worth following up on.

****
COMMENT FROM AUREN:
This is related to the models used for each report, as the ones used previously for Webtrust 1.0 weren’t including this information.

COMMENT FROM WISEKEY:
Evidently, all operations for all Roots are done from the same site in Geneva, Switzerland. You’re invited to a Swiss cheese Fondue in the case you want to check out!
****

> * It notes that external RAs are used, but does not note that key escrow
> or certificate suspension are out of scope - meaning they are in scope.
> This is consistent with the CPS [5] in Section 4.9, which notes that
> non-SSL certificates may undergo suspension, and Section 4.12, which notes
> non-SSL end-entity certificates may undergo escrow.

****
COMMENT FROM AUREN:
This is also related to the model used for the reports, as this was not in previous versions. It’s confirmed that escrow was out of scope.

COMMENT FROM WISEKEY:
Regarding escrow... We left that open in the CPS, as it happened in the past that some technically constrained CAs that customers implemented with Microsoft Certificate Services implemented the native key escrow capability for encryption certificates and we allowed this for these customer-owned constrained CAs, but we, as WISeKey, we don’t provide escrow services to our certificate subscribers.

****

> * In listing auditor responsibilities, it explicitly notes that it did
> not test the operating effectiveness of these controls (Item 3 in the
> illustrative report, which is explicitly called out as out of scope in [2])

****
COMMENTS FROM AUREN:
This is an erratum coming from reusing the PiT report. Obviously all the tests on the controls were done, as we are providing our opinion on the period.
****

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

> * Similarly, comparing [4] with [3] produces some deviations for IN 2.1
> (which is for SSL BRs):
> * Like [2], it calls out that testing operating effectiveness was not
> part of the scope, in this case, entirely omitting (2) from IN 2.1 and
> modifying (3) to exclude testing.

****
COMMENTS FROM AUREN:
Same as above, this is related to the model used at the time of these reports. Newer reports are adapted to the new models.
****

> * The hierarchy within the reports calls out the "OISTE WISeKey Global Root
> GC CA", which is presumably the "OWGTM Root CA GC" mentioned in the CPS
> [5], and the "WISeKey CertifyID Advanced GC CA 1", which tracks with the
> diagram on Page 13.

*****
"OWGTM Root CA GC" is a short name for “OISTE WISeKey Global Root
GC CA”, as stated in the CPS
*****

> * However, the fingerprints listed in the audit report differ from that
> in the CP/CPS for the root CA
> * E0:11:84:5E:34:DE:BE:88:81:B9:9C:F6:16:26:D1:96:1F:C3:B9:31 in the
> audit
> * E8 11 84 5E 34 DE BE 88 81 B9 9C F6 16 16 26 D1 96 1F C3 B9 31 in the
> CP/CPS
> * Note the two typos - E0 vs E8 and 26 vs 16. Which is correct?

****
This was an unfortunate typo, thanks for catching this.

The fingerprint of the certificate uploaded to the Bugzilla post and appearing int he audit reports is the correct one

E0 11 84 5E 34 DE BE 88 81 B9 9C F6 16 26 D1 96 1F C3 B9 31

The one in the CPS had the typo and has been corrected.
****

> * WISeKey CertifyID Advanced GC CA 1 is not disclosed in the CP/CPS

****
As explained in Bugzilla, we don’t list the Issuing CAs in the CPS, but we reference https://www.wisekey.com/repository, were the updated list is maintained. Nevertheless, issuing CAs are always included in the audit reports.
****

[Ryan Sleevi]

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-secur...@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/logical distinction came up, and so it was brought ot mind
when reviewing.

I'm always a fan of stating the obvious ;)

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

Great! Reassuring.

> > * 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])

> ****
> Yes, we misunderstood this. I saw in the past that other CPS put here “No
> stipulation” so maybe I’ll do the same after studying this more carefully.
> ****
>

Yeah, I think most OCSP responders aren't using extensions widely. nonce is
one (and a bad one to support), and the only other one that tends to come
up in the WebPKI is CT (which is optional for CAs to support in OCSP
responses). No stipulation would work, if you don't make use of extensions.

> > * Annex E, 14.1.4 / 14.2.4, notes the use of "Any Other Method" for IP
> > validation

> ****
> Actually we never use any other method, so I removed it of the edited CPS.
> ****
>

Fantastic!

> > == Questions ==
> > * I've confirmed that AUREN is a licensed WebTrust practitioner, as per
> > [1]. When reviewing the audit report, I note that a WebTrust seal was not
> > provided (which is not a requirement), but that may have masked other
> > review items. In examining the report, [2], I noticed some deviations
> from
> > the IASE 3000 illustrative reporting provided by WebTrust [3] for such
> > reports, particularly IN1.1 (which is for WebTrust for CAs) in [3].

> ****
> COMMENT FROM AUREN:
> These reports were generated around the time of publication and adoption
> period of the new templates, being this is the reason of some possible
> deviations. Auren is already adopting the new models for newer reports.
>
> COMMENT FROM WISEKEY:
> We get the Webtrust seals for annual audits, but not for point-in-time or
> first 3-month period audits.
> ****
>

Thanks. That's a reasonable explanation - I know the illustrative reports
spent a lot of time coming, and came at different paces.

> > * In the illustrative reports, it calls out being engaged in a
> reasonable
> > assurance audit, while in the AUREN report, it states it has audited
> > management's assertion. Is there significance in the deviation of
> language?

> ****
> COMMENT FROM AUREN:
> There are two types of reports, the “attestation engagement” and the
> “direct engagement”, as indicated in IN1.1 e IN 1.3 (
> http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf).
> Traditionally we always did the first one and it’s also the one that the
> rest of practitioners commonly adopt.
> ****
>

Understood. And understanding the type of engagement was part of why I
raised it - wanted to make sure I properly understood the type of audit.

>
> > * [2] does not list the location of the CA services, although [4],
> oddly
> > enough, does. This is worth following up on.

> ****
> COMMENT FROM AUREN:
> This is related to the models used for each report, as the ones used
> previously for Webtrust 1.0 weren’t including this information.
>
> COMMENT FROM WISEKEY:
> Evidently, all operations for all Roots are done from the same site in
> Geneva, Switzerland. You’re invited to a Swiss cheese Fondue in the case
> you want to check out!
> ****
>

The big concern here is making sure that it's plainly stated in the
management assertion and report. For example, we don't want a CA with a
copy of the key material in their evil secret bunker, and which spins out
MITM certs, to be considered out of scope for the audit :)

For example, some CAs present separate audit reports for different physical
locations, and when we see something like that, it's a lot more work -
hence why it's desirable to make sure locations are listed, so we know what
the auditor (and management) are attesting to.

>
> > * It notes that external RAs are used, but does not note that key
> escrow
> > or certificate suspension are out of scope - meaning they are in scope.
> > This is consistent with the CPS [5] in Section 4.9, which notes that
> > non-SSL certificates may undergo suspension, and Section 4.12, which
> notes
> > non-SSL end-entity certificates may undergo escrow.

> ****
> COMMENT FROM AUREN:
> This is also related to the model used for the reports, as this was not in
> previous versions. It’s confirmed that escrow was out of scope.
>
> COMMENT FROM WISEKEY:
> Regarding escrow... We left that open in the CPS, as it happened in the
> past that some technically constrained CAs that customers implemented with
> Microsoft Certificate Services implemented the native key escrow capability
> for encryption certificates and we allowed this for these customer-owned
> constrained CAs, but we, as WISeKey, we don’t provide escrow services to
> our certificate subscribers.
> ****
>

Thanks for clarifying. Indeed, the CP/CPS made it clear that this was not
applicable to the SSL case, which is exactly what we want to see. Sorry,
this was more a statement of my examination than a question - it's a thing
that would normally raise eyebrows (escrow and suspension), included in the
scope of an audit - but the CP/CPS detailed that it does not apply to the
SSL/TLS case.

> > * In listing auditor responsibilities, it explicitly notes that it did
> > not test the operating effectiveness of these controls (Item 3 in the
> > illustrative report, which is explicitly called out as out of scope in
> [2])

> ****
> COMMENTS FROM AUREN:
> This is an erratum coming from reusing the PiT report. Obviously all the
> tests on the controls were done, as we are providing our opinion on the
> period.
> ****
>

Our default is to assume all omissions are material and intentional (... as
they have been by some CAs in the past), which is why I flagged. Is it
possible to reissue the report to ensure this is clearly stated as such,
since it sounds like AUREN did include these activities in scope of their
engagement.

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

> > * WISeKey CertifyID Advanced GC CA 1 is not disclosed in the CP/CPS

> ****
> As explained in Bugzilla, we don’t list the Issuing CAs in the CPS, but we
> reference https://www.wisekey.com/repository, were the updated list is
> maintained. Nevertheless, issuing CAs are always included in the audit
> reports.
> ****
>

Thanks, I had not reviewed the Bugzilla entry.

[Pedro Fuentes]

Thanks a lot, Ryan.

I see there's still an open concern, so I'll add a first comment to it.

>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

[Pedro Fuentes]

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

[Pedro Fuentes]

Kind reminder.
Thanks!

[Ryan Sleevi]

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-secur...@lists.mozilla.org> wrote:

> Kind reminder.
> Thanks!

[Pedro Fuentes]

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

[Ryan Sleevi]

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-secur...@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ó:

[Pedro Fuentes]

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

[Ryan Sleevi]

On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy <
dev-secur...@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.

[Wayne Thayer]

On Mon, Jun 25, 2018 at 2:45 PM Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy <
> dev-secur...@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

[Pedro Fuentes]

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

[Ryan Sleevi]

On Mon, Jun 25, 2018 at 5:12 PM, Pedro Fuentes via dev-security-policy <
dev-secur...@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.

[Pedro Fuentes]

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

[Ryan Sleevi]

On Tue, Jun 26, 2018 at 4:29 PM, Pedro Fuentes via dev-security-policy <
dev-secur...@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 :)

[Pedro Fuentes]

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

[Wayne Thayer]

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

[Pedro Fuentes]

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

[Pedro Fuentes]

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

[Pedro Fuentes]

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

[Wayne Thayer]

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

[Wayne Thayer]

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 <ry...@sleevi.com> wrote:

> Sorry for the delay in responding. I think this resolves the ambiguity as
> to the gaps and is a good path forward.