Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

GlobalSign SubCA-audits

1 view
Skip to first unread message

Thorsten Becker

unread,
Aug 26, 2008, 6:24:39 AM8/26/08
to
In Bug #378882 Eddy Nigg directed me here because of a SubCA audit
question: He states that root CAs in mozilla NSS must "Not circumvent
the audit requirement set forth by the Mozilla CA policy.
This means that the CAs which belong to this PKI and are under this root
MUST
be part of the audit. CAs themselves can't be the auditors, otherwise
all CAs
will audit themselves."

That was an answer to a questions to the requirements to T-Systems to
get their root accepted. I compared the practices of T-Systems to that
of GlobalSign, that offer a service to Enterprise CAs that allows the
Enterprise CAs to operate as SubCAs indepependently under the root of
GlobalSign:
http://eu.globalsign.com/pki/rootsign.htm

According to the Info-Gathering-Document in Bug #406794, which covers
the renewal of the GlobalSign root, GlobalSign does just do what they
shouldn't do according to Eddys comment: They audit external SubCAs
themselves, as stated in the bug/info-gathering-document:
"[...] As a CA is then run by an enterprise, domains are not technically
restricted, however domains are contractually restricted.

*GlobalSign* audits periodically as part of our own brand protection
program. [...]" [Emphasis added]

So isn't GlobalSign doing something here that is very problematic?

Thorsten

Eddy Nigg

unread,
Aug 26, 2008, 7:54:21 AM8/26/08
to
Thorsten Becker:

Hi Thorsten,

Let me add a few things here in order to make it clear what I meant:

The Mozilla CA policy requires auditing of the CA and its
infrastructure. In the past there were various requests from CAs which
don't issue themselves end user certificates, but issue (sub) CA
certificates to entities external to them, both physical, logical and
legal. Those CAs were not included if the audit didn't cover the issuing
CAs for the obvious reason, that otherwise CAs acting as roots for the
sole purpose of issuing CA certificates to others and therefore by
transferring the responsibilities to third parties would circumvent the
audit requirement. The audit requirement is not a privilege, but a
condition.

Now, to all of my knowledge, this condition has been applied at other
inclusion and upgrade requests, most notably with Comodo just recently.
CAs may issue subordinated CA certificates to third parties on a
contractual basis, however the audit must cover those. This is made
clear usually in the CP/CPS of the CA in such a way and the auditor has
to confirm that.

As a matter of fact, the auditor confirms the CA/CPS of the CA and if
your CA policy doesn't have any requirements to the third parties, then
the auditor doesn't have to confirm it either. It would be then very
easy to found a "straw-CA" which conforms to its own policy and have
that confirmed by the auditor, but the actual issuing CAs wouldn't have
any requirements whatsoever. Effectively the issuing CAs would never see
an auditor anywhere near them, nor would the controls (if any) and
issuing procedures be ever confirmed by a third party. This goes counter
to the audit requirement of the Mozilla CA policy.

Concerning GlobalSign this problematic practice has been highlighted by
Frank here: https://bugzilla.mozilla.org/show_bug.cgi?id=406794#c19

I don't remember the discussion of GlobalSign's request explicitly, but
the entry at the pending page [1] states:

"The first root has two subordinate CAs (for domain-validated and
organizationally-validated certificates respectively) and the second
root has one subordinate CA (for extended validation certificates).
(There is also a valid chain from the EV subordinate to the first root
via a cross-signing certificate.)"

Apparently GlobalSign either doesn't have any externally operated CAs or
they were part of the scope of the audit. In addition to that, this CA
has been included previously and the request was to enable EV and
replace the already included certificate with the same key, but longer
life-time of the certificate. Most likely Frank can recall the
considerations for approving this request.

[1] http://www.mozilla.org/projects/security/certs/pending/#GlobalSign

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org

Thorsten Becker

unread,
Aug 26, 2008, 8:41:43 AM8/26/08
to
Eddy,

thanks for your elaborate answer. I have only a few questions (I'm still
learning... ;-) )

Eddy Nigg schrieb:


>
> Let me add a few things here in order to make it clear what I meant:
>
> The Mozilla CA policy requires auditing of the CA and its
> infrastructure. In the past there were various requests from CAs which
> don't issue themselves end user certificates, but issue (sub) CA
> certificates to entities external to them, both physical, logical and
> legal. Those CAs were not included if the audit didn't cover the issuing
> CAs for the obvious reason, that otherwise CAs acting as roots for the
> sole purpose of issuing CA certificates to others and therefore by
> transferring the responsibilities to third parties would circumvent the
> audit requirement.

