| It's a fair criticism to say that I've not said anything on the implications of distrust but that does not mean I've not considered that at great length. More on that in a moment, but first let me say a few words about my style. Generally I prefer not to waste time on matters that are of little interest to others. This usually means I end up making vague comments or putting ideas out there in order to gauge interest and then go from there, as I have time available. Sometimes people are interested, sometimes not, and sometimes I get a different response entirely. To some extent I understand that and accept the consequences, but there are still times where I wish there could be fewer you-don't-know's and more have-you-considered's.
With that said, let's talk about removing trust from root certificates. For my purposes here I've adopted the standpoint of an end user--the Relying Party as it's called in CPS docs. Most CPS docs I've reviewed essentially state that it's up to the relying party to make the ultimate determination of when to trust a cert.
So how does a relying party go about making that determination? What steps can the end user take to better inform himself or herself before extending trust? Here are some mechanisms I've been considering:
* Presence of the root in a trusted root store: Presumably if a root is included, it's deemed good enough by some and is a "known quantity" (this, in comparison to some self-signed cert that nobody has seen before). If I really wanted to do so, I can always check the root store myself and see that the root is, in fact, listed.
* Technical checks: If the certificate checking software successfully validates the cert chain, that is usually all the evidence I need to know I can trust the cert. I can be sure that these checks are performed as best they can be by making sure I'm using the latest version of that software. Still, the software can't check everything (e.g. certs with duplicate serial numbers) so other checks on my part might be necessary.
* Revocation: If a particular cert has been revoked for any reason, I should be able to find that out so that I will know not to use it. Ideally this is handled automatically in software but for various reasons it doesn't always work out that way. I'm not sure if the manual tools are all that robust (or exist?), but that almost doesn't matter because I'm dependent either way on the issuer of the cert to issue the proper revocation. In the case of WoSign, there are documented cases where certs were issued improperly. (I'm not sure if we have documented cases where revocations were made improperly?) * Adherence to Policies: I'm thinking of the Mozilla policies on root inclusion, though others apply equally well. I can take some comfort in the knowledge that they exist and that Mozilla does a good job making sure the CA's continue to be in compliance. In the case of WoSign, we now know that they were in violation of the ownership policy and lied about it for almost a year. That's pretty bad so I really have to question the knowledge, understanding, and commitment that WoSign has in complying with the spirit and the letter of the other Mozilla policies. (Note that I've lost track a bit on where things are with policy compliance and I don't wish to give this any greater bearing than is warranted.) * Adherence to Specifications: The primary specifications are, of course, the CABF BR's but I imagine there might be certain RFC's that come into play as well. As a relying party, there is little I can do but to trust and presume that the auditing and reporting process ensures that the cert issuer is compliant with the relevant standards, specifications, and best practices. Unfortunately in the case of WoSign, we now know that there are multiple cases of non-compliance *and* we know that the auditors did not identify those problems during the audit process. (I'm not sure if it's clear how much of the blame here belongs to WoSign or the auditing team?) * Internal Controls: There are, no doubt, policies internal to WoSign (and every CA) regarding their business operation as well as the development, testing, deployment, and maintenance of their various software systems. Typically, as a relying party, the best I can do is trust that the audits have found no major gaps within the CA. Unfortunately in the case of WoSign, we now know that the auditing process was broken so now I have to wonder what gaps might actually exist that have gone undetected, unidentified, and/or unreported. (Again, I've lost track if any issues regarding WoSign systems have been identified, though I personally would include the debacle that StartCom had when they launched their alternative solution to Let's Encrypt--the name of which I've forgotten. The rush to production of an obviously flawed system clearly points to a lack of testing before its deployment.) So here's the point I wish to make: If I'm presented with a certificate issued by WoSign and I'm told I have to decide for myself if I should trust it, I really don't see how I have any choice but to refuse to trust the cert even though my cert validation software might say it's OK. The above mechanisms available to me as an end user seem to be hopelessly compromised by WoSign's actions over the past 10 or so months. Admittedly this is a lot to throw out at once and I know I've probably made mistakes or misstatements that don't quite square with the ongoing investigations or "findings of fact", if you will. I've probably overlooked something as well. I hope people will correct me or ask for clarifications where needed. I also recognize that I've still said nothing about the impacts that removing trust has on the cert holders (website operators, mostly). Doing so is a deliberate move on my part just to keep this particular message of manageable size and scope. I'd be happy to discuss those impacts at another time. Finally, I fully acknowledge that any decision to remove trust from a root certificate creates a significant disruption to the PKI ecosystem and the Internet as a whole. It is not an action to be taken capriciously but only after very careful consideration and thorough discussion. It's good that we have had and continue to have these discussions here in this forum. ________________________________________________________________________ On 22/09/16 03:00, Peter Kurrasch wrote: > Well, well. Here we are again, Ryan, with you launching into a bullying,
> personal attack on me instead of seeking to understand where I'm coming
> from and why I say the things I say. Er, no. I am entirely comfortable with saying that if you found Ryan's
message to be a bullying, personal attack then your skin is too thin. (Which would surprise me, given what I know of you.) Ryan's message, while possibly carrying a slightly exasperated tone, was
a reasonable exposition of the trade-offs inherent in various options for dis-trusting a CA, trade-offs which you seem unwilling to recognise.
I'm sad that you don't see this as a set of trade-offs, but perhaps there's little I or Ryan can do about it. > If Kathleen or Gerv or Richard decide that I'm > disruptive and not providing any value to the wider population, I'll
> happily withdraw from this forum. I am not requesting that you withdraw, although you should know that the
level of account taken of what you say is approximately proportional to
the level of understanding that you show of the perspectives of all parties involved - including those currently using WoSign certificates
for their sites. Gerv |
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
