SwissSign root CA certificate inclusion request
Frank Hecker
root store, as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=343756
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#SwissSign
I have evaluated their request, as per the mozilla.org CA certificate
policy:
http://www.mozilla.org/projects/security/certs/policy/
and plan to approve this request in two weeks time. If you have any
objections, or know of facts which might influence this decision, please
make them known before then.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg (StartCom Ltd.)
Could you please be so kind and provide me with the a URL or document of
the audit attestation of KPMG and what exactly it entails including
under which criteria the CA was audited?
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Frank Hecker
> Could you please be so kind and provide me with the a URL or document of
> the audit attestation of KPMG and what exactly it entails including
> under which criteria the CA was audited?
The criteria were ETSI TS 101.456, as I believe I mentioned in the bug
report. The public URLs confirming completion of the audit are listed in
SwissSign's entry in the pending list, in the summary section; they're
the links for "Swiss Accreditation Service" and "SAS details":
http://www.seco.admin.ch/sas/00229/00251/index.html?lang=en
http://www.seco.admin.ch/sas/00229/00251/00281/index.html?lang=en
As I understand it KPMG does these audits on behalf of SAS, which is a
Swiss government agency, and then SAS publishes the list of CAs that are
thus accredited under Swiss law.
I don't believe that SAS publishes a document comparable to the WebTrust
for CAs "auditors' report on management assertions" (or whatever it's
called). However you can ask Melanie Raemy of SwissSign about that; just
post a comment in bug 343756 and she should see it.
Eddy Nigg (StartCom Ltd.)
I've visited that page you are pointing me obviously. However this page
also says:
"The standards ETSI TS 101.456 (Europe) and ANSI X9.79 (USA, Canada)
*may* also serve *as a basis* for the certification of a Public Key
Infrastructure (PKI) respectively a Certification Service Provider (CSP)."
I would be interested to know which criteria was used by the auditor for
auditing this CA before studying the "Bundesgesetz über die
elektronische Signatur (ZertES)" more in detail.
--
Frank Hecker
> I've visited that page you are pointing me obviously. However this page
> also says:
>
> "The standards ETSI TS 101.456 (Europe) and ANSI X9.79 (USA, Canada)
> *may* also serve *as a basis* for the certification of a Public Key
> Infrastructure (PKI) respectively a Certification Service Provider (CSP)."
>
> I would be interested to know which criteria was used by the auditor for
> auditing this CA before studying the "Bundesgesetz über die
> elektronische Signatur (ZertES)" more in detail.
The "Details SwissSignAG" page seems pretty clear that ETSI TS 101.456
was (one of) the criteria used in the audit. I'm confused by your
question: Is your concern that SAS/KPMG used a variant of ETSI TS
101.456, or a subset of it, or some other practice that did not actually
amount to an audit according to the ETSI TS 101.456 criteria?
Eddy Nigg (StartCom Ltd.)
Frank Hecker wrote:
>
> The "Details SwissSignAG" page seems pretty clear that ETSI TS 101.456
> was (one of) the criteria used in the audit.
Yes, I saw that under Certification Service Provider (CSP)...so if I
understand you correctly, the standards listed under this section were
the requirements used for the audit. In that case it's most likely that
they do have a document confirming that by KPMG (actually I'd be very
surprised if not)
> I'm confused by your
> question: Is your concern that SAS/KPMG used a variant of ETSI TS
> 101.456, or a subset of it, or some other practice that did not actually
> amount to an audit according to the ETSI TS 101.456 criteria?
>
Yes, the later would be my concern (ETSI TS 101.456 as the relevant
criteria according to the Mozilla CA policy as opposed to "ZertES" as
the criteria).
Frank Hecker
> understand you correctly, the standards listed under this section were
> the requirements used for the audit. In that case it's most likely that
> they do have a document confirming that by KPMG (actually I'd be very
> surprised if not)
I'll ask Melanie Raemy about this.
> Yes, the later would be my concern (ETSI TS 101.456 as the relevant
> criteria according to the Mozilla CA policy as opposed to "ZertES" as
> the criteria).
From our point of view it would be perfectly fine if the audit criteria
encompassed both ETSI TS 101.456 and ZertES, as long as the requirements
of ETSI TS 101.456 were satisfied.
Eddy Nigg (StartCom Ltd.)
>> Yes, the later would be my concern (ETSI TS 101.456 as the relevant
>> criteria according to the Mozilla CA policy as opposed to "ZertES" as
>> the criteria).
>>
>
> From our point of view it would be perfectly fine if the audit criteria
> encompassed both ETSI TS 101.456 and ZertES, as long as the requirements
> of ETSI TS 101.456 were satisfied.
Eddy Nigg (StartCom Ltd.)
http://repository.swisssign.com/ and currently have a question
concerning domain ownership validation (or relevant authorization
rights) of the Gold and Sliver server certificates issued by SwissSign
which would satisfy the Mozilla CA policy requirement outlined in
section 7. Maybe I missed it somewhere and somebody (Frank?) already
knows the answer and can point me to the relevant section... Else I'll
ask perhaps for more information at the bug directly.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Frank Hecker
> http://repository.swisssign.com/ and currently have a question
> concerning domain ownership validation (or relevant authorization
> rights) of the Gold and Sliver server certificates issued by SwissSign
> which would satisfy the Mozilla CA policy requirement outlined in
> section 7. Maybe I missed it somewhere and somebody (Frank?) already
> knows the answer and can point me to the relevant section...
Section 3.2.2 of the Gold CPS includes the following:
"/DC= fields will only be accepted if a printout of the WHOIS entry for
the domain is included. The owner of the domain must approve the
request with a handwritten personal signature in the appropriate
position on the registration form and provide information as to his
identity. The RA will create a high-quality copy or scan of all required
supporting documentation. SwissSign validates that the person enrolling
for the certificate has control of the domain by requiring the
person to respond to an e-mail hosted at that domain."
So, as I read it, they determine the ostensible owner of the domain
based on WHOIS data, then do an identity check to verify that the
certificate applicant is that person. Plus they do the email check.
If you have further questions please feel free to ask them in the bug; I
think Melanie Raemy of SwissSign is following the bug traffic but not
the newsgroup discussion.
Eddy Nigg (StartCom Ltd.)
to follow up first of all here...
First of all I realized that Gerv was already up to this issue in the
bug itself but didn't follow through entirely...Please see what I found
out, possibly correcting me if I'm wrong. There are currently two
separate issues which require clarification:
1.)
The DC fields are not relevant for server certificates (browsers).
It's the CN field which matters...Now according to Melanies comment
at https://bugzilla.mozilla.org/show_bug.cgi?id=343756#c14 she mentions:
"/DC= fields will only be accepted if a printout of the WHOIS entry
for the domain is included." (also part of 3.2.2)
So if the printout wasn't provided the DC fields are being omitted
which doesn't have any effect on the browser which checks the CN
field. Whats also interesting is, why does the subscriber has to
provide the WHOIS records print instead of the CA fetching them by
themselfes as a third party information source? (The later just a
minor curiosity)
Now also in the Gold CP/CPS under section 3.2.2 Authentication of
organization identity it says:
"SwissSign validates that the person enrolling for the certificate
has control of the domain by requiring the
person to respond to an e-mail hosted at that domain."
However according to this statement this can be *any* email address...
2.)
The Silver CP/CPS omits any reference to domain ownership or
verification at all! Going through the entire document there is no
actual reference to server certificates (or whois/domain checks and
validations), but under
http://www.mozilla.org/projects/security/certs/pending/#SwissSign
they seem to request also server certificates trust bits set.
Again, I might have missed something here...if not I suggest that you or
me ask about clarification at the bug.
Nelson Bolyard
A policy question (or policy administration question):
Does Mozilla accept documents, *received from the applicants* (the CAs),
that purport to be true copies of auditor's attestation documents, as
being true copies of such documents, without any further proof?
That question applies to both
a) paper copies received from the applicants, and
b) electronic copies received by email or bugzilla from the applicants.
Is a PDF file, received from a CA applicant, that purports to be a
scanned-in copy of a signed paper letter on letterhead from an auditor,
attesting that the applicant CA has passed an audit to specific criteria,
accepted as valid on its face?
Nelson Bolyard
Eddy, please ask exactly those questions in the bug.
Frank Hecker
> Does Mozilla accept documents, *received from the applicants* (the CAs),
> that purport to be true copies of auditor's attestation documents, as
> being true copies of such documents, without any further proof?
I don't think we've ever formulated a formal policy on this issue one
way or another. In this case the document in question (i.e., SwissSign's
certificate from KPMG) is IMO simply supporting documentation for
information already available from an independent source (i.e., SAS), so
I am not as concerned about this issue as I otherwise might be.
However the certificate lists the names of two KPMG employees (Reto
Grubenmann and Alain Beuchat), and Mr. Grubenmann's contact information
is available on the kpmg.ch web site. I've therefore sent him a note and
asked him to confirm that this is indeed a genuine KPMG document.
I think a similar procedure of independent confirmation is worth doing
in other cases where CAs provide documents like this, especially if the
document in question is the sole or primary source of information we
have relating to independent audits and evaluations.
Eddy Nigg (StartCom Ltd.)
relevant documents would solve this issue entirely. In the meantime I
suggest for to always attach the audit papers to the bug.
Concerning the document SwissSign provided I think it's genuine,
confirms the criterion's used and is signed by seal and names of the
auditors. I also uploaded it to the bug for future reference.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Eddy Nigg (StartCom Ltd.)
No further comments have been posted until now, so I went ahead and
posted a few questions at the bug (Comment
https://bugzilla.mozilla.org/show_bug.cgi?id=343756#c44 )
Nelson Bolyard
> Nelson Bolyard wrote:
>> Does Mozilla accept documents, *received from the applicants* (the CAs),
>> that purport to be true copies of auditor's attestation documents, as
>> being true copies of such documents, without any further proof?
>
> I don't think we've ever formulated a formal policy on this issue one
> way or another. In this case the document in question (i.e., SwissSign's
> certificate from KPMG) is IMO simply supporting documentation for
> information already available from an independent source (i.e., SAS),
OK, I had not ascertained that there was independent confirmation from the
info in the bug report.
> so I am not as concerned about this issue as I otherwise might be.
I agree. Thanks for the info that independent confirmation exists.
> I think a similar procedure of independent confirmation is worth doing
> in other cases where CAs provide documents like this, especially if the
> document in question is the sole or primary source of information we
> have relating to independent audits and evaluations.
I think there should be a policy about this. There should be something in
writing that requires that more proof be supplied than documents available
exclusively from the applicant, IMO.
Nelson Bolyard
> relevant documents would solve this issue entirely. In the meantime I
> suggest for to always attach the audit papers to the bug.
> Concerning the document SwissSign provided I think it's genuine,
> confirms the criterion's used and is signed by seal and names of the
> auditors. I also uploaded it to the bug for future reference.
With the scanned copy of the document in hand, I could now produce a
forgery showing that that same auditor had certified *ME* as having
passed the audit. It would appear to have the same seal, same
letterhead, etc. Or I could forge a certificate for Mickey Mouse!
Of course, checking with the auditor to confirm the veracity of the
document would disprove it. My point is that some sort of checking or
confirmation from the auditor MUST be required, except in cases where
the document's authenticity and origin are provable (e.g. if the document
is digitally signed with a cert that traces up to a CA not under the
applicant's control).
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> The change I proposed concerning CA applications and submission of the
>> relevant documents would solve this issue entirely. In the meantime I
>> suggest for to always attach the audit papers to the bug.
>> Concerning the document SwissSign provided I think it's genuine,
>> confirms the criterion's used and is signed by seal and names of the
>> auditors. I also uploaded it to the bug for future reference.
>>
>
> With the scanned copy of the document in hand, I could now produce a
> forgery showing that that same auditor had certified *ME* as having
> passed the audit. It would appear to have the same seal, same
> letterhead, etc. Or I could forge a certificate for Mickey Mouse!
>
in court against whoever did the forgery...
> Of course, checking with the auditor to confirm the veracity of the
> document would disprove it. My point is that some sort of checking or
> confirmation from the auditor MUST be required, except in cases where
> the document's authenticity and origin are provable (e.g. if the document
> is digitally signed with a cert that traces up to a CA not under the
> applicant's control).
>
Eddy Nigg (StartCom Ltd.)
https://bugzilla.mozilla.org/show_bug.cgi?id=343756#c45 answers and
clarifies the questions and issues which I raised. SwissSign intend to
reformulated the relevant parts of their CP/CPS to make it clearer next
time...
Frank Hecker
I posted the above on November 15, so this is the last day of the two
week public comment period. Based on comments in this forum and in bug
343756, it appears that the concerns and issues raised by various people
(Eddy, Nelson, et.al.) have been addressed, and are not at this point
impediments to final approval of SwissSign.
Therefore absent objection tomorrow (Friday November 30) I am going to
officially approve inclusion of the three SwissSign root CA
certificates, and proceed with the other steps needed to get the certs
into NSS.
Frank Hecker
> Therefore absent objection tomorrow (Friday November 30) I am going to
> officially approve inclusion of the three SwissSign root CA
> certificates, and proceed with the other steps needed to get the certs
> into NSS.
Well, I was a week late, for which I apologize. My approval is now
final, and I've submitted a bug to add the three SwissSign root CA
certificates to NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=407396