<p dir="ltr"><br>
On Mar 14, 2016 9:17 AM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br>
><br>
> I disagree that the methods Dean has proposed for making the interim SHA-1 certs untrusted will not work.</p>
<p dir="ltr">And how will this solution protect users on systems that have never checked revocation - such as the vast majority of critical infrastructure online in server to server communication?</p>
<p dir="ltr">The libraries available in nearly every major programming language have no such capabilities. Servers behind firewalls prevented from egress traffic. Mobile devices for whom battery drain - and bandwidth costs - are real concerns. Previously, proponents of SHA-1 extensions argued the impact to the developing world - but all of these solutions proposed foist the cost from the CA and organizations responsible for this problem onto browsers and users - users whose access to critical needs would be impaired by the costs you suggest they should bear.</p>
<p dir="ltr">This is why the need for public debate is high - let there be no question, the cause of this is either the CA or the organization being lax in their duty. They are now coming to ask the world at large to subsidize their mistake - after so many other organizations, many in competition with those now asking, spent considerable time and effort to prepare.</p>
<p dir="ltr">>  For example, issuing and immediately revoking will make the certs untrusted.  If some browsers no longer check certs for revocation, it is the decision to abandon revocation checking that creates any security vulnerability for users, not the cert itself – and that vulnerability exists today even for SHA-256 certs that have been revoked for misissuance, misuse, etc.  If the browsers are treating revoked certs as “good” when serving content to users, that’s a totally different security issue. </p>
<p dir="ltr">In bringing this up, you have both missed and made the point as to why this solution does not work. The number of clients who check revocation is miniscule - browser and non-browser alike. What you describe as a solution has no basis in the real world, merely the idealized world you might wish existed. That's the sort of trade-off discussion to be had - because as a solution, it does not work.</p>
<p dir="ltr">Further, let's be clear - the solution is to immediately recognize the certificates as untrustworthy. That is, the CA would actively be engaging in untrustworthy behaviour. Surely, for an industry based on trust, you can understand why this is damaging.</p>
<p dir="ltr">But perhaps the most important matter is that this obviously does not work. I realize you may be more familiar with the business aspects of trust than the technical, but I encourage you to re-read the work on the MD5 collision on RapidSSL/Symantec. In that, the attackers were able to change the serial number in the malicious cert. As I am sure you are aware, the serial number is how a certificate is revoked - and attacker who can change the serial number creates an irrevocable certificate.</p>
<p dir="ltr">That's why this suggestion has no merit on technical grounds. It simply doesn't provide the protection necessary. Now, we could discuss ways that the CA could make it harder for an attacker, but that again presumes no colluding insider and perfect operational execution. While we have no public evidence of the former, in this day and age we cannot discount it, but in the case of the latter we have ample evidence of CAs' inability to achieve this - as shown by CRT.sh.</p>
<p dir="ltr">> Likewise, browsers can add these interim SHA-1 certs to their CRLsets list, and users will be protected.  If I understand correctly, the WorldPay case only involved 8 or 9 certs total, so this is not a great burden on the browsers.</p>
<p dir="ltr">And yet again, this is not at all a viable solution - on technical grounds. Nor does it scale to protect the ecosystem - doing real harm to non-browser-but-public trust use cases (e.g. in consuming API services from sites also intended to be accessed from browsers - as in, what enables vast amounts of online commerce and functionality)</p>
<p dir="ltr">> I still don’t see how Forum members can evaluate any special pleading from an applicant who needs these interim certs – I assume in all cases applicants can’t update their devices, so the devices will go dark if they can’t get an untrusted SHA-1 cert for the next 90 days, etc.  What other information would you want?</p>
<p dir="ltr">Again, you can find a list of questions that serves as the basis for a meaningful discussion. Absent that, there isn't really the option to discuss further.</p>
<p dir="ltr">> Finally, this situation really illustrates that we should NEVER again create split dates for changes in requirements, where there is an early end date on issuance of some type of cert, and a later “last validity” date.  In this case, we should have made December 31, 2016 the “last validity” date only, and CAs should have been allowed to issue up to that date (even be able to issue a one-day cert on December 30, 2016).  That will get the attention of customers – when they apply on May 1 and are told they can only get an 8 month cert, customers will understand the deadline is real and approaching, and we won’t face the argument “I could have gotten a one-year cert on Dec. 31, but can’t get any cert on Jan. 1 – that makes no sense.”<br>
></p>
<p dir="ltr">I'm sure if you consider this proposal further, you will realize why it does not work. A split date is always inevitable - because you have the day before the effective date of the ballot and the day after. To truly avoid the situation you suggest, we would have to set the effective date to be the max of the validity date at time of issuance, times two (or 78 months) - 39 months for the "issued under the old rules" certs to expire, and then another 39 months to transition the new rules into place. Perhaps if the validity of certs was limited to, say, 9 months, this would be potentially workable, but even then, the Forum must be prepared to transition rapidly in times of security crisis.</p>
<p dir="ltr">The responsible thing for CAs to do would have been to implement the plan you suggest, and not allow them certificates expiring past 1/1/16 (not 17 - the risk is real today, as research has shown). Certainly, browsers like Chrome and Firefox made efforts to assist in bringing awareness, doing as best they could something similar to what you propose - but it seems the problem cases that remain are the ones where they were the CAs' customers, rather than the browsers' - which makes me wonder if perhaps that helps identify how this problem came to be and where the problem lies.</p>
<p dir="ltr">And that's why the need for the case-by-case basis, and the questions I posed - we can only do better in the future if we have a better understanding of why some CAs and sites did so badly in the present. Proposals such as yours will be needed, so that in the future we can do better at preventing these sorts of things. I think it is fantastic that you are looking forward to the next steps - but I don't believe we can reasonably do that unless we understand the present. And to do that requires data, which requires meaningful, direct, honest, and unencumbered interaction with those affected - so that we can truly understand the situation.</p>