<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 1, 2017 at 12:43 AM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div class="m_1781538789454312119moz-cite-prefix">On 1/3/2017 10:22 πμ, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 28, 2017 at 11:36 PM,
Dimitris Zacharopoulos via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span>
wrote:
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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? <br>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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) </div></div></div></div>