[cabfcert_policy] FW: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements

[Ben Wilson]

Also for discussion --



From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Wednesday, March 1, 2017 2:06 AM
To: Dimitris Zacharopoulos <jimmy at it.auth.gr>
Cc: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements







On Wed, Mar 1, 2017 at 12:43 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr<mailto:jimmy at it.auth.gr>> wrote:

   On 1/3/2017 10:22 πμ, Ryan Sleevi wrote:





      On Tue, Feb 28, 2017 at 11:36 PM, Dimitris Zacharopoulos via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:

         Perhaps changing the "Root CA Certificate" as "A CA Certificate in which the Public Key has been digitally signed by its corresponding Private Key with the intention to be distributed by Application Software Suppliers as a trust anchor". Would that work?



      I think this would be a step in the wrong direction. As we know from the discussions about the scope of the BRs, "intent" is something that is hard to audit and hard to document. We should avoid such definitions, and focus on clear technical definitions.



   I agree with the general concept but this is a special case because when you perform a Root Key Ceremony, the CA Certificate is not part of any Trust store. Any language that would make this better is welcome.



   Always require the auditor to attest that any Key Pairs, for any CA Certificate, be accompanied with a Qualified Auditor attesting that the CA followed its Key Generation Script.



   Would we really want to have a process where a Key Pair is generated using means that no one independently verifies as compliant with either the Key Generation Script or the CP/CPS? That's how you end up with a rogue sub-CA (for example, failing to take appropriate protections for the generated Key Pair)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/policyreview/attachments/20170427/46fb8b2c/attachment-0001.html>