[cabfpub] BRs, audits and historical point-in-time events

Ben Wilson Ben.Wilson at digicert.com
Tue Jul 22 17:10:03 MST 2014


Of course, other scenarios that might occur include:  the event was recorded,  but the video recorder malfunctioned, or the CA thought the auditor/third party witness met the requirements, but then discovered the person was not a "Qualified Auditor".

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Tuesday, July 22, 2014 6:02 PM
To: Gervase Markham; cabfpub
Subject: Re: [cabfpub] BRs, audits and historical point-in-time events

I may be missing the issue, but I would point out that BR 17.7(2) requires the CA either to " have a Qualified Auditor witness the Root CA Key Pair generation process" OR to "record a video of the entire Root CA Key Pair generation process".  (Sub (1) requires the CA to follow a script.)  Then sub (3), as a separate matter, calls for the CA to "have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair."

If an auditor is able to issue the sub (3) opinion based on the script and video, that would seem to be sufficient -- perhaps no need for the auditor to have been there, and this opinion could be prepared long after the fact.  But if the script and/or video don't exist, that's a problem.

I'd also go to the Mozilla communications to CAs concerning Mozilla's date of enforcement of the BRs -- as I recall, it was something like starting Feb. 15, 2013.  If the root was created before that date, there was no actual requirement to comply with the BRs by any root program, despite the BRs stated effective date of July 1, 2012.  (There was lots of discussion about this at the time.)  However, BR 8.3 calls for a CA to publicly commit to BR compliance in its CPS -- did CA Foo publicly commit to following the BRs when it cut the root?  If yes, it should have followed 17.7.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Tuesday, July 22, 2014 6:59 AM
To: cabfpub
Subject: [cabfpub] BRs, audits and historical point-in-time events

The following situation in regard to the BRs recently arose. What is the wisdom of the group?

* Ca Foo, Inc. wishes to include their root in Mozilla products.

* By Mozilla policy, this requires an audit to check they are following
  the BRs.

* CA Foo's auditors are Bar Audit Corp.

* Some time in 2012, CA Foo created a root.

* Bar Audit Corp audited that root creation process according to
  WebTrust 2.0 and WebTrust for EV 1.3.

* However, they did not audit it according to the BRs.

* The BRs require, in section 17.7, that all roots created after 1st
  July 2012 meet certain procedural criteria.

* However, Bar Audit Corp can't go back and reaudit a one-time event
  according to different criteria.

* How then can CA Foo pass its BR audit?

To generalise, the problem is that the BRs require something which is difficult to do in retrospect if you didn't do it at the time - which may be because you didn't even know about the BRs or that they were relevant to you. How do we handle that?

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
</pre></td></tr></table>

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public


More information about the Public mailing list