Can we say that it is neccessary (but not sufficient) to get included if
you have "independent" sub-CAs that they are linked logically and
legally to your root in a "sufficient" manner? Entities that are
physically external seem to be quite common (Enterprise CAs)

> The audit requirement is not a privilege, but a
> condition.

I agree with that. The Mozilla CA Certificate Policy is clear on that point.

> Now, to all of my knowledge, this condition has been applied at other
> inclusion and upgrade requests, most notably with Comodo just recently.
> CAs may issue subordinated CA certificates to third parties on a
> contractual basis, however the audit must cover those. This is made
> clear usually in the CP/CPS of the CA in such a way and the auditor has
> to confirm that.

So it has to be explicitly stated in the audit report, or is it
sufficient that it is covered in the CP/CPS and the auditor raises no
objections?

> As a matter of fact, the auditor confirms the CA/CPS of the CA and if
> your CA policy doesn't have any requirements to the third parties, then
> the auditor doesn't have to confirm it either. It would be then very
> easy to found a "straw-CA" which conforms to its own policy and have
> that confirmed by the auditor, but the actual issuing CAs wouldn't have
> any requirements whatsoever. Effectively the issuing CAs would never see
> an auditor anywhere near them, nor would the controls (if any) and
> issuing procedures be ever confirmed by a third party. This goes counter
> to the audit requirement of the Mozilla CA policy.

I agree with that, previously I thought: The auditor also monitors the
operations of the root CA - not only the documents that describe how the
operations are carried out, i.e. CP and CPS. During such an audit the
presence of external sub-CAs would appall to the auditor, and he would
object if this is considered wrong/dangerous.
But I completely get your point that there is no ambiguity on that point
if the external sub CAs are dealt with in the CP/CPS. (And ambiguity is
not a good thing for trust...)

> Concerning GlobalSign this problematic practice has been highlighted by
> Frank here: https://bugzilla.mozilla.org/show_bug.cgi?id=406794#c19
>
> I don't remember the discussion of GlobalSign's request explicitly, but
> the entry at the pending page [1] states:
>
> "The first root has two subordinate CAs (for domain-validated and
> organizationally-validated certificates respectively) and the second
> root has one subordinate CA (for extended validation certificates).
> (There is also a valid chain from the EV subordinate to the first root
> via a cross-signing certificate.)"
>
> Apparently GlobalSign either doesn't have any externally operated CAs or
> they were part of the scope of the audit.

GlobalSign offers a product that lets you operate your CA externally
under one of their roots, so I guess these Sub CAs exist but are not
linked directly to the root CA in question but are in fact subordinate
root CAs further down the certificate chain. There seems to be no limit
to the length of the certificate chain.

In addition to that, this CA
> has been included previously and the request was to enable EV and
> replace the already included certificate with the same key, but longer
> life-time of the certificate. Most likely Frank can recall the
> considerations for approving this request.

That would be indeed interesting.

Thorsten

Eddy Nigg

unread,
Aug 26, 2008, 2:05:28 PM8/26/08
to
Thorsten Becker:

>
> Can we say that it is neccessary (but not sufficient) to get included if
> you have "independent" sub-CAs that they are linked logically and
> legally to your root in a "sufficient" manner? Entities that are
> physically external seem to be quite common (Enterprise CAs)
>

"Quite Common" is perhaps an overstatement. There are scores of CAs with
no external CAs whatsoever.

However I don't agree with your statement above, physical inspection and
gathering of information and evidence on the site is usually quite
extensive during auditing. If those aren't audited, isn't that
effectively circumventing the auditing requirement of the Mozilla CA policy?

>
> So it has to be explicitly stated in the audit report, or is it
> sufficient that it is covered in the CP/CPS and the auditor raises no
> objections?

If the CP/CPS has provisions and makes it clear that auditing includes
the FULL PKI, than I expect the regular audit statements to be
sufficient. However many times the CP/CPS provisions contractual
agreements only, in which case the auditor hasn't covered the external
CAs, but only inspected the agreements. I think that there is a major
difference between the two.

Back to T-Systems, it makes a difference if the auditor inspected the
physical situation at the intermediate CAs or if their audit only
confirms T-Systems own CA infrastructure. Currently it might be possible
that one of those CAs have their CA server in the kitchen cabinet under
the sink somewhere...who knows?

