I think key escrow services are pretty rare related to TLS certs. However, there's lots of CAs and services that escrow signing keys for s/MIME certs. Although, I'm not sure how companies can claim non-repudiation if they've escrowed the signing key, a lot of enterprises use dual-use keys and want at least the encryption portion in case an employee leaves.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Gervase Markham via dev-security-policy Sent: Monday, December 11, 2017 12:48 AM To: [email protected] Subject: Re: CA generated keys Hi Tim, The more I think about it, the more I see this is actually a interesting question :-) I suspect the first thing Mozilla allowing this would do would be to make it much more common. (Let's assume there are no other policy barriers.) I suspect there are several simpler workflows for certificate issuance and installation that this could enable, and CAs would be keen to make their customers lives easier and reduce support costs. On 09/12/17 18:20, Tim Hollebeek 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. That is true. Do you know how common this is in SSL/TLS? > 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. Another way of putting it it: "unless that party were the party the customer is already dealing with and trusts". IoW, there's a much lower barrier for the customer in getting the CA to do it (trust and convenience) compared to someone else. So removing this ban would probably make it much more common, as noted above. If it's something we want to discourage even if we can't prevent it, the current ban makes sense. > 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 doubt that > forcing the owner of the device to generate a key on a commodity PC is > any better (it's probably worse). That's also a really interesting question. We've had dedicated device key generation failures, but we've also had commodity PC key generation failures (Debian weak keys, right?). Does that mean it's a wash? What do the risk profiles look like here? One CA uses a MegaRNG2000 to generate hundreds of thousands of certs.. and then a flaw is found in it. Oops. Better or worse than a hundred thousand people independently using a broken OpenSSL shipped by their Linux vendor? > With an increasing number of small devices running web servers, keys > generated by audited, trusted third parties under whatever rules > Mozilla chooses to enforce about secure key delivery may actually in > many circumstances be superior than what would happen if the practice is banned. Is there a way to limit the use of this to those circumstances? Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://clicktime.symantec.com/a/1/7IiyfqIYVYHVo4yJwZ1gujE6ewgPbVhdeNR8nQYMk tE=?d=-Wn_VctZunngdEk_ioG0-YmJpPH0bSY7avkVy2G5jkppW7WbRwmFtauXnqI4GVKzIanQD2 ZA6NInKdI3JGkcf9ryTq6n-s4c4pg5s3wE4vkp4yda03M7jQfN5_Ag8-70lEsjQb45m2On8sIoG_ dT07uGS0eLuIUFBs5Ejb7aU7SMDef-aiw2SMmHSy34HrobgXESUV5rtJhwEAyCZvSWTdlhTt2mUM XVuNXdmFtAYun19fEnhCuxZTm44Inip_9XUfKb73PIvmELdwusC79xu_WgoRGUvPUEFfEYMZQJLz r1wo3PfgH3YtIhu55H4aSMlU8UOVe5JjW6WYG0wIKfKfGKta_cm5JB9HGONmcRvB8nw-A2xd5kr6 jSh2Pb6kH9EJMOhxcnioBU4Gm_IH7he9MnhbhTu2BATkoSNvbqOoNB&u=https%3A%2F%2Flists .mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
