[cabfpub] Misissuance of certificates

Ryan Sleevi sleevi at google.com
Wed Jan 13 18:11:18 UTC 2016


On Wed, Jan 13, 2016 at 6:02 AM, Sigbjørn Vik <sigbjorn at opera.com> wrote:

> > 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.
>
> This ballot would be part of the BRs, and the BRs only apply to
> certificates in scope of the BRs.
>
> Certificates not in scope of the BRs cannot be issued in violation of
> requirements in the BRs, so even if this ballot would not be part of the
> BRs, it would still not apply to certificates not governed by the BRs.
>

If a CA has been issuing certificates from publicly trusted roots, then
it's naturally within the public's interest to know about these.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160113/0d04dad1/attachment-0003.html>


More information about the Public mailing list