<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 11:23 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Apr 18, 2016, at 11:16 AM, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> wrote:<br>
> I don’t understand your comment about stalling – in fact, I don’t even understand why we need this ballot now.<br>
><br>
> Peter, is there some pressing need for us to consider your ballot at this time?  To be blunt, it’s pretty abstract, and I’m not sure I understand it all (or where it came from).  Why do we need this general statement?<br>
<br>
</span>I was not proposing any ballot at this time.  I’m trying to get a sense whether there is any general agreement of scope rather than negotiate with each trust store.  We know that Mozilla is working to update their policies, Microsoft is continually refining theirs, and I suspect several other major trust stores are also working on new/revised policies, so it is my preference to get alignment from all ahead of those changes.<br>
<br>
The alternative is to have each trust store maintainer define their own independent policy then attempt to comply with the disparate policies and cajole the maintainers to modify their policies to make concurrent compliance practical.<br>
<br>
Thanks,<br>
Peter</blockquote><div><br></div><div>Kirk,</div><div><br></div><div>To add to this: There is an immediate and real security risk from CAs that, for example, are signing alternative types of certificates from intermediates capable of TLS issuance. That is, for example, issuing S/MIME and TLS certificates from the same intermediate.</div><div><br></div><div>Microsoft's newly released program requirements expressly forbid this for existing CAs, beginning Jan 1, 2017. Mozilla's requirements, as Peter mentioned, are similarly in process of being updated. This is a real security risk that puts users at risk, Kirk - thus it is extremely important for the Forum to set appropriate guidance and clarity regarding the intended scope of the document.</div><div><br></div><div>Explicitly, this is not related to the Forum scope, and I remain surprised to here you suggest it is. It is about the scope of the document, and the audits, and the security requirements. We've already seen one security incident where a major CA was issuing "test certificates," which they believed were outside the scope of the Baseline Requirements, and in doing so, led to misissued certificates for critical websites.</div><div><br></div><div>I should hope this need is recognized by all members interested in ensuring that the CA ecosystem does not suffer yet another substantial setback due to an entirely avoidable, entirely predictable security problem.</div></div><br></div></div>