[cabfpub] Revocation ballot

[Ryan Sleevi]

On Mon, Jul 17, 2017 at 12:46 PM, Jeremy Rowley
<jeremy.rowley at digicert.com> wrote:
> I don't think we get to make that false equivalency, certainly not with how the certificates work.
> [JR] This is probably the crux of the discussion.  Why do you feel this is a false equivalency? It's a vulnerability associated with the product shipped by an entity. The CA, as the service provider, seems obligated to help remediate it.

I think it's clear you're seeing it as a product - I'm sure, in part,
informed by some of your customers directly baking the certs and keys
in. But from the point of view of a browser, or a relying party (e.g.
browser user), it's a break of the fundamental assurance of TLS in the
Web PKI - that only the intended party can receive the communication.

The view of "exploited" doesn't align with, for example, a
non-forward-secure ciphersuite negotiated with the key. In those
cases, it may be 'exploited' retroactively - and so because of this,
it's logical to stay it was exploited from the moment the key was
known to be compromised. Even if the server was using solely
forward-secure algorithms, without a form of binding the individual
channel (which does not work on the Internet at large for a variety of
reasons, including a number of members' security products), then you
can't show that the connection _wasn't_ exploited.

Because this is about the communication channel itself, and the
assurances, the idea of applying an exploit-oriented mindset doesn't
hold up with how it works.

> a) If an online transaction was performed, and it was disputed and not reversed, then DigiCert is liable
> b) If something else was performed - for example, the act of signing in - DigiCert is disclaiming liability
> [JR] If we updated our relying party agreement and removed disclaimers on liability, you'd be happy with the modification?

I noted in the original message, although further below, this is not
something that can, from a technical or legal perspective, be
addressed by 'increased liability'.

> I think we're in agreement that, given the nature of the ecosystem, the target state to be moving towards is to enable and allow the prompt and timely rotation of keys, for both emergency and non-emergency situations, correct?
> [JR] Yes. We are in agreement that this is one of the goals, but I think we disagree on whether giving certificate holder's time to remediate an issue is also a goal.

As you note, there are circumstances where no such remediation time is
needed. As such, we'd rather see the system optimized for that - the
scenario of rapid transition - because it ensures it will work
robustly for all situations. The bifurcation of these is what creates
risks - because neither browsers nor relying parties would have the
necessary technical assurance or remedy that the situation was
appropriately triaged.

> How do you propose to discover active exploitation? The math is indistinguishable to all participants but the Subscriber, and even then, it's questionable.
> [JR] Only for publicly disclosed compromised keys. There are many other reasons for revocation under the BRs.

So if a Subscriber violates a Subscriber Agreement, your view is that
the CA should be allowed to use its discretion to not revoke?
If a CA issues a certificate to a non-existent legal entity, your view
is that the CA should be allowed to use its discretion to revoke?

There is no incentive structure for timely revocation. That
discretion, however powerful, has zero incentive structure for timely
action, and the original proposal would have allowed for this to
continue indefinitely.

To be fair, if this is a view we want to go down - that the only thing
you can rely on in a certificate is that the domain name is bound to
the key - I'm fully supportive of this. However, to mitigate the risk
and confusion to the market, that would naturally have to come with a
prohibition on including any additional information beyond the domain
in the certificate - since that would be untrustworthy information
that subscribes and relying parties have come to rely upon. It will no
doubt take several decades of active engagement for CAs to retrain
users not to expect this information to be trustworthy, so the only
viable solution until that retraining has happened is to prevent it
from appearing.

Like I said, would be more than ecstatic to go down that route - of
only allowing DV. Yet if that's not the world we want, and we want
Relying Parties to put faith in the information presented, then we
need to provide the same level of assurance that such information is
bound to the key as we do that the domain is bound to the key.

> Then it sounds like they will be disproportionately affected if they publish their key on GitHub. I don't see a reasonable argument to increase the risk to all Relying Parties (by virtue of relaxing requirements for all certificates) in order to satisfy the incentives of those who do not automate.
> [JR] Okay, but another example. Suppose the company moves and forgets to update their certificates as part of the process? 24 hours for revocation (because the address is now misleading), seems unreasonably tight.

If we believe the address is as meaningful as the domain, it's not
unreasonably tight - it's a common level of assurance.
If we believe the address it not meaningful, then I agree. But we
should solve that by not including the address.

> [JR] I disagree. The concern is the impacted relying parties who are being distrusted by revocation. There's little incentive on the CA side.  Revocation doesn’t equate to a refund.

If revocation did equate to a refund, there would be even less
incentive. But under what model would a CA be inclined to revoke a
certificate? If the proposed language is adopted, it's stating
acceptable practice is to not revoke a certificate (CA discretion). If
Relying Parties disagree with the CA, there is zero consequence to
that CA. You propose to continue to require Subscriber-initiated
revocation, so Subscribers are still assured their needs are met.
However, in the balance between impact to Subscribers (loss of
customers) versus impact to Relying Parties (loss of the
confidentiality they believed they were getting, by virtue of the CA
certifying the certificate), there is every incentive for the
Subscriber to not want revocation, and to put their needs ahead of the
Relying Parties.

That's not good.

> But it does. They have reasonable assurance that their communications remain secure. The software vendor did not provide a way to ensure that, and as such, found it not working until it did.
> [JR] I think the opposite is true. They move to no certificate instead of a new certificate. Once the certificate is removed, there's little incentive to use a new certificate.

Of course, this is technically incorrect on a number of dimensions.
For example, if they were to use powerful features in the context of
the web, they'd get a new certificate. If they're mandated by a
regulatory regime (like PCI-DSS) to use encryption, they'd get a new
certificate. If they're wishing to avoid negative UI indicators,
they'd get a certificate. If they're, say, using an App and subject to
requirements like ATS (on Apple), they'd get a certificate.

In both today's world and the future that is rapidly approaching,
software vendors are working to ensure that the communication from
applications on their platform - whether web or native - are using
secure communications, with limited to no alternatives. So the option
of "no certificate" is not viable on a host of dimensions - and the
need to timely replace that certificate always exists.