<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 6:02 AM, Sigbjørn Vik <span dir="ltr"><<a href="mailto:sigbjorn@opera.com" target="_blank">sigbjorn@opera.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="">> Our concern is also that the proposed ballot is somewhat unclear whether it applies only to certificates that are in scope of BR-s or all other types as well. If the latter is true, we might be facing several issues of disclosing personal information and violating local or other regulations with such disclosure.<br>
<br>
</span>This ballot would be part of the BRs, and the BRs only apply to<br>
certificates in scope of the BRs.<br>
<br>
Certificates not in scope of the BRs cannot be issued in violation of<br>
requirements in the BRs, so even if this ballot would not be part of the<br>
BRs, it would still not apply to certificates not governed by the BRs.<br></blockquote><div><br></div><div>If a CA has been issuing certificates from publicly trusted roots, then it's naturally within the public's interest to know about these.</div><div><br></div><div>This seems to be a case, similar to the one raised by Symantec, of a CA potentially issuing an unknown number of non-BR compliant certificates from a root that is required to be BR compliant. Perhaps the auditor failed to do their job in flagging these, perhaps this circles back to the need to make the scope statement in the BRs even more explicit for auditors, but it's certainly been true in the Root Programs themselves that BR compliant roots need to comply to the BRs throughout their hierarchy, and non-compliance is a root program violation.</div><div><br></div><div>I would definitely suggest a need to discuss with root programs, independent of any ballot here, if you have any body of certificates that are non-BR compliant and chaining to a BR-recognized root, to figure out what options exist. For example, it may mean that the existing root needs to fall out of BR compliance and auditing because the scope of misissuance is so significant that it's not resolvable, and the CA work to spin up a new root hierarchy that can and does comply with the BRs - including the potential disclosure provisions. I'm sure root stores would be happy to work with CAs that find themselves in such a significant-but-regrettable position.</div></div></div></div>