On Tue, Feb 17, 2015 at 7:25 AM, Framarti francescomartin...@gmail.com 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
