[cabfpub] Misissuance of certificates

Ryan Sleevi sleevi at google.com
Fri Dec 11 18:23:52 MST 2015


On Fri, Dec 11, 2015 at 5:10 PM, Rick Andrews <Rick_Andrews at symantec.com>
wrote:

> Ryan,
>
> Today, we and other CAs issue certificates to customers for use both (a)
> publicly and with browsers, and (b) privately on internal networks and/or
> with non-browser applications. Currently, these certificates all have a TLS
> serverAuth EKU, all are in-scope with the BRs, and all comply with the BRs.
> They all are issued from roots that appear in browser and OS trust stores.
>
> However, we believe that if a CA issues a certificate (1) with a TLS
> serverAuth EKU, that (2) chains to a root that is not in browser or OS
> trust stores, then those certificates are not in scope nor need to comply
> with the BRs. We’ve discussed this before in the CA/B Forum and there seems
> to be consensus among the Forum members, including auditors.
>

Right, I think we're very much in agreement here.


>
>
> The issue that we’re raising here is that today the same roots, those
> trusted by browsers, are used for both public and private applications.
> This creates unnecessary complexity and delays in moving initiatives in the
> CA/B Forum forward as we have to solve for both the public and private use
> cases. What we’re recommending is finally to make these use cases clearly
> distinct for customers (clearly using different roots for the public vs.
> private cases and the clarifying the implications of choosing one vs. the
> other) and to provide a transition period to do so.
>

This is where I'm confused again. It sounds like we're in agreement that
regardless of (a) or (b) [which is a question of intent], these
certificates are in scope of the BRs. We also know that, again, regardless
of (a) or (b), misissuance events affect browsers and OS trust stores -
since a priori, we know that the certificate chains to a browser or OS
trust store.

What leaves me confused is what we are meant to transition from or to, and
why that is or isn't necessary.

Let's explore the hypothetical where we say that we're dealing with (b), it
chains to a public root, and the CA/B Forum adopts a resolution requiring
all misissued certificates be publicly disclosed (to oversimplify
Sigbjorn's proposal). That would not affect (b)'s existing certificates
(which we've established all conform to the BRs), nor would it affect (b)'s
new certificates, provided they continue to conform to the BRs.

It only becomes an issue if a (b) certificate is misissued.

Is that a fair understanding so far?

If so, then any plan of transition is really just where the burden of
cost/risk is borne. We're between a tradeoff where we're arguing that (b)
would really prefer to keep their misissued certificate private. However,
it chains to a public root, and we don't know whether (b)'s misissued
certificate affects others - perhaps it's a certificate for www.google.com,
for example. So we have, on the one hand, (b)'s self-interest, and on the
other hand, the public's interest (for which the browsers and OS trust
stores attempt to represent)

It sounds, and perhaps I'm misstating, that you're suggesting that (b)'s
interests are greater/more important than that of the public, therefore we
should phase in a transition plan that allows (b) to hide the misissued
certificate from the public until such a time that they're no longer
subject to the BRs.

Given that this issue only arises when a certificate is misissued, isn't
the way for (b) to keep their certificates undisclosed to ... not misissue
and not violate the BRs? And if they do - whether accidentally or on
purpose - realize that as a part of that violation, they no longer get to
enjoy the benefits of hiding from public scrutiny?

It would sound like you're suggesting that (b)'s interests in privacy are
greater than the public's interest in transparency and security, and if so,
I think we've at least found the root cause of disagreement. I think we're
very much in agreement that (b) should follow the BRs, and that if (b)
doesn't, they should be on a non-public root (one that, for the safety and
security of the Internet, would ideally never have been trusted nor
actively trusted), but in either event, this seems like an issue that is
predicated on there being a misissuance event, which itself should ideally
never happen.

So why wouldn't we just implement immediately - which recognizes that the
public's interest of security and privacy outweighs a lone individual's
business interests - and realize the conflict will only arise in an event
that should never arise?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151211/5d81da0d/attachment-0001.html 


More information about the Public mailing list