[SSL Observatory] Tangent - coercibility of different authority structures

[Phillip Hallam-Baker]

On Tue, Sep 27, 2011 at 2:59 AM, Andy Isaacson <adi at hexapodia.org> wrote:
> On Mon, Sep 26, 2011 at 10:04:28AM -0400, Phillip Hallam-Baker wrote:
>> Your claim would be so much more credible if you would stick to the facts.
>> There are 20-30 CAs, not 100+. If you want to claim that there are more you
>> need to prove that there are more.
>
> It would be extremely helpful if you could make a counter-argument to
> back up your claim that the 900-ish sub-CAs discovered by the
> Observatory are actually controlled by only 30 or so organizations.

At root, the problem is that the distinction between a VRA and a LRA
is purely a matter of practices. So there is no way that the number of
CAs can be measured from the observatory results at present.

That does not excuse making a measurement that is known to give a
wrong result and then repeating it as fact in a political campaign.
John Gilmore has lost a lot of credibility with me in the past few
months. He knows that the '600' figure is faulty but he keeps
repeating it as evidence in his attempt to change the CA system.


The real problem is the VRA class. I don't know how to measure them at
present. However, at the time of writing I am not aware of any VRA
operating under the Comodo CAs. Nor do I think it at all likely that
we would agree to run one again in future. I can't imagine any other
major CA wanting to do that either. The risk just does not justify the
reward.

So an educated guess would put the number of validation points ('CA's)
in the system right now at 20-30.


I am rather less worried about measuring that number right now than
minimizing it. The RA class was intended to support the enterprise LRA
model. I don't think the browsers ever imagined that RAs would act as
unaudited CAs.

[Yes I know that an audit does not mean much, but without an audit the
security policy means absolutely nothing at all]

> I'd certainly rest somewhat more soundly to learn that.
>
> Some of the groupings are very obvious, such as the DFN set.  Others are
> probably obvious to people who follow the industry (such as yourself).
> Others may be very enlightening to explore the relationships between...

That would be commercially sensitive info and I only did operations on
a very occasional basis.


> What about Enterprise CAs?  Supposedly some large corporate customers
> get their own HSM, on site, containing a sub-CA, and the administrative
> systems around the HSM are intended to prevent it from issuing
> certificates outside of the authority delegated by the CA vendor.  I've
> never seen an example of a certificate issued by such an enterprise CA,
> though, so it's pure fable to me currently.  I'd be delighted to hear
> any light you can shed on that matter...


That is a model that has been proposed from time to time. I am not
aware that it is practiced on any great scale for SSL certs. It is
practiced on a large scale for S/MIME certs. It is also done for EMV
and the like.

For SSL certs, even the very largest accounts are going to be buying
certs by the thousand rather than the hundred thousand and even at a
hundred thousand there is really little advantage to having a crypto
HSM on site and a whole heap of disadvantages.


I can't see that operating the signing unit is going to be a
bottleneck for any CA. So having the customer operate the HSM just
means additional risk for the CA without an actual decrease in running
costs as the CA center is a sunk cost regardless of the capacity it
runs at.


-- 
Website: http://hallambaker.com/