"Super" CAs

[David E. Ross]

I noticed in the open bug reports for adding new root certificates that
several national certification authorities are actually acting as super
CAs without complete accountability for the operations of their
subsidiary CAs. Is the plan to eventually include the roots of the
super CAs in the NSS database? Or will only the roots of the subsidiary
CAs be included, after the usual Mozilla review process? How will this
be decided?

See:
<https://bugzilla.mozilla.org/show_bug.cgi?id=335197>
<https://bugzilla.mozilla.org/show_bug.cgi?id=438825>
<https://bugzilla.mozilla.org/show_bug.cgi?id=557167>

--

David E. Ross
<http://www.rossde.com/>

On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.

[Ruy Ramos]

On 02/15/2014 04:42 PM, David E. Ross wrote:
> I noticed in the open bug reports for adding new root certificates that
> several national certification authorities are actually acting as super
> CAs without complete accountability for the operations of their
> subsidiary CAs. Is the plan to eventually include the roots of the
> super CAs in the NSS database? Or will only the roots of the subsidiary
> CAs be included, after the usual Mozilla review process? How will this
> be decided?
>
> See:
> <https://bugzilla.mozilla.org/show_bug.cgi?id=335197>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=438825>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=557167>
>

The brazilian root CA for ICP-Brasil has complete accountability for the
operations of its subsidiary CAs. That is achieved by annual audit
procedures take into effect by ITI, the federal agency that plays the
role of Root CA of ICP-Brasil. So, in our opinion, it doesn't make any
sense to include only the subsidiary CAs certificates, cause the trusted
chain won't be correctly achieved without the check against the root
certificates of ICP-Brasil root CA (the ITI's certificates). So, in our
case, we would like very much to see the root certificates of the so
called super CA (ITI root certificates) included in the NSS database.
Otherwise, it won't work for the brazilian applications

Ruy Ramos
ITI
--


--
Esta mensagem foi verificada pelo sistema de antivírus e
acredita-se estar livre de perigo.

[Ryan Sleevi]

Can you please explain what you mean by "the trusted chain won't be
correctly achieved"?

Trust anchors do not need to be root certificates. So why, specifically
and technically, does the ICP-Brasil root need to be included?

[Kathleen Wilson]

On 2/15/14 10:42 AM, David E. Ross wrote:
> I noticed in the open bug reports for adding new root certificates that
> several national certification authorities are actually acting as super
> CAs without complete accountability for the operations of their
> subsidiary CAs. Is the plan to eventually include the roots of the
> super CAs in the NSS database? Or will only the roots of the subsidiary
> CAs be included, after the usual Mozilla review process? How will this
> be decided?
>
> See:
> <https://bugzilla.mozilla.org/show_bug.cgi?id=335197>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=438825>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=557167>
>

Those are questions I've been pondering, and would appreciate input on.

In the past when we realized that a CA was acting as a super-CA we asked
them to have the subordinate CAs apply for inclusion separately. Then
each subordinate CA certificate could get included as a trust anchor
after they have gone through the full process and been approved.

This is the approach we took with Venezuela’s national government CA
(SUSCERTE, bug #489240) and India’s national government CA (CCA, bug
#557167). Each of these have asked their subordinate CAs to apply for
inclusion separately. PROCERT (bug #593805) has had their PSCProcert
certificate included, which is signed by SUSCERTE's root.

In Firefox 30 we are adding the capability to name constrain at the root
level (https://bugzilla.mozilla.org/show_bug.cgi?id=743700#c2). So I am
wondering if we should consider using name constraints for super-CAs who
want to apply for inclusion of their root certs. For instance if a
certain government CA acts as a super-CA for their country, would it be
reasonable to consider inclusion of their root certificate as long as we
constrain it to their government and/or country domains?

I also think we should consider using name constraints on root certs for
CAs who:
- don't have external, third-party audits
- are slow to respond to changes in policy (such as compliance with the BRs)
- other?

I will greatly appreciate thoughtful and constructive input on these topics.

Thanks,
Kathleen

[Jan Schejbal]

Am 2014-02-19 01:52, schrieb Kathleen Wilson:
> - don't have external, third-party audits

I think the current policy for these is "do not let/keep them in the
root program", and I think that this policy needs enforcement, not changes.

Kind regards,
Jan

--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...

[Ruy Ramos]

On 02/20/2014 02:37 PM, Ruy Ramos wrote:

> On 02/18/2014 08:28 PM, Ryan Sleevi wrote:
>> On Tue, February 18, 2014 5:28 am, Ruy Ramos wrote:

>>> On 02/15/2014 04:42 PM, David E. Ross wrote:
>>>> I noticed in the open bug reports for adding new root certificates
>>>> that
>>>> several national certification authorities are actually acting as
>>>> super
>>>> CAs without complete accountability for the operations of their
>>>> subsidiary CAs. Is the plan to eventually include the roots of the
>>>> super CAs in the NSS database? Or will only the roots of the
>>>> subsidiary
>>>> CAs be included, after the usual Mozilla review process? How will this
>>>> be decided?
>>>>
>>>> See:
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=335197>
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=438825>
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=557167>
>>>>

>>> The brazilian root CA for ICP-Brasil has complete accountability
>>> for the

>>> operations of its subsidiary CAs. That is achieved by annual audit
>>> procedures take into effect by ITI, the federal agency that plays the
>>> role of Root CA of ICP-Brasil. So, in our opinion, it doesn't make
>>> any
>>> sense to include only the subsidiary CAs certificates, cause the
>>> trusted
>>> chain won't be correctly achieved without the check against the root
>>> certificates of ICP-Brasil root CA (the ITI's certificates). So,
>>> in our
>>> case, we would like very much to see the root certificates of the so
>>> called super CA (ITI root certificates) included in the NSS database.
>>> Otherwise, it won't work for the brazilian applications
>>>
>>> Ruy Ramos
>>> ITI
>>> --
>> Can you please explain what you mean by "the trusted chain won't be
>> correctly achieved"?
>>
>> Trust anchors do not need to be root certificates. So why, specifically
>> and technically, does the ICP-Brasil root need to be included?
>>

> We have as a rule validating the entire chain of certification, and
> any application that deals with a certificate will require closing the
> trust chain to the root certificate. So,
> in this case we have the complete chain or trust anchor in ICP-BRASIL
> root.
>
> Otherwise, if the option to insert intermediate or subsidiaries
> authorities is implemented, the responsibility to validate the chain
> is the browser (NSS)?!
>
> To illustrate the hierarchy of ICP-Brazil, in annex have a diagram. We
> have 13 first-level authorities and 46 second-level authorities for a
> single root CA (v2).
>
> Regards,
> Ruy Ramos

[Ruy Ramos]

[Kathleen Wilson]

On 2/19/14 1:43 PM, Jan Schejbal wrote:
> Am 2014-02-19 01:52, schrieb Kathleen Wilson:
>> - don't have external, third-party audits
>
> I think the current policy for these is "do not let/keep them in the
> root program", and I think that this policy needs enforcement, not changes.
>
> Kind regards,
> Jan
>

http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"14. By "independent party" we mean a person or other entity who is not
affiliated with the CA as an employee or director and for whom at least
one of the following statements is true:
- the party is not financially compensated by the CA;
- the nature and amount of the party’s financial compensation by
the CA is publicly disclosed; or
- the party is bound by law, government regulation, and/or a
professional code of ethics to render an honest and objective judgement
regarding the CA."


There are included government CAs whose audits are performed by other
organizations within the same government.

Previously we have tried to tackle how to define and constrain
government CAs. (https://wiki.mozilla.org/CA:GovernmentCAs)
I think it is time to have this discussion again, and maybe this time
focus on identifying certain CA actions/behavior that can be used to
distinguish the CAs who should be constrained.


Kathleen

[Kurt Roeckx]

On 2014-02-18 14:28, Ruy Ramos wrote:
> The brazilian root CA for ICP-Brasil has complete accountability for the
> operations of its subsidiary CAs. That is achieved by annual audit
> procedures take into effect by ITI, the federal agency that plays the
> role of Root CA of ICP-Brasil.

Please note that CAB baseline requirements says this:

17. Audit

Certificates that are capable of being used to issue new certificates
MUST either be Technically Constrained in line with section 9.7 and
audited in line with section 17.9 only, or Unconstrained and fully
audited in line with all remaining requirements from section 17. A
Certificate is deemed as capable of being used to issue new certificates
if it contains an X.509v3 basicConstraints extension, with the cA
boolean set to true and is therefore by definition a Root CA Certificate
or a Subordinate CA Certificate.

And:

17.9 Regular Quality Assessment of Technically Constrained Subordinate CAs

During the period in which a Technically Constrained Subordinate CA
issues Certificates, the CA which signed the Subordinate CA SHALL
monitor adherence to the CA’s Certificate Policy and the Subordinate
CA’s Certification Practice Statement. On at least a quarterly
basis, against a randomly selected sample of the greater of one
certificate or at least three percent of the Certificates issued by the
Subordinate CA, during the period commencing immediately after the
previous audit sample was taken, the CA shall ensure all applicable
Baseline Requirements are met.


So it's either:
- They're Technically Constrained, you need to audit them every 3 months
- They're not Technically Constrained and need a audit every year, and
we could include them directly as root CAs.


Kurt

[Ryan Sleevi]

On Thu, February 20, 2014 9:37 am, Ruy Ramos wrote:
> On 02/18/2014 08:28 PM, Ryan Sleevi wrote:
> > On Tue, February 18, 2014 5:28 am, Ruy Ramos wrote:
> >> On 02/15/2014 04:42 PM, David E. Ross wrote:
> >>> I noticed in the open bug reports for adding new root certificates
> >>> that
> >>> several national certification authorities are actually acting as
> >>> super
> >>> CAs without complete accountability for the operations of their
> >>> subsidiary CAs. Is the plan to eventually include the roots of the
> >>> super CAs in the NSS database? Or will only the roots of the
> >>> subsidiary
> >>> CAs be included, after the usual Mozilla review process? How will
> >>> this
> >>> be decided?
> >>>
> >>> See:
> >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=335197>
> >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=438825>
> >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=557167>
> >>>

> >> The brazilian root CA for ICP-Brasil has complete accountability for
> >> the
> >> operations of its subsidiary CAs. That is achieved by annual audit
> >> procedures take into effect by ITI, the federal agency that plays the

> >> role of Root CA of ICP-Brasil. So, in our opinion, it doesn't make
> >> any
> >> sense to include only the subsidiary CAs certificates, cause the
> >> trusted
> >> chain won't be correctly achieved without the check against the root
> >> certificates of ICP-Brasil root CA (the ITI's certificates). So, in
> >> our
> >> case, we would like very much to see the root certificates of the so
> >> called super CA (ITI root certificates) included in the NSS database.
> >> Otherwise, it won't work for the brazilian applications
> >>
> >> Ruy Ramos
> >> ITI
> >> --
> > Can you please explain what you mean by "the trusted chain won't be
> > correctly achieved"?
> >
> > Trust anchors do not need to be root certificates. So why, specifically
> > and technically, does the ICP-Brasil root need to be included?
> >
> We have as a rule validating the entire chain of certification, and any
> application that deals with a certificate will require closing the trust
> chain to the root certificate. So,
> in this case we have the complete chain or trust anchor in ICP-BRASIL
> root.

That's not required by RFC5280. A trust anchor does not need to be a
self-signed root. If you have specific applications that require that, you
should fix them.

If you're believe there are bugs in NSS's implementation that prevents
trust anchors from appearing anywhere on the chain, file bugs and we'll
fix them.

>
> Otherwise, if the option to insert intermediate or subsidiaries
> authorities is implemented, the responsibility to validate the chain is
> the browser (NSS)?!

Considering it's always the browser's responsibility to validate the
chain, I don't understand your issue here.

If you have some custom PKI client software, running for plugins or
something else that is not part of Mozilla Firefox, then I'm not
sympathetic towards your bugs, nor do I buy the argument that your bugs
should prevent Mozilla from encouraging good PKI practice.

>
> To illustrate the hierarchy of ICP-Brazil, in annex have a diagram. We
> have 13 first-level authorities and 46 second-level authorities for a
> single root CA (v2).

Sure. And those 13 first-level authorities can each apply for inclusion
within Mozilla, which is how things have currently been accomplished.

Under the Mozilla policy, each of those 13 first-level authorities and 46
second-level authorities are required to be compliant to the Mozilla
policy. As such, it should be "trivial" to demonstrate this is the case.

In practice and reality, this actually turns out to not be the case, which
is why I support Mozilla's request that the 13 first-level authorities
apply for inclusion themselves - so that it's clear to Mozilla (and the
public) whether or not ICP-Brazil is fully comforming with the Mozilla
policy throughout the PKI hierarchy.

[Kathleen Wilson]

All,

The only place where we currently describe Super-CAs is here:

https://wiki.mozilla.org/CA:SubordinateCA_checklist
“In the situation where the root CA functions as a super CA such that
their CA policies don't apply to the subordinate CAs (including
auditing), then the root CA should not be considered for inclusion.
Rather, the subordinate CAs may apply for inclusion themselves, as
separate trust anchors.”


I’d like to clarify this text, so that CAs who are super-CAs will
realize that it applies to them.

How about the following?
--
Some governments operate CAs that sign public third-party subordinate
CAs to show that they have been accredited or licensed to operate as a
CA within their country or for their government. Such root CAs are
called Super-CAs, and their subordinate CAs must apply for inclusion
themselves if any of the following apply:
- The root CA performs the audits of their subordinate CAs.
- The root CA does not issue end-entity certificates themselves.
- The root CA’s public-facing documented policies do not contain
information about end-entity certificates.
- The first-level public third-party subordinate CAs sign second-level
public third-party subordinate CAs, making it difficult for Mozilla and
others to annually confirm that the full CA hierarchy is in compliance
with Mozilla’s CA Certificate Policy.
- <Anything else?>
--

I will greatly appreciate your feedback on this.

Kathleen

[Kurt Roeckx]

So I've been thinking about other cases where CAs sign other CAs
that are not from the same organisation. I think we should in
general discourage that, if not forbid it.

I've been wondering about how my government (Belgium) actually
does this. They have a root CA and multiple sub CAs. It seems
they are not a root CA for mozilla but are instead signed by
Cybertrust, which is. I can't imagine that Cybertrust does an
audit of that CA.

So this is basically a reversed case of the above, and I think we
should avoid both ways, and maybe the text should be more general
and not talk about governments except as example.

I think that "subordinate CA" is also not very well defined. I
think a subordinate CA belongs to the same organisation, but I
think most people use it for any intermediate CA.

I would like to come to the situation that all organistations that
operate a CA should themself apply to become a root CA.



Kurt

[David E. Ross]

The lead paragraph should encompass non-government super CAs, too.
Furthermore, the policy should address certification authorities (CAs)
and not their root certificates. Consider the following:

> Some CAs sign the certificates of subordinate CAs to show that they have
> been accredited or licensed by the signing CA. Such signing CAs are

> called Super-CAs, and their subordinate CAs must apply for inclusion

> their own roots if any of the following apply ...

Then, in the listed criteria, change "root CA" to either "subordinate
CA" where a certification authority is meant or to "root certificate"
where a certificate is meant.

I would also add a prohibition against including the root certificate of
any Super-CA.

Finally, the wording cites "third-party subordinate CAs". I assume the
Super-CA is the first-party. What is a "second-party subordinate CA"?

[Brown, Wendy (10421)]

With full disclosure that I have applied for the US Federal Common Policy CA to be included as a trust anchor (even though we haven't made it thru the process yet). I question the proposal to try and have all the cross-certified or subordinate CAs individually apply to be trust anchors. In the case of the US government this would defeat the purpose of trying to get the Federal Common Policy CA in the trust store as the single trust anchor for the US federal government.

We do publicly disclose all the CAs we have certified, we do require independent audits of each and every CA, the Common Policy CP and a redacted version of our CPS is publicly available as is the criteria for approving the subordinate CAs, although they each have to have their own CPS which we have mapped to the CP. Not all of these subordinate CAs even operate a Root CA, because they are supposed to be subordinate to the Federal Common Policy CA.

Those CAs that are cross-certified with the Federal Bridge CA (and therefore have a valid path to the Federal Common Policy CA) operate under their own CP and CPS, but their CP has to have been mapped to the Federal Bridge CP which is again publicly available and they are required to undergo an annual PKI audit which includes independent assessment that they are operating under a CPS that maps to their CP and they are incompliance with the Memorandum of Agreement with the Federal PKI Policy Authority.

Thanks,
Wendy

Wendy Brown
Protiviti Government Services
703-299-4705 (office) 703-965-2990 (cell)

wendy...@protiviti.com
wendy...@fpki.gov



NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services.

This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

[Kurt Roeckx]

Hi,

I have a few questions:
- Are all those subordinate CAs part of the government?
- Do all audit criteria for approving the subordinate CA match
those that are required by Mozilla?

If both of those are the case, I see no problem adding it.


Kurt

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Policy Authority PKIoverheid]

As the Policy Authority of the Dutch Governmental PKI program (PKIoverheid) I would like to add our view to this discussion. We operate a program that is similar in character to the Federal Common Policy CA. We operate one trust anchor (the Staat der Nederlanden Root CA) for use with and within Dutch Government. This trust anchor is already included in the major browser products such as Mozilla, Microsoft and Apple.

We enable parties - both governmental and commercial - to operate as Certificate Service Providers under our Root CA. In doing so we have created an infrastructure that can be used for communication within and with Dutch government. Our Certificate Service Providers must adhere to our Certificate Policies, that are based on ETSI TS 101456 and 102042 with a number of additional PKIoverheid requirements such as the adherence to the CABforum Baseline Requirements. The CSPs annualy undergo an external audit. This certification is an ETSI certification with the addional PKIoverheid requirements taken into account.

This thread started with the fact that "several national certification authorities are actually acting as super CAs without complete accountability for the operations of their subsidiary CAs". This clearly is a problematic practice, as this does not create the required transparency needed for a trust system to operate correctly. A so-called super CA must at all times be completely accountable for their sub-CAs. It is then the responsibility of these sub-CAs to meet the publicly stated requirements of the Certificate Policies of the super CAs, and undergo an external audit to that effect. The Policy Authority PKIoverheid is completely accountable for the CSPs within the PKIoverheid/Staat der Nederlanden hierarchy.

Looking at the proposed requirements as posted by Kathleen we see the need for all, bar the requirement for the Root CA organization to issue end-entity certificates. In our opinion the fact that a trust anchor organization is able, or does, issue end entity certificates does not add to the trustworthiness of the system as a whole. The trust anchor organization must ensure that all sub-CAs demonstrably adhere to the requirements that are applicable to a trust anchor, by means of an external audit and publically verifiable documentation and proof.

Regards,
Mark Janssen

[Kurt Roeckx]

Hi,

I think what we want to accomplish is that all CAs are properly
audited with all our requirements. And from what you describe I
see no problem with PKIoverheid. But I have the feeling that the
Dutch government is an exception and can only hope that the others
would follow the example.

You say that commercial parties can also apply for this with
PKIoverheid. But they could also apply directly with Mozilla
for inclusion, since I understand that they would also comply with
Mozilla's requirements. I'm not sure what the best approach is.

The advantage I see for applying directly with Mozilla instead of
some super CA:
- It's more transparent. Mozilla publishes all audit reports.
- We can contrain the CAs more easily.
- It's easier to disable a CA in case of problems.
- The hierachy gets smaller

The disavantages:
- The new CA would need to apply in multiple programs like
Mozilla and Microsoft.
- Might give more work to Mozilla.

Others?


Kurt

[Kathleen Wilson]

On 3/18/14, 11:54 AM, Kathleen Wilson wrote:
> All,
>
> The only place where we currently describe Super-CAs is here:
>
> https://wiki.mozilla.org/CA:SubordinateCA_checklist
> “In the situation where the root CA functions as a super CA such that
> their CA policies don't apply to the subordinate CAs (including
> auditing), then the root CA should not be considered for inclusion.
> Rather, the subordinate CAs may apply for inclusion themselves, as
> separate trust anchors.”
>
>
> I’d like to clarify this text, so that CAs who are super-CAs will
> realize that it applies to them.
>

Thanks to all of you who have commented on this. Based on your input,
here's a new proposal:

--

Some CAs sign the certificates of subordinate CAs to show that they have

been accredited or licensed by the signing CA. Such signing CAs are
called Super-CAs, and their subordinate CAs must apply for inclusion of
their own certificates until the following has been established and
demonstrated:
- The Super-CA’s documented policies and audit criteria meet the
requirements of Mozilla’s CA Certificate Policy, which includes the
CA/Browser Forum’s Baseline Requirements, and includes sufficient
information about verification practices and issuance of end-entity
certificates.
- The Super-CA is at all times completely accountable for their
subordinate CAs, and the Super-CA ensures that all subordinate CAs
demonstrably adhere to the Super-CA’s documented policies and audit
criteria.
- The Super-CA provides publicly verifiable documentation and proof of
annual audits for each subordinate CA that attest to compliance with the
Super-CA’s documented policies and audit criteria.
- The subordinate CAs do not themselves act as a Super-CA or sign a
large number of public third-party subordinate CAs, making it difficult

for Mozilla and others to annually confirm that the full CA hierarchy is
in compliance with Mozilla’s CA Certificate Policy.

--

I will greatly appreciate your input on this new proposed text.

Thanks,
Kathleen

PS: in https://wiki.mozilla.org/CA:SubordinateCA_checklist there is a
Terminology section which defines third-party and public.
"Third-Party: The subordinate CA is operated by a third party external
to the root CA organization; and/or an external third party may directly
cause the issuance of a certificate within the CA hierarchy."
"Public: The subordinate CA issues certificates to entities not
affiliated with the sub-CA organization."

[Policy Authority PKIoverheid]

Hi Kathleen,

The new proposed text looks okay to me. I have no comments on it. Thanks.

Regards,
Mark

[Kurt Roeckx]

On Mon, Mar 31, 2014 at 04:01:03PM -0700, Kathleen Wilson wrote:
>
> Thanks to all of you who have commented on this. Based on your input, here's
> a new proposal:
>
> --
> Some CAs sign the certificates of subordinate CAs to show that they have
> been accredited or licensed by the signing CA. Such signing CAs are called
> Super-CAs, and their subordinate CAs must apply for inclusion of their own
> certificates until the following has been established and demonstrated:
> - The Super-CA's documented policies and audit criteria meet the
> requirements of Mozilla's CA Certificate Policy, which includes the
> CA/Browser Forum's Baseline Requirements, and includes sufficient
> information about verification practices and issuance of end-entity
> certificates.
> - The Super-CA is at all times completely accountable for their subordinate
> CAs, and the Super-CA ensures that all subordinate CAs demonstrably adhere
> to the Super-CA's documented policies and audit criteria.
> - The Super-CA provides publicly verifiable documentation and proof of
> annual audits for each subordinate CA that attest to compliance with the
> Super-CA's documented policies and audit criteria.
> - The subordinate CAs do not themselves act as a Super-CA or sign a large

> number of public third-party subordinate CAs, making it difficult for

> Mozilla and others to annually confirm that the full CA hierarchy is in
> compliance with Mozilla's CA Certificate Policy.

> --
>

> I will greatly appreciate your input on this new proposed text.

This looks good.


Kurt

[Kathleen Wilson]

I've updated the wiki page:

https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs

Comments, corrections, and recommendations on this are still welcome.

Thanks!
Kathleen

[David E. Ross]

That seems to cover my concerns as an end user. Thanks.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Kathleen Wilson]

I think we need to add one more bullet point to this regarding when it
is OK for the Super-CA to be the auditor of its subordinate CAs.

http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"14. By "independent party" we mean a person or other entity who is not
affiliated with the CA as an employee or director and for whom at least
one of the following statements is true:
- the party is not financially compensated by the CA;
- the nature and amount of the party’s financial compensation by the CA
is publicly disclosed; or
- the party is bound by law, government regulation, and/or a
professional code of ethics to render an honest and objective judgement
regarding the CA."

For instance, in the KISA discussion it was established that KISA is an
independent organization from their subCAs, they are not financially
compensated for the audits, and they are bound by government regulation
to do the audit. So, can KISA (as a Super-CA) audit their subCAs?

Kathleen

[David E. Ross]

I'm not sure I am comfortable with a "super CA" auditing the CAs it
accedits or licenses. Yes, the super CA should indeed oversee (not
overlook) the operations of its subordinate CAs to ensure the latter
adhere to the former's policies. However, I think it is important that
an outside auditor verifies that the super CA is indeed exercising that
oversight and that the subordinate CAs are indeed adhering to the
policies.

[spar...@gmail.com]

It is stated at the law, and the entire procedure is controlled by the government.
Because it is the law, if the subCAs do not follow the policies it would be breaking the law.
Please understand that some countries prefer the government to be involved rather than an outside auditor(like consulting firms) for the transparency of the procedure.

2014년 4월 2일 수요일 오후 3시 17분 40초 UTC+9, David E. Ross 님의 말:

[Kurt Roeckx]

Please understand that it this are requirements on what needs to
be audited, not who should do it.

I'm guessing you're talking about KISA. As far as we can tell the
audit that KISA does does not cover the requirements we have on
what needs to be audited.


Kurt

On Wed, Apr 02, 2014 at 05:56:10PM -0700, spar...@gmail.com wrote:
> It is stated at the law, and the entire procedure is controlled by the government.
> Because it is the law, if the subCAs do not follow the policies it would be breaking the law.
> Please understand that some countries prefer the government to be involved rather than an outside auditor(like consulting firms) for the transparency of the procedure.
>

> 2014? 4? 2? ??? ?? 3? 17? 40? UTC+9, David E. Ross ?? ?:

[Kathleen Wilson]

If I'm understanding the input on this correctly, then an outside
auditor needs to be involved in some way. But that can mean that the
outside auditor verifies that the audit criteria being used includes the
Baseline Requirements and the WebTrust or ETSI criteria that Mozilla
requires, and that the outside auditor reviews the Super-CA's audit
report of each subordinate CA to confirm that the subCA was indeed
evaluated according to the stated criteria.

Correct?

Thanks,
Kathleen

[Kurt Roeckx]

On Mon, Apr 07, 2014 at 04:18:17PM -0700, Kathleen Wilson wrote:
> >
> >http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> >
> >"14. By "independent party" we mean a person or other entity who is not
> >affiliated with the CA as an employee or director and for whom at least
> >one of the following statements is true:
> >- the party is not financially compensated by the CA;
> >- the nature and amount of the party's financial compensation by the CA
> >is publicly disclosed; or
> >- the party is bound by law, government regulation, and/or a
> >professional code of ethics to render an honest and objective judgement
> >regarding the CA."
> >
> >For instance, in the KISA discussion it was established that KISA is an
> >independent organization from their subCAs, they are not financially
> >compensated for the audits, and they are bound by government regulation
> >to do the audit. So, can KISA (as a Super-CA) audit their subCAs?
> >
> >Kathleen
> >
>
>

> If I'm understanding the input on this correctly, then an outside auditor
> needs to be involved in some way. But that can mean that the outside auditor
> verifies that the audit criteria being used includes the Baseline
> Requirements and the WebTrust or ETSI criteria that Mozilla requires, and
> that the outside auditor reviews the Super-CA's audit report of each
> subordinate CA to confirm that the subCA was indeed evaluated according to
> the stated criteria.
>
> Correct?

Those super CAs already need to get an audit. I think what he's
saying is that that audit should include their audit of the sub
CAs.

Or you would have to do some checks that they really follow those
rules.

PS: Did you communicate those things to the (known) super CAs?


Kurt

[Kathleen Wilson]

I'm still conflicted about whether a Super-CA can audit their
subordinate CAs. And if they can, then what assurances do we have that
the audit was done in an unbiased manner and according to the criteria
that we require.

>
> PS: Did you communicate those things to the (known) super CAs?
>

Here's the pending and included Super-CAs that I'm aware of.


KISA (Government of Korea, Bug #335197)
https://bugzilla.mozilla.org/show_bug.cgi?id=335197#c168
"...KISA CA is a Super-CA, so the following applies:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs"


ICP-Brasil (Government of Brazil, Bug #438825)
https://bugzilla.mozilla.org/show_bug.cgi?id=438825#c126
"The conclusion of the discussion is:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs
....Therefore, this request for inclusion of the ICP-Brasil root will be
on hold, pending inclusion of ICP-Brasil's subordinate CAs. The
subordinate CAs should create separate Bugzilla bugs and apply for
inclusion themselves as separate trust anchors"


SUSCERTE (Government of Venezuela, Bug #489240)
https://bugzilla.mozilla.org/show_bug.cgi?id=489240#c31
"Please have each sub-CA file a separate bug requesting the inclusion of
their certificate"


CCA (Government of India, Bug #557167)
https://bugzilla.mozilla.org/show_bug.cgi?id=557167#c16
"Create a separate bug for each of the 7 intermediate CAs to be
separately evaluated for inclusion as a trust anchor in NSS."


US FPKI (Government of US, Bug #478418)
A representative of the US FPKI CA has been involved in this discussion.
My impression is that US FPKI meets the criteria listed in the wiki page
that are needed before the Super-CA can have their root included, so I
don't expect that they will need to have their subCAs apply for
inclusion separately. Additionally, US FPKI has agreed to have their CA
hierarchy constrained (e.g. to *.us, *.gov and *.mil). There will be
another discussion about this CA when we believe our verification
software will properly constrain the CA and will sufficiently handle the
complexities of the old hierarchy (which is cross-signed) -- needs to be
tested with mozilla::pkix.


PKIoverheid (Government of Netherlands, Bug #551399)
A representative of the PKIoverheid has been involved in this
discussion. Note that PKIoverheid is already included, but they have
demonstrated and continue to demonstrate the requirements for Super-CAs
listed in the wiki page. Their subCAs are audited annually by an
external third-party.


Please let me know if you think other included or pending CAs are Super-CAs.

Thanks,
Kathleen

[David E. Ross]

On 4/8/2014 1:25 PM, Kathleen Wilson wrote:
> I'm still conflicted about whether a Super-CA can audit their
> subordinate CAs. And if they can, then what assurances do we have that
> the audit was done in an unbiased manner and according to the criteria
> that we require.

I expressed the same concern earlier. Having previously signed and
vouched for its subordinate CAs, a Super-CA might have a vested interest
in continuing to vouch for its subordinate CAs. Furthermore, having
developed its CP, CPS, and audit process, a Super-CA might not realize
weaknesses therein. Finally, few CAs (super or not) have professional
experience in performing formal audits.

[Kurt Roeckx]

On Tue, Apr 08, 2014 at 01:25:31PM -0700, Kathleen Wilson wrote:
> On 4/7/14, 4:27 PM, Kurt Roeckx wrote:

> I'm still conflicted about whether a Super-CA can audit their subordinate
> CAs. And if they can, then what assurances do we have that the audit was
> done in an unbiased manner and according to the criteria that we require.

I think there is some misunderstanding here. We expect those
supper CAs to either audit the sub CAs, or let the audit be done
by an other 3rd party. And I think that the normal case should
be that it's done by a 3rd party, unless those super CAs are to
be considered independant (by law).

The question now is who is going to verify that those super CAs
actually do follow the rules we have for them. And I see 2
options for that:
- As part of the audit of the super CA, they get checked that
follow up on the audits of the sub CAs.
- We (you?) go and verify that the information they publish
about the sub CAs is complete and correct.

> >PS: Did you communicate those things to the (known) super CAs?
>

> Here's the pending and included Super-CAs that I'm aware of.
>
> KISA (Government of Korea, Bug #335197)

> ICP-Brasil (Government of Brazil, Bug #438825)

> SUSCERTE (Government of Venezuela, Bug #489240)

> CCA (Government of India, Bug #557167)

> US FPKI (Government of US, Bug #478418)

> PKIoverheid (Government of Netherlands, Bug #551399)

So basicly you only know about governments that explictly asked
you about it.

But I know that we already have such super CAs in the root program
now. From the top of my head:
- UTN UserFirst signs Gandi
- CyberTrust Global signs the Belgian government CA
- GeoTrust gives google a CA
- Baltimore CyberTrust gives Microsoft a CA

I'm pretty sure that if I look around I can find others.


Kurt

[Kathleen Wilson]

On 4/8/14, 3:07 PM, Kurt Roeckx wrote:
>> Here's the pending and included Super-CAs that I'm aware of.
>>
>> KISA (Government of Korea, Bug #335197)
>> ICP-Brasil (Government of Brazil, Bug #438825)
>> SUSCERTE (Government of Venezuela, Bug #489240)
>> CCA (Government of India, Bug #557167)
>> US FPKI (Government of US, Bug #478418)
>> PKIoverheid (Government of Netherlands, Bug #551399)
>
> So basicly you only know about governments that explictly asked
> you about it.
>
> But I know that we already have such super CAs in the root program
> now. From the top of my head:
> - UTN UserFirst signs Gandi
> - CyberTrust Global signs the Belgian government CA
> - GeoTrust gives google a CA
> - Baltimore CyberTrust gives Microsoft a CA
>
> I'm pretty sure that if I look around I can find others.

There are lots of subordinate CAs. That's why we introduced sections 8
through 10 of Mozilla's CA Certificate Inclusion Policy.
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Technical_Constraints_or_Auditing.2FDisclosure_of_Intermediate_Certificates

I don't consider the CAs you listed above to be super-CAs, because they
have documented policies about issuing end-entity certs, they issue such
end-entity certs, and they are audited regarding their end-entity cert
issuance practices. Also, the CAs you listed do not "sign the

certificates of subordinate CAs to show that they have been accredited

or licensed by the signing CA." They sign the certificates of the
subordinate CAs so those subordinate CAs' certs will be recognized in
browsers. And usually such subordinate CAs would not be directly
included in Mozilla products, because they are only issuing certificates
for their own organizations.

The Super-CAs "sign the certificates of subordinate CAs to show that
they have been accredited or licensed by the signing CA." Most super-CAs
do not issue end-entity certificates themselves. And usually the
super-CAs' subordinate CAs (or Licensed CAs) also issue certificates to
other organizations and the general public, so those subordinate CAs may
be able to meet Mozilla's requirements so they can be directly included
as trust anchors.

Kathleen

[Kurt Roeckx]

On Tue, Apr 08, 2014 at 03:34:13PM -0700, Kathleen Wilson wrote:
> >
> >But I know that we already have such super CAs in the root program
> >now. From the top of my head:
> >- UTN UserFirst signs Gandi
> >- CyberTrust Global signs the Belgian government CA
> >- GeoTrust gives google a CA
> >- Baltimore CyberTrust gives Microsoft a CA
> >
> >I'm pretty sure that if I look around I can find others.
>
>
>

> There are lots of subordinate CAs. That's why we introduced sections 8
> through 10 of Mozilla's CA Certificate Inclusion Policy.
> https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Technical_Constraints_or_Auditing.2FDisclosure_of_Intermediate_Certificates
>
> I don't consider the CAs you listed above to be super-CAs, because they have
> documented policies about issuing end-entity certs, they issue such
> end-entity certs, and they are audited regarding their end-entity cert

> issuance practices. Also, the CAs you listed do not "sign the certificates

> of subordinate CAs to show that they have been accredited or licensed by the

> signing CA." They sign the certificates of the subordinate CAs so those
> subordinate CAs' certs will be recognized in browsers.

I think that the act of signing someone elses CA means that they
take responsability of making sure that that CA is following our
requirements.

> And usually such
> subordinate CAs would not be directly included in Mozilla products, because
> they are only issuing certificates for their own organizations.

The first example, Gandi, does sign certificates for other
organizations.

I believe none of them are technical constrainted. It might not
be clear what technical constrainted is but I think the CA/Browser
baseline requirements have that as both:
- Extented key usage constraint
- Name based constraint.

And none of them seem to have either constrained.

> And usually the super-CAs'
> subordinate CAs (or Licensed CAs) also issue certificates to other
> organizations and the general public, so those subordinate CAs may be able
> to meet Mozilla's requirements so they can be directly included as trust
> anchors.

We want *all* CAs (that aren't properly constrained) to meet the
requirements so that they can be directly included as trust
anchors. That doesn't mean we need to add them all, someone else
can take the responsability of checking the requirements. And in
my opinion they take that responsability when they sign an other
CA.


Kurt

[Rob Stradling]

On 09/04/14 00:27, Kurt Roeckx wrote:
<snip>

> The first example, Gandi, does sign certificates for other
> organizations.

Hi Kurt.

You seem to be assuming that the Subject organizationName in the
intermediate CA certificate ("O=GANDI SAS" in this case) identifies the
organization that controls the CA private key. This assumption seems
plausible at first glance, but it's actually wrong. It's the same
assumption underlying the EFF SSL Observatory's incorrect claim that
there are "650-odd organizations that function as Certificate
Authorities trusted (directly or indirectly) by Mozilla or Microsoft." [1]

You may recall that the EFF's "650-odd" figure included 200 or so
intermediate CA certificates issued by DFN-Verein to German academic
institutions. It subsequently became apparent that the DFN retains
control of the intermediate CA private keys and checks each certificate
request. Each academic institution is an RA, and DFN is the only CA.

Comodo operate intermediate CAs for several of our partners in a similar
fashion. The partner is named in the intermediate certificate's Subject
organizationName, but it is Comodo who controls the intermediate CA
private key and checks each certificate request.

FWIW, Kathleen has encouraged us to do this! [2]


[1] https://www.eff.org/observatory

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=653543#c0
"4) Implement a hierarchy of internally-operated intermediate CAs for
single or related groups of RAs."

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Rob Stradling]

On 09/04/14 11:57, Moudrick M. Dadashov wrote:
<snip>

>> Comodo operate intermediate CAs for several of our partners in a
>> similar fashion. The partner is named in the intermediate
>> certificate's Subject organizationName, but it is Comodo who controls
>> the intermediate CA private key and checks each certificate request.
>>

> Rob, should we call this as "Hosted CA" or "CA hosting" service?

Hi Moudrick. Yes, something like that, although I'd prefer to call this
something that explicitly states that it's the Issuer of the
Intermediate CA that controls the private key (and not, as you might
expect, the Subject). If we can think of a suitable term...

[Kurt Roeckx]

Hi Rob,

On Wed, Apr 09, 2014 at 11:25:34AM +0100, Rob Stradling wrote:
> On 09/04/14 00:27, Kurt Roeckx wrote:
> <snip>
> >The first example, Gandi, does sign certificates for other
> >organizations.
>
> Hi Kurt.
>
> You seem to be assuming that the Subject organizationName in the
> intermediate CA certificate ("O=GANDI SAS" in this case) identifies the
> organization that controls the CA private key. This assumption seems
> plausible at first glance, but it's actually wrong.

If I read to Gandi's CPS, they seem to indicate that they control
the private key.

But then there is also Comodo's CPS, which seems to indicate that
Gandi should be following Comodo's CPS.

But Gandi also seems to offer certificates that are validated by
Comodo, and it's all becomming unclear to me.

> You may recall that the EFF's "650-odd" figure included 200 or so
> intermediate CA certificates issued by DFN-Verein to German academic
> institutions. It subsequently became apparent that the DFN retains control
> of the intermediate CA private keys and checks each certificate request.
> Each academic institution is an RA, and DFN is the only CA.
>

> Comodo operate intermediate CAs for several of our partners in a similar
> fashion. The partner is named in the intermediate certificate's Subject
> organizationName, but it is Comodo who controls the intermediate CA private
> key and checks each certificate request.

So I basically have a few questions:
1) Who makes the decision to sign a certificate?
2) Who control the private key?
3) Which CPS is being followed?
4) Who verifies that that CPS is being followed?

I was under the impression that the Registration Authority (RA)
would be 1), but that comodo would be 2), but I now I get the
feeling that Comodo is both 1) and 2).

Anyway, the end user certificate has a pointer to the CPS in it,
and in case of "O=GANDI SAS" it points to their own CPS.

Any idea what the situation is with DFN?

Maybe a good way to find the total amount of CA's is to look at
the different CPSs? But I currently can't find a requirement in
the CA/B Forum requirements that they need to add that.

I think what we want to get to is that each CPS is audited, that
everybody following that CPS is audited, and define who is
responsible for that audit.


Kurt

[spar...@gmail.com]

The audit criteria and the policies can be compared to Mozilla’s requirements and CA browser forum’s requirements. And we are willing to confirm the comparison by a third-party audit practitioner(such as Deloitte)

If this is done, do you think KISA can be accepted?

Samuel.


2014년 4월 4일 금요일 오전 1시 43분 56초 UTC+9, Kurt Roeckx 님의 말: