The proposal already includes maximum timeframes for revocation, with two weeks being the highest and 24 hours being the shortest, depending on the reason for revocation. Discretion is not built involved. I already agree that timely revocation should be required to prevent a bad acting CA from never revoking, but what timely means depends on the circumstances.
-----Original Message----- From: Ryan Sleevi [mailto:[email protected]] Sent: Monday, July 17, 2017 12:28 PM To: Jeremy Rowley <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] Revocation ballot On Mon, Jul 17, 2017 at 12:46 PM, Jeremy Rowley <[email protected]> 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
