Re: "Super" CAs

[spark0102]

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 님의 말:
> 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, spark0...@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 ?? ?:
> 
> > > On 4/1/2014 8:11 PM, Kathleen Wilson wrote:
> 
> > > 
> 
> > > > On 4/1/14, 11:12 AM, Kathleen Wilson wrote:
> 
> > > 
> 
> > > >> On 3/31/14, 4:01 PM, Kathleen Wilson wrote:
> 
> > > 
> 
> > > >>> 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'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
> 
> > > 
> 
> > > >>
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > 
> 
> > > 
> 
> > > > I think we need to add one more bullet point to this regarding when it 
> 
> > > 
> 
> > > > is OK for the Super-CA t

Re: "Super" CAs

[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:
> 
> >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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Moudrick M. Dadashov]

On 4/9/2014 2:04 PM, Rob Stradling wrote:

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


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...


Right, the key word here is "controls" and from certificate data its not 
too obvious, at least for me, who in reality is the CA (that owns the 
private key).


We should make this clear - either the technical controller (hosting 
service provider) is the entity who controls (in legal sense owns) the 
private key or the Subject is the owner of the private key, despite the 
fact that its technically under the control of a hosting service provider.


Like in case of domain names, we need somehow to distinguish these two 
aspects: ownership and technical control.


Only the entity that owns the private key is the CA (?).

Thanks,
M.D.


smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Rob Stradling]

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


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...


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Moudrick M. Dadashov]

On 4/9/2014 1:25 PM, Rob Stradling wrote:

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


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.



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

Thanks,
M.D.

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."







smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Rob Stradling]

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


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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:
> >On Mon, Apr 07, 2014 at 04:18:17PM -0700, Kathleen Wilson wrote:
> >>
> >>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.
> 
> 
> 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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.

-- 

David E. Ross


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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Kathleen Wilson]

On 4/7/14, 4:27 PM, Kurt Roeckx wrote:

On Mon, Apr 07, 2014 at 04:18:17PM -0700, Kathleen Wilson wrote:


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.



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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Kathleen Wilson]

On 4/1/14, 8:11 PM, Kathleen Wilson wrote:

On 4/1/14, 11:12 AM, Kathleen Wilson wrote:

On 3/31/14, 4:01 PM, Kathleen Wilson wrote:

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'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





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




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




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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, spark0...@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 ?? ?:
> > On 4/1/2014 8:11 PM, Kathleen Wilson wrote:
> > 
> > > On 4/1/14, 11:12 AM, Kathleen Wilson wrote:
> > 
> > >> On 3/31/14, 4:01 PM, Kathleen Wilson wrote:
> > 
> > >>> 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'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
> > 
> > >>
> > 
> > > 
> > 
> > > 
> > 
> > > 
> > 
> > > 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?
> > 
> > > 
> > 
> > > Kat

Re: "Super" CAs

[spark0102]

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 님의 말:
> On 4/1/2014 8:11 PM, Kathleen Wilson wrote:
> 
> > On 4/1/14, 11:12 AM, Kathleen Wilson wrote:
> 
> >> On 3/31/14, 4:01 PM, Kathleen Wilson wrote:
> 
> >>> 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'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
> 
> >>
> 
> > 
> 
> > 
> 
> > 
> 
> > 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
> 
> 
> 
> 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.
> 
> 
> 
> 
> 
> -- 
> 
> David E. Ross
> 
> 
> 
> The Crimea is Putin's Sudetenland.
> 
> The Ukraine will be Putin's Czechoslovakia.
> 
> See .

___

Re: "Super" CAs

[David E. Ross]

On 4/1/2014 8:11 PM, Kathleen Wilson wrote:
> On 4/1/14, 11:12 AM, Kathleen Wilson wrote:
>> On 3/31/14, 4:01 PM, Kathleen Wilson wrote:
>>> 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'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
>>
> 
> 
> 
> 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

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.


-- 
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See .
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Kathleen Wilson]

On 4/1/14, 11:12 AM, Kathleen Wilson wrote:

On 3/31/14, 4:01 PM, Kathleen Wilson wrote:

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'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





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














___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[David E. Ross]

On 4/1/2014 11:12 AM, Kathleen Wilson wrote:
> On 3/31/14, 4:01 PM, Kathleen Wilson wrote:
>> 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'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
> 

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 .
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Kathleen Wilson]

On 3/31/14, 4:01 PM, Kathleen Wilson wrote:

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'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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Policy Authority PKIoverheid]

Hi Kathleen,

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

Regards,
Mark
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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."


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs (Kurt Roeckx)

[Brown, Wendy (10421)]

Kurt - 
Another disadvantage of having CAs with a relationship to something like the US 
FPKI or Dutch PKIoverheid also apply directly to be included as a trust anchor 
with Mozilla, Microsoft, etc is if a problem does pop up with one of these CAs 
the programs that distribute it remove it via an update or patch that requires 
all relying parties to accept, rather than the single trust anchor severing the 
relationship by revoking the certificate.  Which I know does require the 
relying parties to be checking certificate status.

   wendy


Message: 5
Date: Thu, 20 Mar 2014 19:19:08 +0100
From: Kurt Roeckx 
To: Policy Authority PKIoverheid 
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: "Super" CAs
Message-ID: <20140320181908.gc7...@roeckx.be>
Content-Type: text/plain; charset=us-ascii

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


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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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

On Thu, Mar 20, 2014 at 03:59:35AM -0700, Policy Authority PKIoverheid wrote:
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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

On Wed, Mar 19, 2014 at 07:52:20PM +, Brown, Wendy (10421) wrote:
> 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.br...@protiviti.com
> wendy.br...@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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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.br...@protiviti.com
wendy.br...@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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"?

-- 

David E. Ross


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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Kurt Roeckx]

On Tue, Mar 18, 2014 at 11:54:38AM -0700, 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.
> 
> 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.
> - 
> --
> 
> I will greatly appreciate your feedback on this.

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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.

- 
--

I will greatly appreciate your feedback on this.

Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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:
> >>> 
> >>> 
> >>> 
> >>>
> >>   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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Ruy Ramos]

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:





  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







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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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:




  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










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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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:







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





___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[Ryan Sleevi]

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:
> > 
> > 
> > 
> >
>  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?

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "Super" CAs

[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:




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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy