On Sat, 9 Dec 2017 18:20:56 +0000 Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> First, third parties who are *not* CAs can run key generation and > escrow services, and then the third party service can apply for a > certificate for the key, and deliver the certificate and the key to a > customer. I'm not sure how this could be prevented. So if this > actually did end up being a Mozilla policy, the practical effect > would be that SSL keys can be generated by third parties and > escrowed, *UNLESS* that party is trusted by Mozilla. This seems . > backwards, at best. I'm actually astonished that CAs would _want_ to be doing this. A CA like Let's Encrypt can confidently say that it didn't lose the subscriber's private keys, because it never had them, doesn't want them. If there's an incident where the Let's Encrypt subscriber's keys go "walk about" we can start by looking at the subscriber - because that's where the key started. In contrast a CA which says "Oh, for convenience and security we've generated the private keys you should use" can't start from there. We have to start examining their generation and custody of the keys. Was generation predictable? Were the keys lost between generation and sending? Were they mistakenly kept (even though the CA can't possibly have any use for them) after sending? Were they properly secured during sending? So many questions, all trivially eliminated by just not having "Hold onto valuable keys that belong to somebody else" as part of your business model. > Second, although I strongly believe that in general, as a best > practice, keys should be generated by the device/entity it belongs to > whenever possible, we've seen increasing evidence that key generation > is difficult and many devices cannot do it securely. I do not have any confidence that a CA will do a comprehensively better job. I don't doubt they'd _try_ but the problem is Debian were trying, we have every reason to assume Infineon were trying. Trying wasn't enough. If subscribers take responsibility for generating keys we benefit from heterogeneity, and the subscriber gets to decide directly to choose better quality implementations versus lower costs. Infineon's "Fast Prime" was optional, if you were happy with a device using a proven method that took a few seconds longer to generate a key, they'd sell you that. Most customers, it seems, wanted faster but more dangerous. Aside from the Debian weak keys (which were so few you could usefully enumerate all the private keys for yourself) these incidents tend to just make the keys easier to guess. This is bad, and we aim to avoid it, but it's not instantly fatal. But losing a customer keys to a bug in your generation, dispatch or archive handling probably _is_ instantly fatal, and it's unnecessary when you need never have those keys at all. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
