On Friday, September 23, 2016 at 6:03:01 AM UTC-7, Peter Kurrasch wrote: > * 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?)
Note: In pretty much all major software, automatic revocation doesn't work under an adversarial threat model. That is, you can consider two types of misissuance: Procedural misissuance (perhaps it states Yahoo rather than Google) and adversarial misissuance (that is, someone attempting to impersonate). I'm handwaving a bit here, because it's more of a spectrum, but we might broadly lump it as "stupidity" that causes insecurity and "evil" that causes insecurity. Stupidity is important/relevant to trust decisions, to some extent. However, in practice, I doubt you're examining each certificate presented to you on each connection *before* you send data on that connection, which is what the CPS's are worded to suggestion, so it's unlikely you're making major trust decisions on the basis that the certificate says it was for "Yahoo" So you're most likely concerned about 'evil' misissuance - those that an adversarial attacker is attempting to gain access to your private communications. And it's under this model that revocation doesn't work, due to the attacker's ability to perform various exploits (such as blocking communication to revocation servers, or stapling an OCSP GOOD response). For this reason, I would encourage you not to think of Revocation as an important factor of trust. I agree that you want to know if a certificate is revoked in the abstract, and if we have reliable solutions that can help facilitate that (e.g. OneCRL or CRLSets are more reliable means of revocation), then great, but we're not at a place yet where revocation is an intrinsic part of the secure connection establishment. > > 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. You missed some other additional characteristics to consider, and ones that I think significantly affect the conclusions made. The first is a consideration of risk. The decision to trust or distrust - and this isn't just among CAs or certificates - is more than just a binary yes or no. It's a spectrum that varies with the risk involved. For example, if you said I had a 1% of getting a papercut when doing some action, I'd probably be willing to entertain that risk, but if you were to say I had a 1% risk of dying, then I'd consider that a very risky thing indeed! So the trust of a certificate, even in isolation (that is, not considering the entire corpus of certificates out there) is weighted on a spectrum. For example, if you had a domain whitelist, you would know that you only engage in risky behaviour if you access a domain on that whitelist (as your first mitigator of risk), but then you also have to consider what services the site provides or what actions you're going to engage in (as the second mitigator of risk) when evaluating that trust decision. The other important factor that you're not considering is transparency. You're assuming that you're having to only operate on the knowledge presented in front of you with the certificate, and using only the knowledge you personally have. However, when things are disclosed - such as via Certificate Transparency - you need to factor in the other knowledge that may be had by other parties. For example, an important party you're not considering is the domain holder - if all the certificates are actually logged, or at least all the certificates you might be asked to trust - then the domain holder has an opportunity to speak out against any sort of misissuance. Similarly, you can trust that the certificates are only valid for *that* domain - if there were certificates that were able to facilitate abuse, you could trust that the community of technical experts here would have alerted to such risk. I hope this explains why your considerations of trustworthiness - all important conditions I believe - may not be taking in the full picture, and it's within that full picture, and with consideration of the risk, that there are alternatives being proposed. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
