[cabfpub] Reporting on new CAs created between audit reports

[Peter Bowen]

There has been some discussion in a couple of different forums about how CA operators should report on new CAs they create.  This is especially relevant given that the multi-vendor SalesForce system that several trust stores are using to track root and subordinate CAs expects a link for an audit report that covers each root or subordinate CAs.

One idea, proposed by Kathleen at Mozilla, is to require a Point-in-Time (sometimes also known as a Type I) audit for each new CA.  While this sounds good, in discussion with several auditors I know, it was pointed out that this would likely cost thousands of dollars and a reasonably busy CA could end up with auditors being onsite perpetually.  It also has the disadvantage of requiring a significant delay between creation of the CA and being able to get clear declaration of its intend to conform to the BRs, as it takes auditors a while to issue reports.

I propose an alternative.  Whenever a new CA is created, the management of the CA would publish a signed assertion that covers the key details, including the key generation and a commitment to continue operation of controls.  This would be similar to a “bridge” or “gap” letter published by an organization related to other types of audit reports.  The next audit report would then contain the CAs in question along with their data if activation/creation, allowing a reader to have assurance that the controls were in effect.

I’ve attached a draft of some sample letters.  These try to show various ways one might write such a letter and cover the various scenarios that might occur (new root vs. non-root, operated by an affiliate of the root or not).

Do others think that this is a viable path?  Would this provide the level of transparency and assurance that trust store operators want?

Thanks,
Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CA Creation - Management Assertion.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 117810 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160923/3da206b8/attachment.docx>