On Tue, Feb 17, 2015 at 7:25 AM, Framarti <[email protected]> wrote: > i'm working for a company that is issuing trusted SSL OV certificates as a > subsidiary CA. I was thinking about becoming a trusted root CA in order to > get rid of the fees per each issued certificate to be given to actual root CA. > > I'm not really sure about needed activities. > Trying to schematize them in two steps, here is my guess: > 1 - Creation of a self signed CA certificate; > 2 - Submission to a third party Audit (i.e. vs WebTrust program, baseline and > for publicly trusted certificates); > 3 - Submission to Mozilla Root Certificate Program. > > Am i missing something?
Great question. I'm sure that others will happily weigh in on their views. Obviously you need to comply with the Mozilla CA program requirements. Other vendors (Microsoft, Apple, etc) have their own requirements. >From my perspective, I think that operating a Subordinate Issuing CA and operating a Root CA are functionally two different activities. To have Root CA, you need to have a secure offline facility to hold your HSMs and procedures to issue Subordinate CA certificates. You need a CPS for the Root CA that covers the operations of the Root CA. Your CPS needs to be clear that all Subordinate CAs need their own CPS, and have to be audited. You then need both the WebTrust for CA and WebTrust for Baseline Requirements audits that provide confirmation that you are following your CPS. You didn't ask about EV, which is good, as I'm not exactly clear on what it means to have a Root CA audited for EV compliance. The best I can figure is that the Root CA should publish a policy that all subordinate CAs that issue EV must follow the EV guidelines. You also didn't ask about the other two trust bits (email and code signing). They don't have any specific audit, and Mozilla only has minimal requirements (see section 7 of the policy), but your CPS needs to cover what you do for validation prior to issuance. As far as I can tell, a root CA can apply without any issuing CAs, which makes reasonable sense, as issuing certificates that aren't recognized by browsers isn't a very functional business in most cases. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
