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
