Re: How to become a trusted root CA for SSL Certificates

[Peter Bowen]

On Tue, Feb 17, 2015 at 7:25 AM, Framarti <francesco...@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

[Peter Gutmann]

Framarti <francesco...@gmail.com> writes:

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

>2 - Submission to a third party Audit (i.e. vs WebTrust program, baseline and
>for publicly trusted certificates);

Depending on where you're starting from, that step is going to cost you
somewhere around a million dollars and take at least a year of work to get
through. That buys you an awful lot of certificates from a commercial CA at
$5/year.

Peter.

[Anne van Kesteren]

On Tue, Feb 17, 2015 at 4:25 PM, Framarti <francesco...@gmail.com> wrote:
> I'm not really sure about needed activities.

https://wiki.mozilla.org/CA:How_to_apply has guidelines. It's a fairly
extensive process.


--
https://annevankesteren.nl/

[francesco...@gmail.com]

Hi Peter,
thanks for your support. I'll try to argue to some parts of your answer.

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

Yep, what i think is that the secure offline facility for HSMs is mandatory for Sub-CAs as well from WebTrust Program (as well as DR site). I imagine that sub-CA's certificate issuing topic can be avoided by simply issuing only end-user certificates (restricting the business).

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

EV requirements actually are a bit of a problem. A quick win could be to keep restricting the business, avoiding to issue this problematic kind of certificate.

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

Yes, these parts are not directly covered by WebTrust program or, at least, they're included in general baseline requirements.

So, restricting business to DV and OV end-user certificates, the inclusion of a root- CA certificate in the browsers should not differ so much from a trusted sub-CA: same third party audit requirements (webtrust)and same requirements (CPS, HSM's managements, private keys management issues...). The only big difference is that root-CA certificate is self-issuing and self-signed, the sub-CA is trusted by a root CA. What do you think?

Francesco

[francesco...@gmail.com]

mmm i don't think it's the correct amount. As long as i know, obtaining a report (and relative seals) for Baseline v.2.0 and SSL criteria 2.0 should cost you around 100K dollars. Obviously not considering the money needed to fill any eventually emerged gaps from the standards (i.e. buying HSMs). If i didn't understand you, please correct me.
Francesco

[francesco...@gmail.com]

Thanks for your contribution, it will probably help me.
Francesco

[Peter Bowen]

On Mon, Feb 23, 2015 at 9:49 AM, <francesco...@gmail.com> wrote:
>> 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.
>

> Yep, what i think is that the secure offline facility for HSMs is mandatory for Sub-CAs as well from WebTrust Program (as well as DR site). I imagine that sub-CA's certificate issuing topic can be avoided by simply issuing only end-user certificates (restricting the business).

I was under the impression that most Subordinate CAs are online, as
they issue end-user certificates. I don't think many CAs are doing
hand carry of end-user certificate requests and certificates between
their online systems and their signers. On the other hand, I hope
that this is what happens for all Root CAs.

> So, restricting business to DV and OV end-user certificates, the inclusion of a root- CA certificate in the browsers should not differ so much from a trusted sub-CA: same third party audit requirements (webtrust)and same requirements (CPS, HSM's managements, private keys management issues...). The only big difference is that root-CA certificate is self-issuing and self-signed, the sub-CA is trusted by a root CA. What do you think?

Yes, I think the main difference between Root CA and Subordinate CA is
1) the key generation procedure and 2) the airgap/isolation.

Personally, I think it would be interesting to see a CA setup where
the Root CAs have independent CPS from the Issuing CAs, even if owned
by the same company. However, I suspect this would drive audit costs
up, meaning no one would do it.

[Peter Gutmann]

<francesco...@gmail.com> writes:

>mmm i don't think it's the correct amount. As long as i know, obtaining a
>report (and relative seals) for Baseline v.2.0 and SSL criteria 2.0 should
>cost you around 100K dollars. Obviously not considering the money needed to
>fill any eventually emerged gaps from the standards (i.e. buying HSMs). If i
>didn't understand you, please correct me.

That's like saying that getting a safety-code compliance certificate for a
building will cost you $5,000 and take about a day. That may be the cost of
getting the piece of paper, but the remedial work required to get to that
point could be half a million dollars and take a year of effort. It's the
same with getting to the point of getting the paperwork to get into the root
stores, the rule-of-thumb figure I've heard thrown around is $1M and a year's
work:

As a rule of thumb to help you estimate the amount of legal and procedural
work involved, for a CA providing general services to the public (either
directly or indirectly, for example as part of a government department or
one providing services for multiple different parties outside your direct
control rather than being purely a non-public or in-house CA), expect to
spend about a million dollars (or euros, or pounds, or zorkmids, the figure
of “one million” is rather consistent across currencies) on legal and
business issues including due diligence, preparing the certificate practice
statement (CPS), and being audited to ensure that you’ve got it right. As
one set of PKI guidelines puts it, “given that the principal product sold by
a CA is ‘trust’ there is a critical requirement to be able to demonstrate a
thorough understanding of the security threats faced by a CA” [ ]. If you
ask your lawyers about this they’ll tell you that the best way to limit your
liability is to get everyone involved to agree that they won’t use your
certificates for anything, and then the business people need to negotiate
back what they can actually be used for, as little as possible if the
lawyers can help it.

For a CA of this kind you should expect the legal side of things to occupy
two technical people (to educate the lawyers) and four to six lawyers full-
time for around six months, and then budget another six months to clear the
paperwork and wait for all the approvals to go through. If someone tells
you that they can set up your PKI for a lot less than this when your
certificate practice statement is anything more complex than “You can’t use
these certificates for any purpose and we accept no liability for anything”
then this should ring alarm bells (although some CAs claim to provide
liability cover, this is structured in such a way that the CA never has to
pay out under any conceivable real-world scenario, with one CA admitting
that their liability cover is “really there just to reassure you that it’s a
true 128-bit certificate, and to make you feel better about purchasing it” [
]). The details of the requirements for a PKI of this scope are far too
complex to even begin to address here except to warn that it’s a big one. If
you’re looking for a starting point for this then chances are that your
national government or other governing body (for example a banking standards
body or regulator if you’re a bank) will have some sort of PKI guidelines
that you can use.

Peter.