Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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 

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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

[Pedro Fuentes via dev-security-policy]

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 
> 

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

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 

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Pedro Fuentes via dev-security-policy]

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, 

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Pedro Fuentes via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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 

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

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=cablint,zlint,x509lint=2010-01-01
> Two notable concerns are:
> ** Valid wildcard certificate for a public suffix:
> https://crt.sh/?id=76535370=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=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

[Wayne Thayer via dev-security-policy]

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=cablint,zlint,x509lint=2010-01-01
Two notable concerns are:
** Valid wildcard certificate for a public suffix:
https://crt.sh/?id=76535370=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=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