Dear all,
As a reminder... WISeKey has three Roots "GA" (Generation A), GB and GC. GA and
GB are already included and covered by annual audits. GC is the new one, only
included by now by Microsoft.
I got some inputs from the auditors, that I add here:
"For the next annual audit, covering the period starting the 3rd of June 2017,
it was already planned that it would consolidate the three Roots and
hierarchies, even if this implies an overlapping period with the point-in-time
and 3-month period audit for the new GC Root.
Nevertheless, if there’s a concern on the period after the GC Root was created
(25th of May), it would be possible to adapt the period of the consolidated
audit to start that day, so doing it from 25th May 2017 to 24th May 2018."
Therefore, I'd appreciate if you analyze the auditor's comment and state your
position in front of this perceived issue.
Said that, I'd like to point out this personal comment... According to BR-8.1:
"If the CA does not have a currently valid Audit Report indicating compliance
with one of the audit schemes listed in Section 8.1, then, before issuing
Publicly-Trusted Certificates, the CA SHALL successfully complete a
point-in-time readiness assessment performed in accordance with applicable
standards under one of the audit schemes listed in Section 8.1. The
point-in-time readiness assessment SHALL be completed no earlier than twelve
(12) months prior to issuing Publicly-Trusted Certificates and SHALL be
followed by a complete audit under such scheme within ninety (90) days of
issuing the first Publicly-Trusted Certificate."
For this new GC Root we did a Point-in-time, and I'd say that a PiT for BR can
only be dated once there's capability to issue SSL, and after the PiT, we did
the 3-month subsequent audit... I would dare to say that all this seems in line
of BR.
But, as already said, please kindly state your opinion and we'll dutifully do
whatever is required.
Thanks and regards,
Pedro
El viernes, 25 de mayo de 2018, 11:57:16 (UTC+2), Pedro Fuentes escribió:
> Thanks a lot, Ryan.
>
> I see there's still an open concern, so I'll add a first comment to it.
>
> > > > * As noted, the key generation was performed in May, and this audit is a
> > > > period of time audit beginning in September. This does mean that there
> > > is a
> > > > gap in the audit coverage - from May through September - that's
> > > > difficult
> > > > to reason about. Are there any other supporting documents that would
> > > > help
> > > > assuage these concerns?
> > >
> > > COMMENTS FROM WISEKEY:
> > > We had a pause period between the Root CA Ceremony and the creation of a
> > > first issuing CA, so actually there weren't operations to audit.
> > > That’s the reason of the “gap”, as the Root didn’t issue any certificate
> > > and was just left deactivated, so the first period audit started with the
> > > effective start of operations and verified a first three-month period
> > > after
> > > this start of operations, during which we only issued a few test
> > > certificates.
> > >
> > >
> >
> > So, one area that we've discussed with WebTrust about this is the Root Key
> > Generation Ceremony Report (IN5.1 from the Illustrative reports), along
> > with reporting on the CP/CPS that governs that key and its physical
> > protections, and then on to actual operations.
> >
> > The goal here is roughly: How, as a community, do we make sure that when it
> > was left deactivated, it wasn't just left under someone's desk with no key
> > protections, and which might have signed things that come back to bite us
> > later? We've seen CAs in the past fail to maintain physical access logs,
> > for example, and thus there's no way anyone can be really sure what
> > happened to or with that key material.
> >
> > There is the challenge that you mention - which is how do you opine on
> > operations when it's just sitting unused - but there are still controls in
> > place (such as physical security, auditing, access controls) that
> > presumably are being practiced.
> >
> > I'm a bit uncertain on how best to proceed here on this. I'd like to seek
> > feedback and understanding from our WebTrust & CPA Canada colleagues about
> > how, procedurally, this is handled - as this has been a topic of discussion
> > for several years, and we've heard several statements about what the
> > expectations are for situations like this.
> >
>
> >From my humble perspective I didn't find the issue, as this is not a new
> >Root coming out of the blue, but a Root added to an existing (and included
> >in CCADB) set of roots and a consolidated PKI covered by a single CPS. This
> >means that all CA are managed immediately after the Ceremony under the same
> >existing Trust Model, security policies, procedures, team, datacenter, etc.
>
> I also see the "deactivated" status as the one that should be naturally
> expected for an offline Root CA during the 99.9% of its life-time, so
> a
