[cabfpub] Reporting on new CAs created between audit reports

[Peter Bowen]

> On Sep 30, 2016, at 8:48 AM, Gervase Markham <gerv at mozilla.org> wrote:
> 
> On 23/09/16 21:01, Peter Bowen wrote:
>> Do others think that this is a viable path?  Would this provide the
>> level of transparency and assurance that trust store operators want?
> 
> I discussed this with Kathleen. I made the point that:
> 
>> I can sort of see Peter's point - if CA Foo has 12 HSMs lined up
>> in their data centre, with unconstrained intermediates in them, and it
>> creates a 13th one and adds it to the rack (perhaps for scaling), that
>> seems like a different situation to "OK, I have a new data centre, new
>> staff, new controls, and here's my new subordinate I'm going to issue from".
>> 
>> Throwing out ideas: can we find a way of saying that if the new
>> intermediate is kept in basically the same conditions and under the same
>> controls as an existing one, then a letter attesting to that fact is
>> sufficient, but if there are variances, an audit is required? Can we
>> make a line here bright enough to be useful?
> 
> And Kathleen replied:
> 
>> Yes, I think that would work. Thanks!
> 
> So is there some way we could work towards that?

I think so.  To clarify further, in many cases creating a new subordinate CA means using the exact same existing HSM but just generating a new key on it.  For example, the Gemalto SafeNet Network HSM has 2MB of key storage.  As a 4096-bit RSA key is less than 1KB stored, such a HSM can store at least 2000 CA keys.  Additionally it was pointed out to me recently that subordinate CAs could even share keys as long as each CA has a unique Distinguished Name and Key Identifier.  This is useful if the other attributes of the CA change (for example updating a policy identifier or constraint).

Thanks,
Peter