> I agree with that, previously I thought: The auditor also monitors the
> operations of the root CA - not only the documents that describe how the
> operations are carried out, i.e. CP and CPS. During such an audit the
> presence of external sub-CAs would appall to the auditor, and he would
> object if this is considered wrong/dangerous.

I'd hope so...For this to be clear also to third parties like Mozilla,
the CP/CPS must cover the issuance procedures and requirements for
issuing CAs, including the physical and logical controls in place. Now
supposed those are covered in the CP/CPS, the auditor wouldn't sign the
audit statement before making sure that those are kept.

>
> GlobalSign offers a product that lets you operate your CA externally
> under one of their roots, so I guess these Sub CAs exist but are not
> linked directly to the root CA in question but are in fact subordinate
> root CAs further down the certificate chain. There seems to be no limit
> to the length of the certificate chain.

Nonono...it's nice that GlobalSign offers those as a product, it doesn't
mean that there are actually external CAs.

In relation to intermediate and external issuing CAs, we mean ANY CA
certificate which is chained to the root...As I understand, there are no
other sub ordinate CAs at the GlobalSign PKI as mentioned in the pending
page.

>> Most likely Frank can recall the
>> considerations for approving this request.
>
> That would be indeed interesting.
>

I'm certain that I've also looked at this CA during the comment period.
Since Frank was aware in relation to the possibility of sub ordinate
CAs, I believe that he clarified it with GlobalSign and also listed the
affected sub ordinate CA certificates at the pending page.

Kyle Hamilton

unread,
Aug 26, 2008, 2:15:27 PM8/26/08
to mozilla's crypto code discussion list
On Tue, Aug 26, 2008 at 3:24 AM, Thorsten Becker <tb-new...@arcor.de> wrote:
> In Bug #378882 Eddy Nigg directed me here because of a SubCA audit
> question: He states that root CAs in mozilla NSS must "Not circumvent
> the audit requirement set forth by the Mozilla CA policy.
> This means that the CAs which belong to this PKI and are under this root
> MUST
> be part of the audit. CAs themselves can't be the auditors, otherwise
> all CAs
> will audit themselves."

Eddy: Can the root CA operator itself be the auditor of the sub-CAs,
and bring its auditing documentation to its own auditor? That's not
clear from the language you used; I'm assuming that sub-CAs cannot
audit themselves (but could perhaps audit sub-sub-CAs), but since it's
the root CA's reputation on the line does the root CA get the ability
to enforce it by auditing its subs directly?

I think that's what this question is really about.

>
> That was an answer to a questions to the requirements to T-Systems to
> get their root accepted. I compared the practices of T-Systems to that
> of GlobalSign, that offer a service to Enterprise CAs that allows the
> Enterprise CAs to operate as SubCAs indepependently under the root of
> GlobalSign:
> http://eu.globalsign.com/pki/rootsign.htm
>
> According to the Info-Gathering-Document in Bug #406794, which covers
> the renewal of the GlobalSign root, GlobalSign does just do what they
> shouldn't do according to Eddys comment: They audit external SubCAs
> themselves, as stated in the bug/info-gathering-document:
> "[...] As a CA is then run by an enterprise, domains are not technically
> restricted, however domains are contractually restricted.
>
> *GlobalSign* audits periodically as part of our own brand protection
> program. [...]" [Emphasis added]
>
> So isn't GlobalSign doing something here that is very problematic?
>
> Thorsten

> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

Eddy Nigg

unread,
Aug 26, 2008, 2:38:13 PM8/26/08
to
Kyle Hamilton:

>
> Eddy: Can the root CA operator itself be the auditor of the sub-CAs,
> and bring its auditing documentation to its own auditor? That's not
> clear from the language you used; I'm assuming that sub-CAs cannot
> audit themselves (but could perhaps audit sub-sub-CAs), but since it's
> the root CA's reputation on the line does the root CA get the ability
> to enforce it by auditing its subs directly?

Which reputation [1] ? Are you suggesting that because I have a CA root
I can also play KPMG?

>
> I think that's what this question is really about.
>

Indeed! But I have been pretty clear, that the audit requirement is
circumvented if the "whatever-CA-under-some-root" isn't audited as well.
Hence CAs can't audit their own customers!

What I suggested is, that the language used in the CP/CPS must make the
audit requirement clear and/or obvious. Otherwise the audit statement of
the auditor shall confirm that instead ("Yes, we audited the complete
PKI including external CAs").


[1] I think we relied too many years on "reputations" for securing the
Internet....Bullshit!

0 new messages