SECOM inclusion request and PWC audit
Stephen Schultze
inclusion request should wait, pending discussion of
PriceWaterhouseCooper's acceptability as an auditor and Brian's
suggestion that inclusion requests be postponed until we finish
reconsidering our inclusion criteria:
Kathleen Wilson
SECOM's request is a root refresh request that we fully discussed in
June and July, and approved for inclusion in August:
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/a0612ccafb2e84ff#
https://bugzilla.mozilla.org/show_bug.cgi?id=527419#c26
SECOM has always been responsive, including during the recent CA
Communication.
I see no reason why this SECOM request should not continue with our
current process.
The issue that Stephen cites in the bug is that we still need more
information about how the ETSI audit failed to find the network security
issues for DigiNotar.
Note that the audit criteria that was used for SECOM was WebTrust CA and
WebTrust EV.
Stephen's issue is that it was the same auditor, PWC.
Note that it was the PWC auditors in Amsterdam who had performed the
audit for DigiNotar against the ETSI audit criteria. For SECOM the PWC
auditors are in Japan, and they used the WebTrust CA and EV criteria.
Different auditors, different audit criteria.
Anyways, I think that the discussion regarding what to do about audits
and auditors belongs in m.d.s.policy and not in the root inclusion bug
for SECOM.
Kathleen
ianG
> I see no reason why this SECOM request should not continue with our
> current process.
+1
Stephen Schultze
> On 10/10/11 1:02 PM, Stephen Schultze wrote:
>> Over in bug 680979, Kathleen suggested we discuss here whether the SECOM
>> inclusion request should wait, pending discussion of
>> PriceWaterhouseCooper's acceptability as an auditor and Brian's
>> suggestion that inclusion requests be postponed until we finish
>> reconsidering our inclusion criteria:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=680979#c7
>
> SECOM's request is a root refresh request that we fully discussed in
> June and July, and approved for inclusion in August:
>
> http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/a0612ccafb2e84ff#
....which was before the DigiNotar "incident" and the subsequent doubt
that was cast on PWC as an auditor.
> https://bugzilla.mozilla.org/show_bug.cgi?id=527419#c26
>
> SECOM has always been responsive, including during the recent CA
> Communication.
Which is to be commended, but irrelevant to the question of whether
their auditor is a "competent independent party".
> I see no reason why this SECOM request should not continue with our
> current process.
>
> The issue that Stephen cites in the bug is that we still need more
> information about how the ETSI audit failed to find the network security
> issues for DigiNotar.
>
> Note that the audit criteria that was used for SECOM was WebTrust CA and
> WebTrust EV.
>
> Stephen's issue is that it was the same auditor, PWC.
>
> Note that it was the PWC auditors in Amsterdam who had performed the
> audit for DigiNotar against the ETSI audit criteria. For SECOM the PWC
> auditors are in Japan, and they used the WebTrust CA and EV criteria.
> Different auditors, different audit criteria.
So, what is the precise set of criteria that must be met for the "TBD"
status of PWC to actually affect the validity of an audit that is being
considered as part of root inclusion? An ETSI audit taking place in
Amsterdam by the same individual auditors? Must they all be the same or
can there be one member of the audit team that is different?
If it is so easy to exempt a subset of auditors within a particular
auditing company, what motivation do those companies have to prevent and
deal with shortcomings?
Kathleen Wilson
> So, what is the precise set of criteria that must be met for the "TBD"
> status of PWC to actually affect the validity of an audit that is being
> considered as part of root inclusion? An ETSI audit taking place in
> Amsterdam by the same individual auditors? Must they all be the same or
> can there be one member of the audit team that is different?
>
We are still investigating this, but we do not currently have proof that
PWC's Amsterdam office was negligent in their audit.
We don't have answers yet, but indications are that we need to re-look
at the ETSI criteria.
Kathleen
Erwann Abalea
[...]
> PWC's Amsterdam office was negligent in their audit.
field (bets and cardplaying games), on the vault side. Reading the
Spain regulation, requirements, and specifications is somewhat funny,
the associated security is ridiculous. The scheme was either proposed
or validated by PWC. Therefore, I don't trust PWC anymore.
--
Erwann.
ianG
> ....which was before the DigiNotar "incident" and the subsequent doubt
> that was cast on PWC as an auditor.
The question over DigiNotar's audit looks to me like doubt exists in
many places:
* audit as a methodology for asserting some facts we rely on
* our ability to read and understand audit reports
* The audit reports says it in black and white, and we never bothered
to look
* our expectations as to whether audit does something which it does not
* PWC's Amsterdam office, or PWC all over
* instructions from the regulator of CAs in NL (it's a QC issuer, so
see the Signing Directive in Dutch law)
* The criteria used
* The letter of engagement
* DigitNotar tricked the auditor
* DigiNotar were asked by Auditor to fix something and never quite
got there
* Everything was properly covered in systems and audit, but it just
went wrong on the day...
Out of that, while it may feel good to blame the auditor, I'm not sure
that is helpful. Also, I'm pretty sure they know more about it than us
... And knowing how it all works, I'd expect them to be teflon-coated.
Does anyone have a link to the audit reports?
On the other hand, the CAs and the auditors are going to say nothing
here. So either we lop off a few heads, or we all go home. If we can't
get disclosure, we can't see the sub-CAs, we can't get changes, we can't
see liability, and we can't even get a conversation, what are we doing here?
iang
Peter Gutmann
>If we can't get disclosure, we can't see the sub-CAs, we can't get changes,
>we can't see liability, and we can't even get a conversation, what are we
>doing here?
I'm here pretty much entirely for the amusement value really. Dunno about
others...
Peter :-).
Kathleen Wilson
The 2011 audit for SECOM was performed by Deloitte Touche Tohmatsu LLC,
and is available here (in both Japanese and English):
https://cert.webtrust.org/ViewSeal?id=1214
People keep posting comments in the SECOM root inclusion bug to say that
we should wait before adding this root.
https://bugzilla.mozilla.org/show_bug.cgi?id=680979
This particular request is to add the SHA256 version of the Security
Communication RootCA1 (SHA1) root certificate that is currently in NSS.
As I stated before, I see no reason why we would wait to add a refresh
root that has already gone through all of our inclusion discussion and
approval process. We should be encouraging our existing CAs to refresh
their root certificates.
All new and existing CAs should be held to the same policies that are
published in Mozilla's CA Certificate Policy, and the practices that are
documented in our wiki pages (https://wiki.mozilla.org/CA).
When Mozilla's CA Certificate Policy is updated, then we will send a
communication to all of the CAs with roots in NSS, and give them a
certain amount of time to comply with the changes.
Likewise, if we determine that a certain auditor or audit type is
insufficient, then we will need to communicate that to all of the CAs
with roots in NSS, and give them a certain amount of time to get updated
audits.
Kathleen
Eddy Nigg
> This particular request is to add the SHA256 version of the Security
> Communication RootCA1 (SHA1) root certificate that is currently in NSS.
>
> As I stated before, I see no reason why we would wait to add a refresh
> root that has already gone through all of our inclusion discussion and
> approval process. We should be encouraging our existing CAs to refresh
> their root certificates.
>
Yes, it's in the interest of Mozilla and the CA in this particular case
to add the SHA2 roots in favor of the SHA1 . Also there is probably not
much to discuss since the root is already included.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Jean-Marc Desperrier
>[...]
> All new and existing CAs should be held to the same policies that are
> published in Mozilla's CA Certificate Policy, and the practices that are
> documented in our wiki pages (https://wiki.mozilla.org/CA).
Yes, there's no security reason to hold newly coming CA to higher
requirement level than the one that are already in the list, as long as
the new requirements *will* be applied to all CAs including those
already accepted (and *not* wait until renewal phases out all already
included CAs, which would take forever).
Let's go forward, we're punishing everybody for no sensible reason.
BTW it would be good to try to push further for more people to review CA
inclusion requests, including those who are impatiently waiting for
their own to be examined, and who don't seem to get the message
including the fact they will learn a lot about the process and be able
to go through it faster.